Flash programmer for STM32

[rs11]

Posted on October 29, 2009 at 06:41

Flash programmer for STM32

[rs11]

Posted on May 17, 2011 at 13:28

I am looking for a tool to program the internal flash of STM32. I am hoping to also use this tool to dump (read) the contents of the internal flash to a file on PC to create master images that can be used for mass programming for production.

I have been using ulink2 from keil for development; unfortunately it does not have the capability to read back the flash to create a file with the contents of the flash. Also, ulink2 needs the keil uVision IDE to work with it. ulink2 + uVision would cost a lot to do just the programming.

Any recommendations or suggestions?

[swhite]

Posted on May 17, 2011 at 13:28

What about the built-in bootloader via a serial port?

http://www.st.com/stonline/products/literature/an/13801.pdf

http://www.st.com/stonline/products/literature/an/14156.pdf

http://www.st.com/stonline/products/support/micro/files/um0462.zip

[ This message was edited by: swhite on 27-10-2009 11:53 ]

[norcio82]

Posted on May 17, 2011 at 13:28

Check RLink Standard from

http://www.mcu-raisonance.com/

and Ride7 from

http://www.mcu-raisonance.com/mcu_downloads.html

Ride7 is free and there is option to dump flash into hex file

[rs11]

Posted on May 17, 2011 at 13:28

Thanks norcio82.. Do you know if Ride7 expects any specific format for the file that needs to be programmed?. Or can this be any binary file?

[rs11]

Posted on May 17, 2011 at 13:28

Thanks swhite..

Built in bootloader cannot be used since I can not change the boot pin configuration on the custom board.

[rs11]

Posted on May 17, 2011 at 13:28

Quote:

Pulling binary data from a working/golden device wouldn't provide the level of source code control I'd be looking for.

Could you please elaborate on this as I dint figure what you meant by source code control.

[rs11]

Posted on May 17, 2011 at 13:28

Hi Clive1..Thanks for the valuable input.Combining Save command with uVision's ability to program any hex file solves my problem.

[clive2]

Posted on May 17, 2011 at 13:28

It's been a while since I played with it, but Segger's J-Flash program for the J-Link should support reading and writing of the device. It would probably be usable by production staff.

The old Realview AXD debugger could download the memory from the debugger. In Keil uVision you can create a HEX file from the debug command window (lower left - Output Window) using a ULink, the following with pull 128KB slowly (will appear to hang for 20-30 seconds) from the STM32 flash.

save c:\foo.hex 0x8000000,0x8020000

Keil generates a Intel Hex file as part of the compile/link process, you should be able to use that as a master. Pulling binary data from a working/golden device wouldn't provide the level of source code control I'd be looking for.

The user code running within the STM32 could output data out of memory, could checksum the flashed image, and also be set to update it self from an external source. In designing a board for manufacture and test, the BOOT0/1 and UART1 TX/RX, RESET and JTAG signals should reach test points.

Even without control of the BOOT0/1 pins code running within the FLASH or RAM of the STM32 can execute the System Boot Loader in ''ROM''. If UART1 is not available you could create an equivalent loader/monitor using a UART of your choice.

-Clive

[clive2]

Posted on May 17, 2011 at 13:28

I guess my point is that I wouldn't use data pulled off a device as a golden standard to produce all the others, I would want to use the first generation output from the tool chain, or automated make process. If the data on the working device were somehow different to the code that was supposed to be onboard I would be quite worried. Things have advanced considerably since I had to make golden EPROMS for a stand-alone PROM programmer where bytes/words had to be swapped and split across multiple devices.

When developing production code I use CVS to achieve source code control, I would check in and tag a build of software giving it a version number, I would associate that with the BIN/HEX file generated by the tools, and the version/build of the tool chain used to create it. The BIN/HEX file would then be signed off to production.

If at some point in the future I have to revisit the code because a customer (my boss, sales, whomever) finds a bug or wants a feature added, not only can I produce the ROM image they have, but the source code that made it. If necessary I can remake it, and versions and branches prior to and derived from it. Frankly anyone within the organization should be able to do it to.

I would want to be able take a blank STM32 and burn the hex file to it with any of a number of tools, I would not want to have the development IDE program it and then extract a binary image to generate a production image. I might want to pull off a binary image if I wanted to confirm that the tools programmed it correctly, or if someone gave me a random part and wanted to know/confirm what was on it.

In the case of part unique data (configuration, calibration, serial, etc), I would look to have the boot code identify the absence and enter a production test mode. Alternatively I would partition the image, or mark configuration data, so that the production programming tool could insert suitable data.

Hopefully that was the elaboration you were looking for.

-Clive

[sjo]

Posted on May 17, 2011 at 13:28

you can use the SAVE cmd within keil to save the target memory.

As for programmers, either Raisonance or have you looked at openocd?

Cheers

sjo