STM32F09x serial bootloader: does it work?

[nctnico]

I'm wondering whether anyone has some remarks/suggestions about the serial bootloader in the STM32F09x series. I'm working on a tool which should allow the customer (who also wrote the device's firmware) to do updates over the serial port but so far I don't get any further than the auto-baud handshake (send 0x7F receive 0x79) but after that the communication stops. The serial port signals look and decode good on an oscilloscope.

[Kalvin]

I wrote a similar tool on Linux for the STM32F030-series processor. I do not remember details, but it went pretty smoothly after all. Just read the application note AN3155 carefully and proceed step by step adding more functionality as you go www.st.com/resource/en/application_note/cd00264342.pdf The first command implemented was "get device id" or similar. The implementation is a simple state machine which had two main states: connected | disconnected. Each command was also a simple state machine which made the debugging easier. Now as I read the code, it is also easy to follow. I used the Saleae Logic as a debugging tool, which proved to be extremely useful. Using a plain oscilloscope (even with a deep memory) is just frustrating.  Remember to flush the rx buffer before each new command. Good luck!

[Kalvin]

Ps. When you open the serial port, disable the HW and XON/XOFF handshakes.

Edit: I am using 100ms receive timeout ie. If there is no character received within this 100ms timeout period, the receive function will return error.

[nctnico]

I did all that but either with my software, ST's own UART flash loader utility or manually with Teraterm I can't get the bootloader to do anything beyond the auto baud stage.

[Kalvin]

Change the USB to ttl-serial dongle. I have had some problems with the cheap dongles - the signal levels with the 3V devices do not quite match resulting lost or intermittent communication or the baud rate will be a little off or fluctuating which will generate occasional transmission errors. Changing the dongle has been the cure.

[nctnico]

Change the USB to ttl-serial dongle.

I did think about doing that but since the signals are OK on an oscilloscope I see very little chance the problem is in the (FTDI) USB-uart converter. Besides that the regular serial communication works just fine with the same converter.

[nctnico]

or the baud rate will be a little off or fluctuating which will generate occasional transmission errors. Changing the dongle has been the cure.

How much was the baudrate off? I just made some measurements with the baudrate set at 38400. The USB-UART is spot on but the STM32F09x seems to be at 38600. That is a difference around 0.5% so it is well within general UART tolerance but if the bootloader is somehow using a soft-UART with too strict timing then all bets are off.

[voltsandjolts]

Just to be sure, you could try an FTDI baud rate of 38585 (3e6/77.75)

[jesuscf]

How are you activating the bootloader?  I have a SM32F051 with a push-button connected to BOOT0.  BOOT0 is pulled down with a 330 ohm resistor and connected to 3.3V when the push-button is pressed.  While pressing the push-button at BOOT0 I press and release the push-button connected to NRST and then release the push-button connected to BOOT0.  Also I have a 470uF electrolytic capacitor between 3.3V and GND I don't remember why... Seems to work every time.

I'm wondering whether anyone has some remarks/suggestions about the serial bootloader in the STM32F09x series. I'm working on a tool which should allow the customer (who also wrote the device's firmware) to do updates over the serial port but so far I don't get any further than the auto-baud handshake (send 0x7F receive 0x79) but after that the communication stops. The serial port signals look and decode good on an oscilloscope.

[nctnico]

The bootloader is activated from software by (AFAIK) writing a special value into a register before resetting the controller. This is a two stage process where the controller is reset twice. First to restart the firmware which then jumps into the bootloader before initialising the peripherals with the second reset. At least that is how it should work but I can't check whether it is implemented correctly.

[jesuscf]

Maybe the bootloader is not activated. AN2606 (st.com/resource/en/application_note/cd00167594.pdf) describes several ways of activating the bootloader.  Could it be possible in your hardware to try to activate the bootloader using the BOOT(x) pin(s)?

EDIT: AN2606 says: "The STM32F09xxx bootloader is activated by applying pattern6 (described in Table 2: Bootloader activation patterns). The following table shows the hardware resources used by this bootloader."

Pattern6
Boot0(pin) = 1, nBoot1(bit) = 1 and nBoot0_SW(bit) = 1
nBoot0(bit) = 0, nBoot1(bit) = 1 and nBoot0_SW(bit) = 0
Boot0(pin) = 0, nBoot0_SW (bit) = 1 and main flash empty

The STM32F051 is activated using pattern2:
Boot0(pin) = 1 and nBoot1(bit) = 1

[LHelge]

I know there is an undocumented bug/feature on the STM32F042 chips where the bootloader internally checks the BOOT0-pin on startup and freezes up if it isn't set to 1. This creates a lot of problems if you're trying to jump to the bootloader using software. Perhaps it's the same with the STM32F09x

One thing that works is to conenct a small capacitor to the BOOT0-pin and a weak pull-down resistor. To get to the bootloader you configure the BOOT0-pin as an output and pull it high to charge the capacitor for a short period of time and then reset. The capacitor will keep it high for long enough to get past the part of the bootloader which checks the state of the BOOT0-pin.

[nctnico]

Time to get back on this: it turned out the board I had on loan had been used for other software experiments which for some reason prevented the bootloader from working properly. A different board worked OK.