TMS320F28P550SG: TMS320F28P55x Unhandled Interrupt Triggered

Hi Emily,

This is certainly an odd issue. I will say, for the IFR.INT8 / and IER.INT8 being cleared, this is expected since hardware automatically clears these fields when prorogating an interrupt to the CPU. The PIEIFR8 should also get automatically cleared after the vector fetch happens. However, this doesn't explain the PIEIER8. A couple things to check:

When reading these registers in the unhandled interrupt, can you verify that the "Continuous Refresh" button in CCS is toggled on?

Could you also add a GPIO toggle in the default ISR handler to verify that the behavior is the same in standalone mode (not debugger attached)?

In Sysconfig, can you take a look at the generated code and verify that it is actually writing configurations to SCIA and not SCIC?

Emily Birch said:

I should note that I am porting code from the TMS320F280049C, using the same SCI and interrupt handling. From what I can tell, the SCI functionality/API is the same between these two processors.

Yes, the above is correct. The SCI modules on both these devices are the same. 

Best Regards,

Delaney

Hi Delaney, Thanks for getting back to me.

1. The continuous refresh is turned on, and I have tried manually refreshing, closing and restarting CCS to make sure its not a CCS issue.

2. I can let it run freely without debug, and have the GPIO configured to toggle when the spurious interrupt 88 fires. 

3. Yes I can confirm that I checked the generated SysCfg code to make sure that no other peripherals are being used and nothing unexpected is being generated.

4. I have also noticed that if i let it continue running, then other spurious interrupts occur. I see interrupt 40, 23, 64. 40 and 64 are the first interrupts in groups 2 and 5, and 23 is an odd user defined interrupt which we dont use.

I have found that the silicon errata COULD explain the issue. I have implemented the fixes described in here, but this does not fix the issue.

Errata TMS320F28P55x Real-Time MCUs Silicon Errata Silicon Revisions A, 0
SPRZ572B – APRIL 2024 – REVISED FEBRUARY 2025

One thought is that these are early uCs with issues, as this is still quite a new device. According to the PARTIDL register, my uC is an engineering sample. Is it possible to source uCs from TI that are full production samples, to rule out whether it is a silicon issue?

Hi Emily,

Thank you for your response. I can't see which Errata you have linked but is it the below?

If so, this would only apply for a interrupt nesting implementation. Have you enabled nesting in your application at all? If so, can you show me how you did the ISR code (this has to be done in a very specific way)?

I will check about the production samples question and get back to you.

Best Regards,

Delaney

Apologies for the lack of response.

So, firstly after pressing on with the rest of the ISR/UART configuration, I noticed that some critical section code was implemented incorrectly. The code was wrapped by two critical section enter calls, without an exit. Fixing this, the spurious interrupt issue appears to have gone away. Nonetheless, I intend to return to this later on to confirm this behaviour, as there does appear to be some other interrupts being triggered seemingly without cause.

In response to your last post, we do not implement nesting interrupts, however I defensively added the EDIS to the end of all interrupts as mentioned by the errata.

The errata i mentioned is document SPRZ572B, from www.ti.com/.../sprz572b.pdf

Hi Emily,

I will get back to you with another response in 1-2 days.

Best Regards,

Delaney