[Openocd-development] Clock setup for STM32F107
Hi,
inspired by this post, I created a reset-init script that initializes
the system clock for the STM32F107 (connectivity line) and sets the JTAG
speed to 6 MHz.
https://lists.berlios.de/pipermail/openocd-development/2010-October/016709.html
Currently, I source it in my custom configuration script, but it would
be nice to have this included into to the OpenOCD distribution.
source [find interface/arm-jtag-ew.cfg]
source [find board/olimex_stm32_h107.cfg]
source [find stm32f10x_cl_72MHz.cfg]
init
reset init
This JTAG speed yields flash programming at 13.6 kb/s, and stepping is
also pretty smooth.
Some further benchmarks (OpenOCD compiled without any additional logging):
@ 32 KHz: 1.9 kb/s
@ 64 KHz: 3.4 kb/s
@ 125 KHz: 5.6 kb/s
@ 250 KHz: 8.1 kb/s
@ 500 KHz: 10.2 kb/s
@ 1MHz: 11.8 kb/s
@ 2MHz: 12.9 kb/s
@ 4MHz: 13.4 kb/s
@ 6MHz: 13.6 kb/s
Next, I will try out the async. write patch mentioned here:
https://lists.berlios.de/pipermail/openocd-development/2011-July/020261.html
(and related posts).
Best regards,
Simon
# Enable PLL2 and PLL (as in CMSIS system_stm32f10x.c)
# and clock system with 72 Mhz
#
# Set JTAG clock to 6 MHz
$_TARGETNAME configure -event reset-init {
# RCC_CR reset value: 0x??83
# RCC_CR - RCC_CR_HSEON
mww 0x40021000 0x10083
sleep 10
# FLASH_ACR reset value: 0x30
# FLASH_ACR - FLASH_ACR_PRFTBE, FLASH_ACR_LATENCY_2
mww 0x40022000 0x32
# RCC_CFGR reset value: 0x0
# RCC_CFGR - RCC_CFGR_HPRE_DIV1, RCC_CFGR_PPRE2_DIV1,
RCC_CFGR_PPRE1_DIV2
mww 0x40021004 0x400
# RCC_CFGR2 reset value: 0x0
# RCC_CFGR2 - RCC_CFGR2_PREDIV2_DIV5, RCC_CFGR2_PLL2MUL8,
# RCC_CFGR2_PREDIV1SRC_PLL2, RCC_CFGR2_PREDIV1_DIV5
mww 0x4002102c 0x10644
# RCC_CR - RCC_CR_PLL2ON
mww 0x40021000 0x4010083
sleep 10
# RCC_CFGR - PLLCLK = PREDIV1 * 9 = 72 MHz
mww 0x40021004 0x1d0400
# RCC_CR - RCC_CR_PLLON
mww 0x40021000 0x5010083
sleep 10
# RCC_CR - RCC_CFGR_SW_PLL
mww 0x40021004 0x1d0402
sleep 10
adapter_khz 6000
}
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Clock setup for STM32F107
On 04.08.2011 09:30, Simon Barner wrote: Some further benchmarks (OpenOCD compiled without any additional logging): @ 32 KHz: 1.9 kb/s @ 64 KHz: 3.4 kb/s @ 125 KHz: 5.6 kb/s @ 250 KHz: 8.1 kb/s @ 500 KHz: 10.2 kb/s @ 1MHz: 11.8 kb/s @ 2MHz: 12.9 kb/s @ 4MHz: 13.4 kb/s @ 6MHz: 13.6 kb/s Note that I used the following command to program my (47kb) image: flash write_image erase image.bin 0x800 bin However, when I explicitly erase the flash before, I yield even higher speeds: flash erase_address 0x800 0x4 erased address 0x0800 (length 262144) in 0.044003s (5817.785 KiB/s) flash write_image image.bin 0x800 bin wrote 47984 bytes from file image.bin in 2.623150s (17.864 KiB/s) Simon ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Jlink SRST pin value
Hi, I am a newbie of openocd. I am using JLink to debug a ARM926ejs CPU. During startup of openocd, it will use EMU_CMD_GET_STATE command to get all the pins state of jlink. On a working board, it gets TMS = 0 SRST = 0 TRST = 0 On a no-working board, it gets TMS = 0 SRST = 1 TRST = 0, (then it will get the wrong message: Error: jlink_usb_message failed with result=5) In my understanding, when SRST is low, the system will reset. I think it should be high at the startup time. But, why when SRST=0, the JTAG works? Best Regards Richard LIU ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Jlink SRST pin value
Additional information: I think the jlink can not communicate with my CPU msm7x27A (when CPU is in the reset state) Because now, the reset and halt command is working. But the reset halt and reset init isn't. When execute reset halt, it will display some errors: reset halt JTAG tap: msm7xxx.cpu tap/device found: 0x006300e1 (mfg: 0x070, part: 0x0630, ver: 0x0) WARNING: unknown debug reason: 0xf jlink_usb_message failed with result=5) jlink_tap_execute, wrong result -107 (expected 270) According to the User Guide: In the best case, OpenOCD can hold SRST, then reset the TAPs via TRST and send commands through JTAG to halt the CPU at the reset vector before the 1st instruction is executed. Then when it finally releases the SRST signal, the system is halted under debugger control before any code has executed. This is the behavior required to support the reset halt and reset init commands; after reset init a board-specific script might do things like setting up DRAM. Thanks a lot in advance. Best Regards Richard LIU On Thu, Aug 4, 2011 at 4:37 PM, Liu Hua lhh...@gmail.com wrote: Hi, I am a newbie of openocd. I am using JLink to debug a ARM926ejs CPU. During startup of openocd, it will use EMU_CMD_GET_STATE command to get all the pins state of jlink. On a working board, it gets TMS = 0 SRST = 0 TRST = 0 On a no-working board, it gets TMS = 0 SRST = 1 TRST = 0, (then it will get the wrong message: Error: jlink_usb_message failed with result=5) In my understanding, when SRST is low, the system will reset. I think it should be high at the startup time. But, why when SRST=0, the JTAG works? Best Regards Richard LIU ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Clock setup for STM32F107
Andreas, list, On 04.08.2011 09:46, Simon Barner wrote: On 04.08.2011 09:30, Simon Barner wrote: Some further benchmarks (OpenOCD compiled without any additional logging): @ 32 KHz: 1.9 kb/s @ 64 KHz: 3.4 kb/s @ 125 KHz: 5.6 kb/s @ 250 KHz: 8.1 kb/s @ 500 KHz: 10.2 kb/s @ 1MHz: 11.8 kb/s @ 2MHz: 12.9 kb/s @ 4MHz: 13.4 kb/s @ 6MHz: 13.6 kb/s Note that I used the following command to program my (47kb) image: flash write_image erase image.bin 0x800 bin However, when I explicitly erase the flash before, I yield even higher speeds: flash erase_address 0x800 0x4 erased address 0x0800 (length 262144) in 0.044003s (5817.785 KiB/s) flash write_image image.bin 0x800 bin wrote 47984 bytes from file image.bin in 2.623150s (17.864 KiB/s) Next, I will try out the async. write patch mentioned here: https://lists.berlios.de/pipermail/openocd-development/2011- July/020261.html (and related posts). I applied the patches 1/5 - 5/5 against my fixed ARM-JTAG-EW driver and yield now (STM32F107, JTAG @ 6 MHz). Also, debugging the target seems to work decently. flash erase_address 0x0800 0x4 erased address 0x0800 (length 262144) in 0.063400s (4037.855 KiB/s) flash write_image image.bin 0x0800 bin wrote 47984 bytes from image.bin in 1.778403s (26.349 KiB/s) Here, the performance penalty of auto-erase becomes even more visible. monitor flash write_image erase image.bin 0x0800 bin wrote 49152 bytes from file image.bin in 2.932805s (16.367 KiB/s) Or, could it be the case the time required for the explicit erase is reported to low? One more question: In the above patch (5/5), there is a change to the flash loader in the contrib directory. As far as I understand, this Cortex-Code is not used in the above programming method. Could you please point me to some documentation how to use it or briefly explain what it is good for? Best regards, Simon ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Tutorial Material on Flash Drivers
Based on my need for a flash driver for a new chip, I have created some tutorial material on creating flash drivers for OpenOCD. This is work-in-progress as I experiment and learn more. Inspired by an Open Source Software Engineering class at Portland State University, I have posted some code and documentation others may find helpful. The example code is a copy of the stm32.c flash driver to which I have added extensive comments that reflect my understanding of the code. There is also a start at a custom flash driver on which I am working. Certainly it would be wonderful if some of the experienced OpenOCD developers could offer some insight and fill in some details. Any responses will be greatly appreciated and added to the material. Here's the link: https://github.com/doctek/COOCDFlash/wiki Contact me via the list or privately. - jim larson jlar...@pacifier.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Tutorial Material on Flash Drivers
Cool :-) Congrautlations Jim! We wanted to do something like that as more general wiki with Drasko, so now we have a place to develop :-) Best regards, Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Last call before release
I submitted these patches a couple weeks ago, i guess everybody was too busy with the release... Could they be added? Thanks! On Wed, Aug 3, 2011 at 7:34 AM, Andreas Fritiofson andreas.fritiof...@gmail.com wrote: On Wed, Aug 3, 2011 at 3:32 PM, Tomek CEDRO tomek.ce...@gmail.com wrote: Hello Jean, please provide full featured RC package (generated by make distcheck, containing configure scripts) to test it on FreeBSD, as for now bootstrap fails, so the status is no-go. Best regards, Tomek Yes, we haven't had a chance to iron out bugs in the release procedure so I'd say we need a proper RC release before 0.5.0. But there's more to it than make distcheck. At this point I think it would result in wrong version strings in the binary. We have a script, tools/release.sh, that (when used correctly) patches configure.in with the correct version string, builds source packages, creates the proper tags, prepares the repository for the next release cycle and whatnot. Please use that. Some manual steps may be needed too: http://openocd.berlios.de/doc/doxygen/html/releases.html#releasehow Check the git log to see how the 0.4.0 release and preceding RCs were handled. Right now, the repository looks nothing like that. /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development -- Rodrigo. 0001-PATCH-1-4-dps5680xx-fix-warnings.patch Description: Binary data 0002-PATCH-2-4-dsp5680xx-fix-FM-clk.patch Description: Binary data 0003-PATCH-3-4-dsp5680xx-fix-constante-ref.patch Description: Binary data 0004-PATCH-4-4-re-enable-dsp5680xx.patch Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Last call before release
Hi Rordrigo, it's too late for this release, we're just waiting for the release to go out of the door, I don't think there are any issues we intend to fix at this point. -- Øyvind Harboe - Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
