STM ROM Bootloader on STM32F217VGT

[MFC2]

I'm working with a STM32F217VGT that has Bootloader version 3.1. I'm experiencing issues with the ROM'ed bootloader provided by ST. The issue is the Bootloader is unresponsive to UART1, the desired interface to communicate with the bootloader. We know UART1 works properly as it's a comms interface we use and get correct TX/RX from. I'm able to initiate the Bootloader in 2 ways.

Method 1: power device off, configure BOOT0 such that it'll be HIGH on power up and BOOT1 will be LOW on power up, then power ON the device. With this approach the device usually is successful at communicating over UART1 while in the Bootloader and has been able to write a new firmware image and jump to it, when we have our main boards running separately from our production unit. When we have our main board running within our production unit this method only works ~10-25% of the time.

Method 2: jump into the System Memory address from our firmware during run time. Way 2 is successful at entering the Bootloader, as specific buttons that should illuminate LEDs in our firmware do NOT illuminate the LEDs after we command our FW to jump to the System Memory address. However, though we're in the Bootloader ~99% of the time we're unable to talk to the Bootloader from UART1, whether our main board is running separately from our production unit or if it's running within our production unit.

This leads us to think that there's noise on the other interfaces that could be used to communicate to the Bootloader and that the noise on those interfaces produces the 0x7F byte that initiates Bootloader communication with that port, ultimately preventing us from communicating via UART1 interface.

Is there a way to force ST's ROM'ed Bootloader to only listen to 1 comms interface while in Bootloader?

[TDK]

> This leads us to think that there's noise on the other interfaces that could be used to communicate to the Bootloader and that the noise on those interfaces produces the 0x7F byte that initiates Bootloader communication with that port, ultimately preventing us from communicating via UART1 interface.

I would agree with this, especially as it behaves differently based on what's connected to it. Perhaps look at how each supported interface is connected and narrow down the source.

> Is there a way to force ST's ROM'ed Bootloader to only listen to 1 comms interface while in Bootloader?

Not really. You could disassemble the bootloader and jump specifically to the point where it thinks USART1 is active, but that would take some effort.

[MFC2]

@TDK​ 

> I would agree with this, especially as it behaves differently based on what's connected to it. Perhaps look at how each supported interface is connected and narrow down the source.

We've removed any circuitry connected to the other 6 pins that the Bootloader would scan (PB10, PB11, PC10, PC11, PB13, PB5, PA11, PA12) and have added 10K Ohm pull down resistors to those pins to force a known state. We left the pins for UART1 in their original circuitry so that we could continue to talk and test over that interface. With all of this in place we're still unable to talk to the Bootloader once we've entered into it. This still leaves us thinking the environment has an impact (based on my original comments on the performance differences in different environment) but given the states of the other Bootloader pins are known and effectively unchangeable it also seems to make an argument against noise on those pins being the root issue.

> Not really. You could disassemble the bootloader and jump specifically to the point where it thinks USART1 is active, but that would take some effort.

Is it possible to set breakpoints in the ROM'ed Bootloader and step through it once we enter in the Bootloader state? Does ST have any tools that would assist in such an adventure?

[TDK]

It's almost certainly possible to set breakpoints in the bootloader code in openocd or gdb, however since the source is not available, it's not going to be a pleasant experience.

You really shouldn't be getting undefined/unpredictable behavior. It's a microcontroller, so it should behave the same given the same inputs, barring things like electrical noise, but that seems like a bit of a stretch for an explanation.

[MFC2]

@TDK​ 

> It's almost certainly possible to set breakpoints in the bootloader code in openocd or gdb, however since the source is not available, it's not going to be a pleasant experience.

Okay, that's interesting to know, thank you.

> You really shouldn't be getting undefined/unpredictable behavior. It's a microcontroller, so it should behave the same given the same inputs, barring things like electrical noise, but that seems like a bit of a stretch for an explanation.

I'd agree.

Have any of the verification/test team or the development team at ST seen anything like I'm describing?