No source available for "<signal handler called>() at 0xfffffffe"
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2025-01-28 4:14 AM
Hello,
I have been facing this issue of "No source available for "<signal handler called>() at 0xfffffffe"" on a nucleo-h753zi board. Following are few logs obtained from STMCube Programmer.
1. Fault that is eesca;ated to a hard fault (forced)
2. Faulty called function address: 0x1BB16608
3. Fault on instruction access (IACCVIOL)
4. MMFAR: 0x0
5. R0,R1,R2,R3,R12: 0x0
SP:0xFFFFFFFC
LR:0xFFFFFFFF
PC:0xFFFFFFFE
XPSR:0x1000003
6. Debugger issue: As soon as disassembly is clicked, debug is stopped.
Note: I am trying to test CAN communication between two nucleo-h753zi boards. Code works on one of the boards.
Any help would be much appretiated.
Thanks in advance
Solved! Go to Solution.
- Labels:
-
STM32H7 Series
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2025-01-31 6:40 AM
Hello @PranavBharadwaj
Please check the faulting code and registers at the fault. Likely causes could be a bad pointer pointing to the wrong memory or exceeding that memory's limits. It is also possible that you have an insufficient stack size
Saket_Om
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2025-01-31 6:40 AM
Hello @PranavBharadwaj
Please check the faulting code and registers at the fault. Likely causes could be a bad pointer pointing to the wrong memory or exceeding that memory's limits. It is also possible that you have an insufficient stack size
Saket_Om
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2025-01-31 6:43 AM
Debugging Hard Faults:
A complex system designed from scratch never works and cannot be patched up to make it work.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2025-01-31 6:47 AM
So stack content/pointer already looks trashed. It struggles to unwind effectively.
Like it's pulling content from blank flash, or doing a context switch.
Using an RTOS?
Would suggest instrumenting code to understand the dynamic flow immediately prior to failure.
Perhaps walk the actual stack in RAM to understand most recent functions called.
Up vote any posts that you find helpful, it shows what's working..
