No response from bootloader after entering

JPatr.3 · ‎2022-04-19

Hello,

I am trying to communicate with the bootloader by serial.

Most of the times it works nice but sometimes it fails as I fail to enter the bootloader.

To give a context, in order to enter the bootloader I set the rts of my FTDI high (this will set the bootloader to listen) and I send the 0x7F for it to get my baudrate and enter the bootloader. Then after the ack (0x79) if I send again 0x7F I should get a response (0x1F), at least some seconds after. This works most of the times, but sometimes it just doesn't.

Any tip on what might be the cause? The image attached is a record of the data transmitted by serial.

Another issue that also occurs sometimes is, after I do that, the stm32 just gets itself out of the bootloader into the app and starts sending the regular app serial messages.

Thank you for your time and input.

Tesla DeLorean · ‎2022-04-19

It is possible to use a debugger against ROM'd code.. The code can be disassembled, reviewed, and understood, at a functional level.

Make sure you're using 8-bit EVEN parity for your messaging. Make sure the adapter has a solid clock and baud generation, check stability with a scope, and sending 0x55 'U' patterns. Check rise/fall time, capacitive load on the pins, and perhaps drop baud rates. Consider using 2 STOP BITS to insure the inter-symbol separation.

The Loader is fickle, it is looking for interactions/transitions on the pins of interest (see AN2606), it is likely to see any of these as the primary communications channel. It doesn't receive the 0x7F pattern as much as time it with a TIM in some input capture method.

Perhaps send query command pairs (command+checksum), not 0x7F patterns, after the original acknowledge.

Which STM32? Which version of the loader?

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

View solution in original post

Tesla DeLorean · ‎2022-04-19

It is possible to use a debugger against ROM'd code.. The code can be disassembled, reviewed, and understood, at a functional level.

Make sure you're using 8-bit EVEN parity for your messaging. Make sure the adapter has a solid clock and baud generation, check stability with a scope, and sending 0x55 'U' patterns. Check rise/fall time, capacitive load on the pins, and perhaps drop baud rates. Consider using 2 STOP BITS to insure the inter-symbol separation.

The Loader is fickle, it is looking for interactions/transitions on the pins of interest (see AN2606), it is likely to see any of these as the primary communications channel. It doesn't receive the 0x7F pattern as much as time it with a TIM in some input capture method.

Perhaps send query command pairs (command+checksum), not 0x7F patterns, after the original acknowledge.

Which STM32? Which version of the loader?

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

JPatr.3 · ‎2022-04-19

Thank you for your quick answer, I will try your hints!

The version of the bootloader is the 3.1 and the model a STM32H755IIT6.

Update: I already had the communication with the bootloader set to 8-bit EVEN but only 1 stop bit. Changed it to 2 STOP Bits as Tesla DeLorean advised and it is way more stable now!