2023-04-26 03:35 AM
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:
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.
Solved! Go to Solution.
2024-07-29 04:48 AM
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.
2023-04-26 05:52 AM
Better to enter at Reset Conditions, via NVIC_SystemReset and immediate branch, not trying unwind the application state, clocks, etc.
Part starts from HSI
2023-04-26 11:44 PM
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.
2024-07-29 04:48 AM
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.