I want to use the stack pointer monitor to determine which thread crashed the system as explained in the following discussions
But it seems there is no stack pointer monitor in RA4M3. Can anyone suggest an equivalent mechanism to trace the same thing?
The Cortex M33 has the stack limit checking as part of the CPU core, so there is no need for a separate peripheral
Arm Cortex-M33 Devices Generic User Guide r1p0
The Core will generate a UsageFault exception :-
Did you enable the fault handlers :-
SCB->SHCSR |= (SCB_SHCSR_USGFAULTENA_Msk…
Can you provide an example of how to configure this interrupt, I can't find which IRQ is generated on the violation.
By the way, thanks for the lead.
Hi Jeremy! I added a separate function body for each exception. And each time a thread is low on the stack a hard fault exception occurs and usage fault never occurs. If I see at that time the PSP and PSPLIM registers are both identical, I know that the stack pointer limit has been violated, but I do not know which thread broke this. Can you help me solve this problem?
SCB->SHCSR |= (SCB_SHCSR_USGFAULTENA_Msk | \ SCB_SHCSR_BUSFAULTENA_Msk | \ SCB_SHCSR_MEMFAULTENA_Msk );
Thanks a lot, Jeremy!
I have enabled the usage fault handler as you showed, and I am getting inside the function body.
I have still a few doubts/questions. I want to determine the thread which has a low stack.
In the solution for RA2A1 (as I mentioned in my first question) I could see the "NMI" at the top of the call stack of the thread in the "Debug" window in e2studio and I could easily see which thread requires more stack.
but here in RA4M3 the "UsageFault_Handler" is not shown on top of the call stack of the thread with low memory. So, to find out I checked the status of all the threads and only one was "Executing" and that was the one I configured with a lower stack to test this code as can be seen in the following image.
Is this the only way to find out by searching for the status, let me know?And also in the ISR function, I could only read and print (on RTT) the CFSR register once and any other read was ineffective as you can see in the image, the breakpoint it hit is the last 'else'. Can you also throw some light on this? However, the value printed is pointing to stack overflow.
In another case, I can see the correct breakpoint has hit, and the only thread in the "Executing" status is the one which has a low stack
And one more thing, how to tag you in the replies? what is your exact tag? @jeremy
Thanks a lot again!!!!
Ether use the info provided my the CPU registers :-
to workout where the exception was triggered, or use the FreeRTOS API :-
to work out the currently executing task.