On Thu, Aug 4, 2011 at 5:12 PM, Simon Barner <[email protected]> wrote: > 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 0x08000000 0x40000 > erased address 0x08000000 (length 262144) in 0.063400s (4037.855 KiB/s) > > flash write_image image.bin 0x08000000 bin > wrote 47984 bytes from image.bin in 1.778403s (26.349 KiB/s) >
Thanks for testing the patches. So, a significant speed-up (~50%) due to the async patches, great. I believe the actual flashing is now mostly limited by flash write speed of the STM32F1x (~39 KiB/s => about 1.2 seconds for your file) and that there's not much more that can be done with the flash write algorithm. The overhead of almost 0.6 seconds can be explained (without examining debug logs) by the time it takes to set and restore registers before and after the algorithm execution. Which is extremely inefficient and I don't know if it's for a good reason. It's on my todo list to dig into that. Any speedup in that area would also greatly improve stepping speed. > Here, the performance penalty of auto-erase becomes even more visible. > > monitor flash write_image erase image.bin 0x08000000 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? > I think it's correct. I haven't looked at the auto erase code but I suspect that the slowdown is due to the fact that only the blocks being reprogrammed are erased. As is common with flash, you can select one of a few configurations of blocks to erased. On the STM32F1xx, you have the choice of erasing one block, or all of them. Both operations take about the same time (milliseconds). I'm guessing that the explicit erase command detect that you're erasing the entire flash and so use the mass erase command instead of several invocations of the per-block erase command. I very seldom need to save existing flash content so I tend to use the explicit mass erase command (stm32f1x mass_erase 0) instead of auto erase/flash erase. > 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? > It is certainly being used during flash programming. The source code is assembled to machine code and included as a static array in the flash block write function in stm32f1x.c, using the following commands (out of my head): arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -c stm32f1x.S -o stm32f1x.o arm-none-eabi-objcopy -O binary stm32f1x.o stm32f1x.bin xxd -i < stm32f1x.bin This is not done automatically during build to avoid the need for the casual openocd builder to have lots of cross toolchains installed. The source code is included for reference and not actually used during build. /Andreas
_______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
