2024-07-20 05:34 PM
Hey St Forum,
Just getting a new project off the ground, and working with the STM32H7S7 Dev Kit.
So far, I've been able to get some example code up loaded into CubeIDE, and upload to the board.
However, when I try and debug, I get this error:
Viewing the ASM shows that we're getting hung up on a b.n instruction very early in program memory:
I'm not 100% sure what this means.
It seems that this is some kindof width check instruction,
But I'm not sure why it would be referencing it's own instruction address.
After I disconnect the power from the devboard, and plug it back in, the firmware runs fine.
I'm doing the GPIO example, where LD 1 -> 4 all flash in 100mS delays.
Before this I did have to specify that I needed to load the program from external flash.
I followed this thread for that advice.
But, they recommended using an "ExtMem_Boot" for there example, which is missing on the STM32H7S78 example selection.
My switch and jumpers are also all set to the correct configuration detailed in the User Manual.
Thanks,
-Hal
Solved! Go to Solution.
2024-07-29 10:42 PM
You've loaded ST's XIP (execute in place) boot code into internal flash. You've linked your app code to execute from external flash. Your debug configuration specifies an external loader (for STMCubeProgrammer) to write it to external flash.
After loading, the debugger would set a breakpoint at main's address and should then reset the core and break when it arrives there. But for some reason it does sigtrap and stops at 0x80060c4 instead. I guess it's a bug with the debugger. A click of the "Reset the chip and restart debug session" button will recover it and it'll stop at main.
2024-07-29 10:42 PM
You've loaded ST's XIP (execute in place) boot code into internal flash. You've linked your app code to execute from external flash. Your debug configuration specifies an external loader (for STMCubeProgrammer) to write it to external flash.
After loading, the debugger would set a breakpoint at main's address and should then reset the core and break when it arrives there. But for some reason it does sigtrap and stops at 0x80060c4 instead. I guess it's a bug with the debugger. A click of the "Reset the chip and restart debug session" button will recover it and it'll stop at main.
2024-08-01 05:52 PM - edited 2024-08-01 05:55 PM
This seems to do the job! Not sure why the debugger isn't just resetting on upload, is there something I can configure in a debug configuration to make that happen?
Just found this option in the debug configuration, I was using "connect under reset" instead of "Software system reset". Everything seems to be working as expected.
Now I have to see if I can get this to boot from internal flash instead of external.
Thanks for the reply!