cancel
Showing results for 
Search instead for 
Did you mean: 

STM32H7 System Bootloader sometimes not working

heveskar
Senior

We are using STM32H723ZG on custom board. Sometimes, we want to jump to System Bootloader (address 0x1FF09800) from our application. Then we connect to device via USB DFU. I thought that it works reliably, however we discovered that sometimes, there is a problem that the device is not enumerated correctly (STM32CubeProgrammer doesn't see it).

Additional info:

  • Bootloader version both v9.2 and v9.3
  • Preparation for jump is done almost the same as in https://community.st.com/s/article/STM32H7-bootloader-jump-from-application (note that there is wrong clearing of ICER/ICPR registers) with few additions such as disabling cache. Let me know if I should post the complete code.
  • We have BOOT pin on button to go directly to the bootloader after reset. This seems to always be working correctly. So the issue seems to affect only jumping from our application.

Furthermore, when I tried looking to bootloader operation through debugger, from the disassembly, it seems that it is not stuck and correctly checking all the available interfaces. So it seems that it just does not detect USB cable connection. But without the source code it is difficult for me to debug it further. I could post the disassembly but I think it would be of no use.

I have looked at this: https://community.st.com/s/article/FAQ-DFU-mode-with-system-bootloader-is-not-working-while-USB-does but I do not know if it is relevant. We are doing the tests in room temperature and few times it works and few times not. For the record though, we use 24 MHz HSE.

Any ideas why could this happen? This is not too painful for us since we have the button to bypass our application, however it would be nice to solve this.

1 ACCEPTED SOLUTION

Accepted Solutions
heveskar
Senior

In the end, jumping to the bootloader after reset as described above helped, but another thing that must be done is calling USBD_DeInit() (thanks to this comment: https://community.st.com/t5/stm32-mcus/how-to-jump-to-system-bootloader-from-application-code-on-stm32/tac-p/594395/highlight/true#M603). Those two things seem to have resolved the issue for good.

View solution in original post

3 REPLIES 3

Better to enter at Reset Conditions, via NVIC_SystemReset and immediate branch, not trying unwind the application state, clocks, etc.

Part starts from HSI​

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

But isn't the System Bootloader supposed to work correctly even when jumping to from the application? I agree that doing the jump from Reset Conditions might be easier though.

Anyway, I tried your suggestion of entering right after reset by NVIC_SystemReset() (from main() before system initialization) and the issue seems to persist, sometimes device is enumerated sometimes not. Only thing I am doing before is checking a variable in DTCMRAM that tells me to jump to the bootloader.

I think it must be some software error on my side, as booting directly to the bootloader using BOOT pin seems to work well every time.

heveskar
Senior

In the end, jumping to the bootloader after reset as described above helped, but another thing that must be done is calling USBD_DeInit() (thanks to this comment: https://community.st.com/t5/stm32-mcus/how-to-jump-to-system-bootloader-from-application-code-on-stm32/tac-p/594395/highlight/true#M603). Those two things seem to have resolved the issue for good.