TMS570LS0432: Phantom interrupt handler

Hello Dmitry,

Please refer to the ways of avoiding the phantom interrupt mentioned in this application note:

http://www.ti.com/lit/an/spna218/spna218.pdf

Hi QJ,

ways from the mention application notes are taking into account.

But we are working on safety-critical application, VIM RAM is filled with a handler address, so it shall exist and shall be safe.

Therefore how we could handle it correctly, which flags has to be reset to leave ISR and continue normal execution?

Hi TI team,

do you have any information regarding correct phantom interrupt handling for successful returniing to the normal SW execution?

Thanks in advance.

Hi QJ,

pity to hear cause we are really in a difficult situation.

VIM RAM shall be filled in, phantom interrupt handler shall be available, but we do not have enough information how to handle it correctly, i.e how to reset request correctly to resume to the normal system running.

If you don't mind, I will ask some additional questions which maybe help us with phantom interrupt handling.

1. I found that INTREQ register cannot be reset directly, first of all corresponding reset source has to be cleared.

   How can I identify interrupt source in case of phantom interrupt?

   What could be the source of phantom interrupt? Only enabled channels or any of available for the MCU?

2. If we speak about phantom interrupt, do we mean only the handler which is located at offset 0x0 of VIM RAM?

   For example phantom interrupt handler is mapped also for all unused entries in HALCoGen VIM RAM configuration page. 

   Could one of them be invoked (e.g. reserved channel or any other unused interrupt vector) somehow if the corresponding channel is disabled?

3. Reserved interrupts vector which is located at the offset 0x14 (.intvecs). Could it be invoked somehow except SW mistake/bug?

4. Forcing phantom interrupt, is it possible?

Best regards,

Dmitry

Hello Dmitry,

1. Writing 1 to INTREQ will clear the pending INT request. Writing the peripheral INT flag or reading peripheral INT offset will clear the corresponding bit in INTREQ too. 

There is no way to determine the source of the phantom interrupt. The disabled VIM channels don't cause the phantom interrupt.

2. Yes, you are right. The offset of 0x00 means the the INT source can not be determined. It is called phantom interrupt. 

3. #0x14 in exception table is reserved. Cortex-Rx only supports 7 exceptions: Reset, Undefined Instruction, SVC, Prefetch abort, data abort, IRQ, and FIQ. VIM is to prioritize and control the IRQ/FIQ interrupt sources presented on the device. #14 should not be invoked except for HW bug.

4. It is possible, but it is very hard to force a phantom interrupt. 

Hi QJ,

thank you for your reply.

I have some additional comments and questions if you don't mind.

1. Writing 1 to INTREQ does not clear request. I've checked it at least with RTI interrupt.

    Also the same was confirmed here on the forum in some other topic: first of all interrupt request shall be cleared at the source and only afterwards it can be cleared in INTREQ.

    If I'm wrong, let me know please how can I clean INTREQ. Writing 1 does not work.

    And some additional subquestions:

    1.1 If I cannot identify phantom interrupt source, how can I clean the corresponding request?

    1.2 If we have only RTI interrupt enabled, does it mean that only this RTI could be a source of theoretical phantom interrupt? Or something else as well?

    1.3 Enabled ESM High NMI could be source of phantom interrupt?

2. If phantom interrupt is the interrupt with handler mapped to offset 0x0 of VIM RAM, why the same handler is also mapped to all unused vectors in HALCoGen?

3. Ok, clear.

4. I've found another topic at the forum with explanation how-to, will try.

    I hope I could raise some questions here, if it does not work for me.

Thanks for your support,

Dmitry

Hello Dmitry,

I noticed that INTREQ can not be cleared by writing "1". I will test on another device. 

Hello QJ,

Looking forward to receiving new information from you.

Thanks in advance,

Dmitry

Hello QJ,

have you had a chance to look a bit deeper to a phantom interrupt request reset?

Regards,

Dmitry

Hi TI team,

have you had a chance to investigate the topic?

Thanks in advance,

Dmitry 

Hi,

will raise the topic once again...

will raise the topic once again...

Hi TI team,

could anybody try to help me..?

Hello,

Sorry for the long thread without a resolution. Is your first question still the issue you have? That is, are you still trying to write a handler for a phantom interrupt?

Hello Sunil,

thank you for your answer.

Yep, the issue with the phantom/unexpected interrupt call is still actual.

Since we are working on DO-178 application for us it is very important to have deterministic behavior and since all vectors have to be defined (even unused), we have to know how to handle it even if probability to reach it in normal situation is almost 0.

In fact we need an handler for unused vectors which makes some troubleshooting data collection and return to a normal SW execution. And the bottleneck is exactly how to return normally from the handler, how to guarantee that wrong/unexpected request is reset by our handler.

First idea was to reset INREQ inside of the handler and just exit it. But it looks like that INTREQ cannot be reset by writing 1 there (at least I observed it with expected RTI interrupt) until request is active at the source of this interrupt. And here is something unclear - what is the source of phantom or unexpected interrupt?

If request cannot be reset by writing to INTREQ, how we can guarantee that unexpected interrupt handler won't be entered once again after its leaving?

Hi Sunil,

thank you for the answer.

We are using Hardware Vectored Interrupts Mode, sure for IRQ only. And the only one FIQ is configured - ESM High Level.

I absolutely understand that phantom interrupt is almost impossible and disabled channels probably will never be invoked.

But since we are working on a safety-critical application, it makes more sense to have a handler with predefined behavior instead of filling VIM RAM with some garbage and hoping that it will never be invoked. We are not hundred percent sure, but maybe due to some either software or hardware issue disabled interrupt or phantom interrupt could be invoked and we are trying to minimize risks in this case and keep determined behavior as well.. 

Could you please support with another couple of questions:

• You mentioned that there is no flag to clear for a phantom interrupt. Do you mean flag at source or inside the VIM?
• If this almost impossible event like phantom interrupt or unexpected interrupt has been invoked, does it make any sense to:

• Disable all disabled channel
• Reset sources of all activated channels

• I expect that phantom interrupts were evaluated at TI since the special documentation is available.
  How this interrupt influenced on a system? Did you have normal system running after its handler leaving or..?

Thank you in advance for your help,

Dmitry