Spencer Oliver a écrit : > > >> I've looked a bit more into STM32 flash programming >> performance and most of the time is spent waiting for the >> target to complete flash programming, i.e. it appears that it >> is the *target* that is slow. >> >> Could this be the case? >> >> >> > > Have you tried turning on the PLL etc before programming? > That is generally what i do, and as far as i remember what the ST bootloader > does. > > Otherwise the device is running @ 8MHz, gets better when running @ 72MHz. > you can then speed up the jtag, instead of using the initial 500kHz. > > Cheers > Spen > > That could be interesting to see the change in performance.
There is an issue that has to be remembered as well in order to get a reliable reflash of the code. You need to make sure that the peripherals are reset if you are using DMA. I had an interesting experience this week on this. This was with the IAR debugger. I use DMA for the A/D. When I would reflash the device it would sometimes crash after that. That depended what flash piece was not written correctly. Changing the code would make the crash somewhere else. It turned out that the DMA might have been running in the background. Reflashing from a crashed device (from power up) would result in a correctly programmed flash. Resetting the peripherals before starting the reflash fixed the problem. Michel -- Tired of Microsoft's rebootive multitasking? then it's time to upgrade to Linux. http://home.comcast.net/~mcatudal _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
