TMS320F28032: What causes the following two interrupts to enter?

Hi Everyone，

     (6) TMS320F28032: Add ERTM to the first Line in the Main function, will affect the chip's functionality ? - C2000 microcontrollers forum - C2000︎ microcontrollers - TI E2E support forums

    The problem comes from the above, but it is different from the above problem.

Hi Shaoxing, I'm trying to identify who is best equipped to help with this issue.  You should see a response by Wednesday.  Thank you for your patience.

Regards, Joe

Hi Shaoxing Ke,

The EMUINT is not expected to trigger in a normal application, please see this post.

https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/841826/tms320f28377d-what-condition-does-emuint-occur-in-the-tms320f28377d-chip

Based on the fact that both EMUINT and USER1 ISR are being triggered it appears that likely the application is executing unexpected code. I can't find any documentation that links the ERTM to any of these interrupts.

Here are some suggestions to identify what instruction is triggering these ISRs:

1. If you are able to reproduce the issue with debugger attached, as suggested in the above E2E post, the for loop can be removed from the ISR code and when the core halts at the ESTOP0, the user can step past the ESTOP0 to see where the application returns.

2. If this is seen only with the debugger disconnected then you will need to backtrack the stack to find the return address. The section 3.5.2 of the C28 CPU document shows where in the stack the return address is saved before entering the ISR. Please also refer to the assembly generated for the ISR as the compiler may also additionally push some registers to stack and update the stack pointer. The ISR code can be updated to find the return address from stack and save it to a global variable that can be output over COM port or read back by connecting debugger (remove GEL files before connecting CPU to prevent debugger from issuing CPU reset) and loading symbols.

Thanks,
Ashwini

Ashwini Athalye said:

1. If you are able to reproduce the issue with debugger attached, as suggested in the above E2E post, the for loop can be removed from the ISR code and when the core halts at the ESTOP0, the user can step past the ESTOP0 to see where the application returns.

Hi Ashwini,

     When connected to the emulator, the chip will not have such a problem. And backtrack the stack to find the return address is point to what？

    Does Check the return address do anything? And ERTM is added to the first Line in Main

Hi Shaoxing,

Shaoxing Ke said:

And backtrack the stack to find the return address is point to what？

We can see what address/instruction triggered the ISR to see if that gives us any clues.

I will try and loop in some experts on the ERTM behavior. In the meantime, is there a need for adding the ERTM at the start of main - it will be good for us to understand the use case for this situation.

Thanks,

Ashwini

Hi Ashwini,

     As ERTM is added to the first Line in Main, so it will randomly enter one of the following two interrupts: interrupt void EMUINT_ISR(void)  and interrupt void USER1_ISR(void). And when connected to the emulator, the chip will not have such a problem. So customer only load symbols to view the Code.

     So the customer wants to know clearly what method can be used to judge the interruption mentioned above, or is there an explanation?

Shaoxing,

We're going to loop in some additional team members from the TI India team.  Please expect a reply by early tomorrow 10/20.

Best,

Matthew

Shaoxing,

I've just started looking on to this, will get back to you by tomm after I get a hand on looking at the thread in detail.

Shaoxing,

What you have explained doesn't look straight forward for me to root cause the problem. So few more questions to you.

I assume you are getting on to these ISR's when you run without debugger being connected.

If yes,

a. are you seeing this struck in that ISR even before you attempt to connect (I mean you have some way to make sure whether code is running properly via a GPIO toggle or any comms or by some means which shows the code is struck even before you attempt to connect)

OR

b. Whenever you attempt to connect, you are seeing it ending up in of of these ISR's ?

If the answer to above question is 'a', then please help us with the contents of memory location starting from 0x800 to 0x810 when that issue is seen.

Hi expert，

     Customers check the running status through Load Symbols, and I will let Customers see the contents when issue occurs. 
     Sorry for the long delay in this information，we also intend to convince customers from the perspective of ERTM not being used normally.

Hi Experts,

     Can you give me more explanation about 0x800 to 0x810？

Hello Shaoxing,

These are some of the debug status registers which are generally not documented for normal usage.

Hi Experts,

     The customer cannot view the faulty unit through the link emulator at this time, can you tell me if there is a better way to locate it than other or other?

Shaoxing,

What do you mean by Faulty unit ? you mean to say you are unable to connect to the debugger after these interrupts are fired ?