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!
2024-12-09 10:52 PM
Hello alister,
Greetings from pooja.
I am working on the USART exercise as per your suggestion using the NUCLEO-H7S3L8 board with STM32CubeIDE. I'm facing a similar issue. As suggested earlier, I updated the debug configuration to write my application code to an external loader for storing it in external flash. However, I am encountering an error: "Failed to initialize the external memory," and the reset option is also not functioning. I would greatly appreciate any assistance in resolving this issue.
Thank you!
2024-12-10 04:34 PM
This isn't what halfordC's posted about and should be a new thread.
Not reading 1MAIN_APP.C because I'm guessing the problem's occurred before the app executes.
I don't know why your app's debug configuration's external loader (uses STM32CubeProgrammer) is failing.
https://wiki.st.com/stm32mcu/wiki/Getting_started_with_External_memory_Manager_and_External_memory_loader and other places describe the following: