Re: [Openocd-development] load_image trouble
I cant upload an image into internal SRAM (AT91SAM9). it can really write only 20 bytes. load_image into internal flash area works fine. But why it doesn't fail if it writes the other regions? It crashes only if it writes into internal SRAM. Could it be that the load_image command uses working area which overlaps with the address you're trying to write, thus corrupting the algorithm? No, I've tested writing area address:0x30-0x300040 (SRAM start address). So, where is your working area? I don't know which config file you use but, looking through some of the at91*.cfg, they generally set up working area to 0x30 and a few KB onwards. Have you tried moving it a bit to see if it makes a difference. I don't see why load_image should need to use working area so maybe it's a long shot. Worth a try anyway. :) First of all I wrote a script that can program internal flash: 1. It writes 512b into intertal flash area (load_image) 2. It touches EEFC_FCR to start writing process 3. It waites for EEFC_FSR FRDY (finishing writing process) 4. Repeat 1 with the next 512 block until all data are written It worked pretty slowly. So then I've tested to write 32k block to SRAM (I wanted to write 1-2Kb loader). I wanted then to start the program from SRAM. But I stumbled on the load_image's trouble. Then I've returned to my old slow script. My test program countinued to grow. It ranked 2blocks, 3 blocks,... 11 blocks. Then my program began to require 14 blocks: i stubmled the problem again: If I use load_image for addresses 0x20_ - 0x20_1c00 - it works fine. If I use load_image for the other addresses (for example: 0x20_1c00 - 0x20_1e00 (Flash) or 0x30_ - 0x30_0200 (SRAM)) I have the problem. Also I've tested a few JTAGs SAM-ICE. And the problem exists for Openocd 0.4.0 and 0.5.0. -- . ''`. Dmitry E. Oboukhov : :’ : email: un...@debian.org jabber://un...@uvw.ru `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 signature.asc Description: Digital signature ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] gerrit hosting
Anyway you can check this site to find any hoster with a code review ability: http://en.wikipedia.org/wiki/Comparison_of_open_source_software_hosting_facilities No gerrit listed. I've asked sourceforge if they can install it, but I'm not holding my breath. -- Øyvind Harboe - Can Zylin Consulting help on your project? US toll free 1-866-980-3434 http://www.zylin.com/ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Clock setup script for STM32F107
Dear list,
I have already posted the attached script some weeks ago.
It enables the PLL of the STM32F107 and thus configures
the MCU to run at 72 MHz which allows for higher JTAG speeds.
Since this should be useful for everybody, I would like to
contribute it to OpenOCD. However, I am not sure how to integrate
it. One idea is to conditionally call it from scripts/target
/stm32f1x.cfg. Comments and alternative suggestions are highly
appreciated.
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 script for STM32F107
Am 10/09/2011 12:37 PM, schrieb Simon Barner: Dear list, I have already posted the attached script some weeks ago. It enables the PLL of the STM32F107 and thus configures the MCU to run at 72 MHz which allows for higher JTAG speeds. Since this should be useful for everybody, I would like to contribute it to OpenOCD. However, I am not sure how to integrate it. One idea is to conditionally call it from scripts/target /stm32f1x.cfg. Comments and alternative suggestions are highly appreciated. How about moving this to a function that can be called from the board config file? cu Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Clock setup script for STM32F107
On Sun, Oct 9, 2011 at 12:37 PM, Simon Barner bar...@gmx.de wrote:
Dear list,
I have already posted the attached script some weeks ago.
It enables the PLL of the STM32F107 and thus configures
the MCU to run at 72 MHz which allows for higher JTAG speeds.
Since this should be useful for everybody, I would like to
contribute it to OpenOCD. However, I am not sure how to integrate
it. One idea is to conditionally call it from scripts/target
/stm32f1x.cfg. Comments and alternative suggestions are highly
appreciated.
First of all, it's better to run off of the HSI instead. Not everyone has a
crystal attached, or it could be another frequency.
For example, I have this in my config files (for STM32F103, I don't know
what differs):
$_TARGETNAME configure -event reset-init {
mww 0x40022000 0x32
mww 0x40021004 0x3c0400
mww 0x40021000 0x01000883
sleep 10
mww 0x40021004 0x3c0402
sleep 10
adapter_khz 3000
}
As Michael said, it's probably best to put in in a tcl procedure that the
user can choose to call from the reset-init hook. Don't put the adapter_khz
in that procedure. If the settings are the same for all devices in the
family, the procedure probably belongs in target/stm32f1x.cfg.
/Andreas
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] What's up? Why so slow?
(At least) in SWD mode with an FTDI programmer openocd is sending data bit by bit. I am planning to send in a patch to fix that, but I am currently unable to test it, because I am waiting for my SWD-capable programmer. Regards, Ákos Vandra On 9 October 2011 08:21, Øyvind Harboe oyvind.har...@zylin.com wrote: USB roundtrips? On Sun, Oct 9, 2011 at 3:40 AM, Peter Stuge pe...@stuge.se wrote: EK-LM3S9B90 ICDI JTAG openocd git jtag_khz 6000 (gdb) load Loading section .text, size 0x1e5f8 lma 0x0 Loading section .data, size 0xe0 lma 0x1e5f8 Start address 0xc63d, load size 124632 Transfer rate: 3 KB/sec, 13848 bytes/write. Seriously, in 2011? //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development -- Øyvind Harboe - Can Zylin Consulting help on your project? US toll free 1-866-980-3434 http://www.zylin.com/ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] What's up? Why so slow?
Øyvind Harboe wrote: On Sun, Oct 9, 2011 at 3:40 AM, Peter Stuge pe...@stuge.se wrote: Transfer rate: 3 KB/sec, 13848 bytes/write. USB roundtrips? Ḯ'll have a look with usbmon soon. Akos Vandra wrote: (At least) in SWD mode with an FTDI programmer openocd is sending data bit by bit. I am planning to send in a patch to fix that, but I am currently unable to test it, because I am waiting for my SWD-capable programmer. LM3S knows JTAG and SWD. ICDI is FT2232 based and knows JTAG and SWD, and it's what the late David Brownell was doing his SWD work on, but my setup is using JTAG. //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] What's up? Why so slow?
On Sun, Oct 9, 2011 at 10:43 PM, Peter Stuge pe...@stuge.se wrote: Øyvind Harboe wrote: On Sun, Oct 9, 2011 at 3:40 AM, Peter Stuge pe...@stuge.se wrote: Transfer rate: 3 KB/sec, 13848 bytes/write. USB roundtrips? Ḯ'll have a look with usbmon soon. U+0618 LATIN CAPITAL LETTER I WITH DIRT ON TOP? I tried to scrape it off my monitor, dammit... :) It sounds like the LM3S flash algorithm could use a rewrite like the one I merged for STM32F10x yesterday. Flash speed went up from 9KB/s to 29 KB/s. I don't know why before-speed was so low when I tested yesterday, I normally got around 14 KB/s. Maybe the bus/computer was extra heavily loaded. I've never seen it as far down as your figures though. Almost as if the LM3S driver lacks block write completely. Examining the timestamps in the full debug log is a good complement to usbmon when debugging performance problems, btw. Akos Vandra wrote: (At least) in SWD mode with an FTDI programmer openocd is sending data bit by bit. I am planning to send in a patch to fix that, but I am currently unable to test it, because I am waiting for my SWD-capable programmer. LM3S knows JTAG and SWD. ICDI is FT2232 based and knows JTAG and SWD, and it's what the late David Brownell was doing his SWD work on, but my setup is using JTAG. I'm pretty sure that mainline ft2232 uses byte writes whenever possible. Akos: Is SWD even remotely up and running in mainline or are you using a fork? /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] What's up? Why so slow?
On Sun, Oct 9, 2011 at 11:28 PM, Akos Vandra axo...@gmail.com wrote: P.S. Is it just me, or the default reply address is the sender himself, and not the list? The list server doesn't set Reply-To to the list address, for some very good reason which I have forgotten now. Easiest fix is to set reply-to-all as the default reply action in your client. /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
