STM32F103 series bootloader PC software.

[avinash_elec]

Posted on July 01, 2011 at 06:00

Hello All,

I am new to STM32F103 MCUs. I know it can boot from system area containing a factory programmer ST bootloader that uses USART1 interface. So I thought there must be a ISP utility from ST can (like the Flash Magic for NXP). I tried lots of Googling but cannot find one. So can any one point me such an utility that can program and read a STM32F103VET6 MCU over UART1? Thanks in advance. (I found STVP - ST Visual Programmer but I think it does NOT support STM32 ISP) #programming #isp #tool #bootloader #stm32f103

[Tesla DeLorean]

Posted on July 01, 2011 at 06:24

Try Googling ''STM32 Flash Loader''

http://www.st.com/stonline/products/literature/um/13916.pdf Pick any STM32F1xx part, Select ''Design Support'' tab, scroll to ''SW DEMOS'' http://www.st.com/internet/mcu/product/216821.jsp http://www.st.com/internet/com/SOFTWARE_RESOURCES/SW_COMPONENT/SW_DEMO/um0462.zip

[avinash_elec]

Posted on July 01, 2011 at 10:07

@clive1

Thanks a lot !

[avinash_elec]

Posted on July 02, 2011 at 05:04

Hello,

I download the software but it says ''Unrecognized Device ... Please, reset your device then try again '' I have gone through the detail of the bootloader to find out that the host sends a 0x7F at the beginning so that stm32 can autobaud. After that the stm32 returns and ACK (ascii y) I tried the same sequence manually from RealTerm and got the ACK properly. That means connections are OK. So what could be the problem ?

[p_hedlund]

Posted on July 02, 2011 at 16:47

Greetings,

I have tried the bootloader in AN2557 the only problem i found was it set the baud rate to 57600 not 115200 as in the docs.  You can then use a terminal program (hyperterm, ZOC) to upload your program via the usart.

[Tesla DeLorean]

Posted on July 03, 2011 at 16:44

You could try to drop the baud rate as suggested, but I've found the boot loader to be quite robust at 115200 8E1. It does the autobaud at startup, so you might want to reset and try over.

The other problem commonly reported is a with external USB serial dongles, try using different external/internal ports to see if things work any better

[avinash_elec]

Posted on January 08, 2012 at 14:02

Hello,

I am using PL2303 based USB to RS232 convertor. My Board has MAX3232 to USART1 interface. The ''ST Flash Loader Demonstration'' is working ok till last phase, where it fails after certain percentage of write. See the attached image ... ________________ Attachments : FlashLoaderDemo.PNG : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I0pC&d=%2Fa%2F0X0000000bex%2ForZB.5z4.NkarNQCLJMxXWTNfIgNQLy2tI5o5caOGjU&asPdf=false

[Tesla DeLorean]

Posted on January 08, 2012 at 16:16

Well that will be fun to trouble-shoot.

It is possible that the flash memory is a problem, which could be due to power supply issues. Look at the bulk capacitance on the STM32, and those on the MAX3232. Is the problem consistent across a number of boards? Different PCs or serial ports? It could be a communication problem, serial data transmitted in this fashion can get corrupted. Try lower baud rates, and perhaps two stop bits. The protocol does provide for some simple checksum integrity check, but I can't speak to the robustness of the retries, or page erase/retry capabilities of the flash loader demonstration. Most of the failures are probably hard, and the diagnostic messages non-specific. This might be easier to diagnose by using the command line source code, or reimplementing the protocol, so you can specifically identify if the problem is with transmission of data to the part, or the programming of data to the flash memory, or subsequent read-back verification.

[avinash_elec]

Posted on January 15, 2012 at 07:48

@Clive1

Thanks for your time. actually my J-LINK died in middle of an important project. Since these are NOT available in by country, I have to import them via DHL Express. But it too take some time to get in here. I was trying to flash the board using bootloader instead of JTAG. Since I already had a neasrly debugged program with me. Board may NOT be a problem (though I will check with other boards today). This is because I used 3-4 boards with my J-LINK and never faced any such verification problems. It was very reliable.

[Tesla DeLorean]

Posted on January 15, 2012 at 16:45

That is certainly a valid approach. I'm using JTAG for the more invasive debugging, but I've been using USART1 to provide production programming, as well as debugging and telemetry data. In all current STM32 designs it is committed to this function with other serial devices connected to the other serial ports instead. A lot of this also comes from doing it this way for a very long time, from a time/place were hardware debuggers (ICE) were very expensive, and not terribly available. You learn to be creative, and understand how the code is working via other means.

The use of the serial port also permits easier in-field diagnostic with readily available, low cost, interfacing hardware.