STM32G03x bootloader nonresponsive after errant UART data

[chostetler]

Good day,

I have stumbled upon an issue with my device's bootloader that seems to be inconsistent with the ST documentation. 

I have an STM32G031K8T6. USART1 RX and TX are connected to an RS-232 transceiver, which is then connected to my host PC using a USB-to-RS232 cable:

[STM32G03x USART1] <----> [RS232 tranceiver (MAX3232 equivalent)] <---> [FTDI RS-232 USB cable] <---> [Host PC]

I would like to use the bootloader to upload firmware to the device, over this UART link. Normally, this works just fine. However, I have observed that the bootloader will not respond if it receives invalid data before receiving the valid 0xF7.

To reproduce "good" behavior:

1. Create an empty board
2. Apply BOOT0, and power on (bootloader mode).
3. Connect to the COM port using TeraTerm, or some other serial terminal (57600, 8 bit, even parity, 1 stop bit)
4. Don't send any data
5. Disconnect from TeraTerm
6. Attempt to connect to board using Stm32CubeProgrammer (UART, 57600, 8 bit, even parity, 1 stop bit)
7. Connection will succeed

To reproduce non-responsive behavior:

1. Create an empty board
2. Apply BOOT0, and power on (bootloader mode).
3. Connect to the COM port using tera term (57600, 8 bit, even parity, 1 stop bit)
4. Send a single byte over tera term (any keyboard press)
5. Disconnect from tera term
6. Attempt to connect to board using Stm32CubeProgrammer (UART, 57600, 8 bit, even parity, 1 stop bit)
7. Connection will fail with error: "Error: Activating device: KO. Please, verify the boot mode configuration and check the serial port configuration. Reset your device then try again..."

When I observe the communications with a logic analyzer, I see that the device responds like normal in the first instance, but in the second response the device does not respond at all - neither when the bad data or the good 0x7F is sent afterwords.

But my reading of the documents seems like this shouldn't matter. The flow chart in section 44.2 of AN2606 shows that the bootloader should just ignore the errant byte and continue listening for the 0x7F, but it doesn't.

Obviously, one solution to this is just "don't send bad data". But I have a Desktop program that is unable to determine whether it is connected to the bootloader or to the application. 

Any idea what the cause could be of this, or how to work around it?

Thanks

[TDK · Accepted solution]

> Send a single byte over tera term (any keyboard press)

When this happens, the bootloader is activated and the baud rate is set to whatever width the first pulse is. Unless you send 0x7F, the baud rate will be set incorrectly and any future data will be correctly ignored.

Workaround could be to send 0x7F first.

[chostetler]

> When this happens, the bootloader is activated and the baud rate is set to whatever width the first pulse is. Unless you send 0x7F, the baud rate will be set incorrectly and any future data will be correctly ignored.

That was my initial hunch, but I made sure to set all of the COM port settings equal between TeraTerm and Stm32CubeProgrammer. Indeed, comparing the RS232 traces of 0x7A (lowercase 'z' sent by Teraterm) and 0x7F (sent by STM32cubeprogrammer), the timing is basically identical.

In fact, if the message I send through teraterm is the DEL key (0xF7), the bootloader responds properly! So it seems unlikely to be related to timing/serial port settings.

> Workaround could be to send 0x7F first.

This is probably what I will end up doing. Just wanted to make sure I wasn't missing something obvious from the documentation.

[TDK]

> In fact, if the message I send through teraterm is the DEL key (0xF7), the bootloader responds properly! So it seems unlikely to be related to timing/serial port settings.

That proves what I'm saying is true. Any other character yields an incorrect baud rate. 0x7F gives it the right one. That also lines up with the documentation.

The bootloader measures the first pulse on the channel to get the baud rate.

[chostetler]

> The bootloader measures the first pulse on the channel to get the baud rate.
I think I may be misunderstanding you. If that were the case, then 0x75 ('u') should set the baud rate correctly, because its first pulse has the same width as 0x7F (17.5μs):

But, 'u' causes the same issue as any other byte.
---
Did some more research and, yep, I just wasn't understanding properly.

For anyone looking at this with the same issue I had, it appears that my μC is using software-based auto baud rate. I didn't realize this, but this functionality always assumes that the first two pulses it receives represent the byte 0x7F, and configures the baud rate to match the time between those two rising edges (falling edges for RS232), setting the baud rate higher than it actually is. So, technically it's not measuring the width of the pulse, but rather the time delta between two pulses.

Above from AN4908

Then, (I'm assuming) it looks at that data frame using the calculated baud rate to see if it matches 0x7F. In my case, with the garbage data, it won't match, so it ignores it. But the baud rate has now automatically been set to the wrong value, and any other messages sent after this with my original baud rate will be ignored too. Only a reset will fix this.

So I guess my only real solution is to just always send 0x7F first if I can't guarantee whether I am connecting to bootloader or to application.

Thanks for the help