• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 29 subscribers
  • Views 2032 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

RM57L843: Phantom ISR

Dmitri Zakharevski59
Intellectual 905 points
Part Number: RM57L843
Other Parts Discussed in Thread: HALCOGEN

Hello,

I have observed a Phantom ISR while running the processor. This behavior is not  documented in the RM57 errata, but is noted in the RM48 errata:

 VIM#27

Could this issue be present in the RM57 as well? What could cause the behavior observed?

I am currently violating the RM48 errata notice running with the default Halcogen GCLK (300Mhz) and VCLK (75Mhz) with hardware vectored interrupt mode. 

The errata mentioned legacy interrupt servicing mode does not have this issue, is that the recommended solution if running 2:1 ratio is out of the question? Or should the Phantom ISR just be an empty handler?

Thank you!

  • 0
    TI__Guru**** 190406 points
    Hello Dmitri,

    RM57Lx and TMS570LC4x don't have this issue (VIM#27 for RM48).

    As VIM#27 stated, under the condition (defined in VIM#27), the VIM may return the phantom interrupt vector instead of the real interrupt vector. This issue can be completely avoided if the GCLK:VCLK ratio is 1:1 or 2:1. If the ratio is >=5 for SW vector mode or >=3 for HW vector mode, the workaround is to define a empty phantom ISR (as you said).
  • 0 in reply to QJ Wang
    Intellectual 905 points
    Thank you for the Reply,

    What would cause a phantom interrupt on a RM57Lx or TMS570LC4x? The phantom interrupt was detected on an RM57L revision B.

    The only interrupts I had enabled at the time where ESM LOW and RTI. REQMASKSET0 = 0x100007
  • 0 in reply to Dmitri Zakharevski59
    TI__Guru**** 190406 points
    Hello Dmitri,

    What are the value in FIQVECREG and IRQVECREQ? The channel 1 is enabled and configured as phantom interrupt.
    Can I have your test code, so I can verify it on my bench? Thanks
  • 0 in reply to QJ Wang
    Intellectual 905 points

    Here are the values I had present:

    I dont believe having the source will allow you to reproduce this issue, this is the first time I have seen it in the RM57 in my time developing with it. It happened on a bench unit running for several days straight. It looks to be an exceptionally rare occurrence. The phantom interrupt handler I currently have will halt the processor, from reading the other Chips Errata, it seems that the best course of action would be to accept this may happen in a rare case, exit the phantom interrupt handler ASAP and continue execution?

  • 0 in reply to Dmitri Zakharevski59
    TI__Guru**** 190406 points

    Hello Dmitri,

    I tested on my RM57 Launchpad and could not reproduce the issue, but same kind of test case can produce this issue easily on RM48 board. RM57 is cortex-R5 architecture, but RM48 is Cortex-R4 architecture.  

    Can you share your test case with me? Attached is my test case running on my RM57 Launchpad.

    1423.RM57_VIM27_Test.zip

  • 0 in reply to QJ Wang
    Intellectual 905 points
    I have not been able to reproduce this issue again, and did not see it before.

    I expect this is an extremely rare issue (possibly a hardware defect?)

    I dont believe we will easily see it again, but it is possible to see it.

    What I would like to close this ticket is an advisory from TI on what to do if we see this from a safety standpoint. Should I do what the RM478 errata suggested and just return as soon as possible form the Phantom ISR? Or should execution halt and appropriate safety policy (such are rebooting) take place?

    Thanks!
  • 0 in reply to Dmitri Zakharevski59
    TI__Guru**** 190406 points
    Hello Dmitri,

    If you see the same issue next time in development stage, please save the value of the CPU registers, system registers and VIM registers etc which will help us to find the root cause. If possible, ship the board to TI to reproduce the issue. For production, please halt the execution and take the safety action such as reboot. I will keep running my code for days to see what will happen.