TMS320F28335: Illegal instruction entered ILLEGAL_ISR interrupt

Hi Cherry,

I apologize for the delayed response. Please can you confirm my understanding of what is happening:

1. Illegal ISR is entered

2. The RPC points to MOV32 instruction after call to sqrt

Question customer is asking is why is the illegal ISR being called - illegal instruction or addressing mode.

I assume since the failure happens after some time and that this code executes fine most of the times.

Thanks,
Ashwini

Hi Ashwini,

Thank you for the support.

Ashwini Athalye said:

Please can you confirm my understanding of what is happening:

1. Illegal ISR is entered

2. The RPC points to MOV32 instruction after call to sqrt

Question customer is asking is why is the illegal ISR being called - illegal instruction or addressing mode.

Yes correct, from the current register values, the customer suspects an illegal ISR interrupt was entered while running sqrt.

Thanks and regards,

Cherry

Hi Cherry,

When a TRAP ISR is entered the return PC is saved on the stack and not RPC. Can you halt at the start of the Illegal TRAP ISR and read the stack for the return address. The CPU Instruction Set document section 3.5.2, table 3-5 has information on which location on stack has return address.

https://www.ti.com/lit/spru430

Customer will need this return address to know where the illegal instruction occurred. RPC only has return address of an LCR instruction hence pointing to the instruction after the LCR and not relevant for last executed instruction.

Thanks,

Ashwini

Hi Ashwini,

I'll try to clarify the case here, 

The above screenshots contain stack information when entering an illegal interrupt and the customer has learned from the spru430 doc that the PC pointer before the jump is 0x117701 which appears to be an illegal address. This is also the direct cause of an entry abort. Depending on the RPC value, it can be further confirmed that the PC value in the sqrt function points to 0x117701. This is because the value of RPC will only equal 0x300A1D in the sqrt function, and the probability of this occurring is very low.

So the customer would like to know under what conditions would cause the PC pointer to jump abnormally to 0x117701 when running in sqrt function?

Thanks and regards,

Cherry

Hi Cherry,

I cant spot anything in the SQRT function that could cause any issue, only situation is a stack overflow occurring but that would be outside of the sqrt - so maybe some spurious interrupt.

Regarding the illegal address, can we double check that the address is 0x117701. For ISRs ,the compiler generates some instructions to save to stack before the customer ISR code, when backtracking the stack to get the return PC did the customer look at the assembly and walk the stack to arrive at right address?

Thanks,

Ashwini 

Hi Ashwini,

The customer has tried to modify the ILLEGAL_ISR content to see the returned PC value obtained, but if the original contents of the ILLEGAL_ISR are modified, the problem does not occur.

The above figures show the status of the stack, which, according to the doc, is due to the INTR instruction being executed and some of the necessary registers are pushed onto the current stack so we can exclude the stack exception here. The stack for this task starts at address 0x8800 and is 2 KB in size.

But it is strange that this problem does not occur if only some insignificant code is modified that forces the function storage addresses of the .text section to change.

Thanks and regards,

Cherry

Hi,

May I know is there any updates?

Thanks and Regards,

Cherry

Hi Cherry,

I will loop you into the internal discussion on this topic.

Thanks,

Ashwini

Hi Ashwini,

Thank you for the help and I've double checked with Strong Zhang(TI FAE) that we are supporting the different customer so I'm wondering if you could help specify more on details regarding the latest response as below:

Cherry Zhou said:

The customer has tried to modify the ILLEGAL_ISR content to see the returned PC value obtained, but if the original contents of the ILLEGAL_ISR are modified, the problem does not occur.

The above figures show the status of the stack, which, according to the doc, is due to the INTR instruction being executed and some of the necessary registers are pushed onto the current stack so we can exclude the stack exception here. The stack for this task starts at address 0x8800 and is 2 KB in size.

But it is strange that this problem does not occur if only some insignificant code is modified that forces the function storage addresses of the .text section to change.

Thanks a lot for any information!

Thanks and Regards,

Cherry

Cherry Zhou said:

But it is strange that this problem does not occur if only some insignificant code is modified that forces the function storage addresses of the .text section to change.

Sounds like a timing loop issue, adding code .txt section slows down access Sqrt() problem loop. Hence it is often necessary to add delay time into a high-speed service loop where an ISR might randomly access LSRAM for POP/ PUSH of stack data. We noticed similar exception issues x49c often occur in slower ISR loops accessing ePIE where another high speed ISR is running background tasks. The C+ high level language seems to mask low-level instruction decoder issues when ePIE gets involved. Could it be the local bus arbitrator needs re-work? 

Edit FYI: x35 has 150MHz clock, x49c 120MHz similar timing issues exist. 

Hi,

Two interrupts are used in the project, one enters once every 0.156ms, and the other enters once every 1ms. How could he locate this problem? Or how to ensure that such problems do not occur?

Regards,

Annie

Annie Liu said:

How could he locate this problem?

 It's really hard to know without more details (C+ functions) though sounds like random ePIE or stack control issue. Customer has custom PCB? could be related to PLL clocking even XTAL bypass caps, who knows for sure. Another forum post customer emails schematic for TI engineer evaluation, a good starting point. Perhaps also check the known errata PDF x35 MCU!

Hi Annie and Cherry,

You mentioned that there are 2 ISRs. Has any SW nesting of interrupts been enabled for these ISRs or does this use default no nesting behavior (see Interrupt Nesting for reference ).

Here are a  few suggestions to help narrow down the issue:

1. In the device errata see section Memory: Prefetching Beyond Valid Memory. For sections of memory that are used for text and are next to reserved spaces, update the linker command file to change the size of the memory block so last 8 words are not allocated as explained in the errata. Then compile and re-run code, see if this resolves the issue.

If above does not , do step 2 and 3 to see if any different behavior is observed.

2. Please make sure all unused interrupts are assigned to the default ISR which has the ESTOP0. This will ensure that system halts in any unused interrupt incase that is being triggered inadvertently and also ensure that illegal trap was not entered due to escalation from an unused interrupt.

3. Use CCS option to Fill memory with ESTOP0. See this post for how to do this. Once this is done, load application. This will ensure that if any unexpected fetch is made CPU will halt right away instead of issuing illegal opcode trap and will ensure we can pin point where the issue is occurring.

If none of these help, please can you share the following so I can help confirm the return address stored on stack is illegal address 0x117701.

1. Snapshot of the Illegal ISR disassembly view from start of ISR to  ESTOP0
2. Snapshot of the registers with SP and RPC
3. Snapshot of the stack.

Thanks,

Ashwini

Hi Ashwini,

Ashwini Athalye said:

1. In the device errata see section Memory: Prefetching Beyond Valid Memory. For sections of memory that are used for text and are next to reserved spaces, update the linker command file to change the size of the memory block so last 8 words are not allocated as explained in the errata. Then compile and re-run code, see if this resolves the issue.

The customer said he couldn't understand this. Is there any other way to explain this one?

And customer said all snapshots have already been provided in the original post above. This is the customer's own board, and he believes that if it is caused by a hardware issue, it should be discovered earlier. But in reality, this problem is extremely unlikely to occur.

Regards,

Annie

Hi Ashwini,

The customer reported that his program is stored and run in FLASH, so the above problems should not occur. Could you possibly help to check it again?

Regards,

Annie

Hello Annie,

Ashwini will be out-of-office until next week, please expect a reply around Tuesday.

Hi Annie,

Circling back to this topic. Was this issue resolved for customer?

Thanks,

Ashwini