2018-12-03 03:06 PM
I am trying to use the built in bootloader on an STM32H750VB over USART1. I've used the code found here to enter the bootloader,
I've been able to load code successfully using this approach. My problem is that after I power cycle the device, the bootloader no longer responds. I send 0x7F and there is no response, have repeated to no effect. I've observed hard faults on when trying to run SCB_CleanDCache(); after the power cycle, so I think it may be tied to this issue. Commenting out this line does not allow the bootloader to run after a power cycle. A software reset in my code does not allow it to run either. Everything in my code runs fine after a power cycle except the bootloader.
After a power cycle I can get the bootloader to function propertly doing one of the following,
1) Manual reset by shorting NRST to ground.
2) Connect with I-jet and perform a reset
I've noticed when the bootloader fails that the external crystal is enabled, which makes me suspect it is entering DFU mode. If this is the case I am not sure how to prevent it.
Any help is very much appreciated.
Thanks,
Erik
2018-12-03 03:30 PM
What does your design do with the BOOT0 pin. Are you pulling it high in this situations?
2018-12-04 12:52 AM
I have the same behavior. In my case noise and/or renaming communication cause
a wrong UART bootloader start condition. Monitor the bus (with a logic analyzer or oszi) during the power cycle. If there are glitches, then it is very likely that you are in the UART bootloader with a unknown baudrate.
2018-12-04 03:54 AM
Agreed, it is sensitive to pin transitions on the watched interfaces.
Consider a POR circuit like the MCP120 which holds the device in reset for 100ms or more beyond the point the supplies stabilize.
2018-12-04 08:28 AM
Thanks for the responses. The BOOT0 pin is tied to ground with a 10k resistor.
I'll order a POR chip and give that a try. Just a note, the bootloader is not entered directly after the power cycle. My main code runs fine after the power cycle, and I send the board a command to enter the bootloader several seconds later. This is when I observe no response from the bootloader. Are there downstream effects of the reset before the supplies stabilize that would not affect my main code but prevent operation of the bootloader? I've confirmed that the startup code does properly enter the bootloader when I send my main code the command by single stepping with the debugger (connect using I-Jet after power cycle without performing reset/downloading).
2018-12-04 08:44 AM
You shouldn't need to single-step. If you run from the debugger you should also be able to stop via the debugger and determine where in the ROM it is.
If the System Loader resets (say Watchdog) it will also re enter your code, instrument your own entry points so you can see what's happening without a debugger.
I don't have any H750 boards here.