- Ask a related questionWhat is a related question?A related question is a question created from another question. When the related question is created, it will be automatically linked to the original question.
Hi,
I was running an application on CPU2 when an Itrap problem occurred.
As I understand it, the image above indicates that an itrap has occurred, which means maybe an illegal instruction has been executed. So I took a look at the RPC register trying to find the itrap_addr.
According to the images above, the CPU2 stopped after executed at 0x088397 where a 'break' was being executed. So why a simple 'break' can cause an ITRAP issue?
However, when I was looking through the documents, it says that the itrap address can be located in stack as 'TRAP#19' will save this value in stack. What confuses me is that when I tried to look into the stack to find this value, the 'SP' register was not pointing within the stack range specified by me.
As showing above, the 'SP' value is far greater than '_STACK_END'.
So could you guys show me the correct way to find the itrap_addr, whether it's in 'RPC' register or it's saved in stack?
What's more, the issue does not occur at the same time every run. Sometimes it occurred a few seconds after program started running. Sometimes it occurred a few minutes after. But if it occurred, it always stuck at this 'break' instruction. 'DriveAndCtrl_Timer0ISRProc()' function where the 'break' instrucation is being executed, is a CPU2 Timer0 ISR that executes every 100ms.
Thanks.
Best regards
John
Hi Karthikeyan,
Thank you for your reply.
I think the cause may not be the stack overflow, because
a) I didn't use any recursive function in my program
b) if stack overflow was the cause of it, the application should have stuck at the same place same time ever run, but instead, it ran smoothly at the beginnig, and then it jumped to itrap isr a few minutes or a few seconds after.
c) I have checked the functions involved, including ISR, and even if they are nesting, stack usage would be around 400+ bytes.
d) after moving the .stack section(512*16 in size) to RAMM0 instead of RAMLS3(configured as CLA1 data ram as well), the application ran smoothly for almost an hour(longest time ever) then the same issue occurred. Originally, '.stack' section was placed in RAMLS3 along with CLA scratchpad.
At this point i'm really confused about this issue. In one of the tests I did later on, I followed your advice adding a 'default' to the switch_case and the program magically ran approximately 30mins until the same problem occurred. Before that it usually runs 10mins before it stuck.
Is there a way to know for sure if it's a stack overflow issue, or a way to find the exact line of code that causes this?
I have encountered illegal itrap problem before. But that time, the codes always stuck at the same point and at the same time. So it was easy to debug.
BTW here is the CPU2 timer0 ISR used:
Best regards
John
