Skip to main content
J
JPatr.3
Visitor II
April 19, 2022
Solved

No response from bootloader after entering

  • April 19, 2022
  • 2 replies
  • 1782 views

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.0693W00000LyMK2QAN.png 

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.

    This topic has been closed for replies.
    Best answer by Tesla DeLorean

    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?

    2 replies

    T
    Tesla DeLoreanAnswer
    Graduate II
    April 19, 2022

    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?

    J
    JPatr.3Author
    Visitor II
    April 20, 2022

    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!

    Terms & ConditionsAccessibility statement