cancel
Showing results for 
Search instead for 
Did you mean: 

Default bootloader characteristics

NSR
Associate III

I have a project that inadvertently appears to have what looks like the bootloader area.

I'm using STM32CubeIDE and when I program the board from the IDE, it runs fine and all is ok. If I press the reset button then the board ceases to run.

I've duplicated the debug session to allow me to attach while the board is running. After the compiling and programming the board from the IDE. I can see it running as expected and attach the debug session without a problem. If I press the reset button then attach the debug session, I get the following message:

Break at address "0x1ff09c94" with no debug information available, or outside of program code.

I understand that the main reset part of this area is generally handled via a jump to 0x1ff09800.

I'm using an STM32H750 on an in-house developed board. The reset button pulls NRST to ground. I've checked the option bytes against another board that has previously worked ok and they are the same. I've not programmed the other board as I don't want to unnecessarily leave a trail of dead boards

1 ACCEPTED SOLUTION

Accepted Solutions

Make sure BOOT0 is pulled low externally in your design.

The H7 latches behaviour at a power-on-reset differently than via NRST, so if the FLASH is empty/invalid it is likely to keep going into the ROM boot loader until you cycle the power.

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

2 REPLIES 2

Make sure BOOT0 is pulled low externally in your design.

The H7 latches behaviour at a power-on-reset differently than via NRST, so if the FLASH is empty/invalid it is likely to keep going into the ROM boot loader until you cycle the power.

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

Thanks for this suggestion. I cleaned around the BOOT0 jumper switch and that appears to have solved the problem - it must have kept starting in DFU mode. There's another board that has the opposite problem, trying to get it into DFU mode results in having to sometime apply to the jumper. Such are the niggles of in-house produced prototyping and development.