2025-02-10 11:18 PM - edited 2025-02-10 11:21 PM
Hi all,
i have an issue with an STM32-H7A3, which is going into hard fault, when calling a function, which is moved to the ITCM-RAM.
I have defined a section for ITCM-RAM in the Linker-Script:
_siitcmram = LOADADDR(.itcmram); /* size of ITCM-RAM */
.itcmram : { /* ITCM-RAM Section */
. = ALIGN(4); /* Alignment: 4 Bytes - "Word" - u32 */
_sitcmram = .; /* define a global symbols at itcmram start */
*(.itcmram)
*(.itcmram*)
. = ALIGN(4);
_eitcmram = .; /* define a global symbols at itcmram end */
} >ITCMRAM AT> FLASH /* reseve memory in flash for this section */
I copy the code from the flash to the ITCM-RAM in the startup
// BEGIN MODIFICATION - STM-CubeMX Code above
/* Copy from flash to ITCMRAM */
ldr r0, = _sitcmram // start: itcmram start
ldr r1, = _eitcmram // end: itcmram end
ldr r2, = _siitcmram // size
movs r3, #0
b LoopCopyCCMInit
CopyCCMInit:
ldr r4, [r2, r3]
str r4, [r0, r3]
adds r3, r3, #4
LoopCopyCCMInit:
adds r4, r0, r3
cmp r4, r1
bcc CopyCCMInit
/* End of copy to ITCMRAM */
// END MODIFICATION - STM-CubeMX Code below
basically the code above is just a "Copy & Paste" of the section above, where the data get copied from Flash to RAM. I Just edited the names and symbols.
I got the same ruinning - with the same functions - in a Test Project without any issues. The only issue I had at the beginning in the test project was, that I did not copy the code from flash to the ITCM-RAM, but when I did that it worked as intended.
But in this case i can litterally see, that somthing is wrong, because when I step through my code in the debugger, I can not jump (with "step into (F5)") into the function. The debugger simply steps over and quickly goes into hard fault. So my asumption is: for some reason the code is not copied into the ITCMRAM, and the copied functions seem to have the address 0x00 - which is the reason why it goes into hard fault quickly.
Obviously I am missing something. But I don't know what. Can anyone help me out?
Additional Info:
In the CubeIDE Memory Details, I can see the code that should be in the ITCM-RAM is allocated in the ITCM-RAM. There is also a ITCM-RAM section in the flash, where the code that gets copied is stored.
Solved! Go to Solution.
2025-02-11 10:04 AM
While debugging, in the Memory Browser tab, view the ITCMRAM (0x0 address) and right click the word that gets modified and selection "Add Watchpoint (C/C++)...". That will add a breakpoint that gets hit when it's modified.
2025-02-11 10:12 AM - edited 2025-02-11 10:15 AM
Thanks for that hint! It definitively helped me to debug! I did not know before, that I can set breakpoints there, too!
I have not yet found the issue, but sooner or later i will catch that bugger! It makes very easy to find out where a specific memory position gets changed!
2025-02-11 10:51 AM
Okay and Oh my gosh ... I found the root cause.
Thanks to your hint with the Memory watchpoints, I could trace back where the one value in the ITCM was changed.
That value corrupted a function in the ITCM (that's why the flash is read only ...), which caused the hard fault very quickly.
The error was in front of the monitor (me), and it was as you suspected: there was an uninitialized pointer ...
The reason why it worked in project A, but not in the new projecct was simply: in Project A this pointer was initialized correctly.
At least I learned a lot today about the startup script and learned a new and very powerfull way to hunt down wild pointers. Beeing able to fill the memory section with 0x00 with your code is very helpful, too! Thanks again for your support!