Fast programmer for stm32

[trevwhite]

I am looking for a fast programmer for STM32 devices. I am working on a device that has 2MB flash and the JLINKV2 just takes too long to program.

I have looked around a bit and the SEGGER J-Link Ultra+ seems to be fast at 3MB/s but it has a high price tag to it. I was wondering if anyone can recommend a cheaper alternative that is quick?

Thanks

Trev

[technix]

The STM32 chip has a built-in serial bootloader, but it isn't that fast in reality. You can load your own bootloader using this, and load the main firmware using your own USB bootloader. This way, through the use of USB bootloader, you can saturate the writing speed of the Flash.

[trevwhite]

Thanks, that's an interesting idea about using the bootloader. Be nice to have mass storage device bootloader application. Just dump the file in and it programs. I think mbed has this but no idea of speed.

Be nice to find a ready made open source version of that.
 

[abraxa]

the JLINKV2 just takes too long to program

What is the size of the binary? How long is "too long"? Are you using JTAG or SWD to program? Does it flash *all* flash segments every time or only the ones that changed?

[trevwhite]

File size is over 1MB. I have images embedded in the code space and so the actual file is quite large. I am using the STM32F429..

If I use the onboard debugger of the dev board I am waiting minutes to download and start debugging. I have been testing the demo application source code supplied with the board by ST.

I am using SWD through Atollic IDE interface and STM32 development board as the platform. I think it erases the whole chip but I cant be sure but judging by the fact it takes a few minutes its doing something crazy. Maybe I am doing something wrong but it seems real slow to me.

[Kjelt]

Could just be the normal way, the chip has to erase the flash page receive data in ram, write to entire flashpage and verify, this takes a long time.
Only the transfer from data to ram is the mentioned speed. The internal flash is rather slow, it takes often waitcycles in your program.

Best way to check is use the cheap stlink and the stlink utility, erase the chip and write the entire program to the chip with stlink utility, record time this takes and compare.

Then debugging is an entire different story, besides the debug program which is larger you have to setup the debug environment, set the breakpoints, read all registers etc etc, this is always lot slower than just programming the chip.

[trevwhite]

Thanks, will try stlink utility, it may well be quicker.

[ataradov]

Read the erase and write speed of the flash. I bet the slowness you see a limitation of flash write speed.

[trevwhite]

ST-LINK Utility works great. I programmed 1MB in about 20 seconds so programming is fine. It seems it is more to do when I start a debug session in Atollic.

 

[AndyC_772]

That sounds like an Atollic limitation. Maybe it would be worth directing your enquiry at their technical support?

I use an ST-Link V2 with Rowley Crossworks, and I see programming speeds about the same as you're getting with the ST-link software. Their own proprietary 'cross connect' cable is no faster, despite its much higher cost.

[trevwhite]

AndyC, have you had any problems with setting up a debug session in CrossWorks? The demo app for the STM32F429 discovery board is 1MB. When working with boards that only have 20K or 30K I had no problems with Atollic Lite.

[technix]

AndyC, have you had any problems with setting up a debug session in CrossWorks? The demo app for the STM32F429 discovery board is 1MB. When working with boards that only have 20K or 30K I had no problems with Atollic Lite.

Ahh program size limits in Lite versions of those tools...

I have been using straight Eclipse CDT + GCC toolchain for a while. No problem at all sizes have been encountered. And it is always fairly fast.

[AndyC_772]

AndyC, have you had any problems with setting up a debug session in CrossWorks?

Not really. It gets a bit confused if the target gets unplugged or loses power at the wrong moment, but nothing that a retry or two won't fix. Generally I find the solution overall to be very robust. My download size is around 600k on a 1MB device, so not quite as big as yours, but comparable.

[trevwhite]

I don't believe there is a size limit in Atollic these days. It just has features removed.

I did consider subscription but they just doubled the price and that unsettled me to think they could put the price up so much. I do like the IDE though and I am not against paying but to pretty much double the cost makes me wonder what else they will do. Before they released a free version and then withdrew it. Now it is free again but who knows.

[DBecker]

Writing the STM32 flash is handled by the ARM core, not the debugging interface.

To write the STM32 flash on a blank part you write a tiny program into RAM, write the page to programmed into RAM, initialize the CPU registers including the program counter, then start the processor.

The typical process uses the simplest possible flash writing program, and the simplest way to poll on the page write being finished.  It then repeats the entire process from scratch to write the next page.

It's possible to significantly increase the speed by overlapping the transfer of the next page while writing the first, and have the program automatically switch to the next write.  The larger parts have dual banks of flash which can be written simultaneously.  The former is easy to program.  Using latter is more complex than you might initially expect.

[Brutte]

File size is over 1MB (..) If I use the onboard debugger of the dev board I am waiting minutes to download and start debugging.

Ok, so you do not need a fast programmer actually.
You just want to speed up the cycle time:

Code: [Select]

compile->reprogram->debug->compile->reprogram->debug->...
Then you can try my SplitCode.
The idea is to partition the application (the source files) into two categories:
one was called "Evolving" and the other
one was called "Stable"

As long as you edit source files in "Evolving" part, the cycle time: ->compie->reprogram>debug->... takes seconds.
What is interesting, this time does not depend on the size of the final application.

The project is a proof of concept, tested on STM32L152.

[trevwhite]

Thanks, Brutte. Interesting idea. I shall have a look at it.

[Siwastaja]

Just write your own in-application programming code (sometimes wrongly called "bootloader"). Often, it's something you want anyway at a later point. This way, you can reprogram any way you want, through any interface you are using, without any special devices, cables or even boot pins. Then you can add convenient "remote update" features, even for end user.

Flash speed is not necessarily the bottleneck. For example, when I program through my own USART programmer ("bootloader", except it has nothing to do with booting or loading, it's entered during normal operation, rewrites the flash except it's own memory area, and ends up in a reset) at 115200 baudrate, it's approximately 5 times faster than the factory STM32 USART bootloader running at the same 115200.