• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 31 subscribers
  • Views 1152 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TMS570 VIM Parity Error Handling

Nathan Flinn
Prodigy 30 points
Other Parts Discussed in Thread: TMS570LS20216

HI there,

 

I am having a frustrating issue.  I have initliatezed the VIM and have entered code to test the VIM Parity Correction routine that I created.  I generate a parity error, which both the VIM and the ESM see.  I have loaded the FBPARERR register with the location of the subroutine to recover from this.  I see that the FIQVECREG properly displays this address to the CPU.

 

The problem is that the CPU never begins executing this code.  It simply ignores the FIQ interrupt.

 

I have triple checked that the FIQ is being enabled in the CPSR.  I have also double and triple checked all of the ESM and VIM registers that enable, map, etc.  Is there something I'm missing?

 

Thanks for all you do!

  • 0
    TI__Mastermind 22375 points

    Nathan,

    I need additional information to answer your question.

    What device are you using, and which board?

    How do you check that the CPU does not enters FIQ?

    In which mode are you using the VIM?
    1) The TMS470R1x legacy
    2) Vectored interrupts
    3) Hardware vectored interrupts (IRQ only)

    Thanks,

    Jean-Marc

  • 0 in reply to Jean-Marc Mifsud
    Prodigy 30 points

    Hi Jean-Marc,

     

    I am using the TMS570LS20216 board with a TMS570 chip.

     I am using register vectored interrupts.  By the way, I never saw a place to explicitly select 1,2, or 3 from your list above.  I instead simply enabled the VIMs registers and initalized the VIM RAM.  So far this seems to work because the FIQVECREG receives the correct ISR addresses.

    I check the CPU to see it does not enter FIQ for the VIM Parity error by verifying that the VIM FIQVECREG is set to the FBPARERR address and the PARFLG is set to 1.  I placed code in the ISR pointed to by FBPARERR that writes a RAM address with a known value that is different than its startup value (the startup value of this RAM address is set during startup).  I also put an infinite loop into the service routine which is contained in the FBPARERR.  Neither of these have anything to do with the actual ISR.  I only added them to try and see if they were ever hit.  The infinite loop is never reached, and the RAM is not written.  I have done this while the debugger is attached and while it is not.

     

    FYI, I have also turned off all of interrupt disables in the debug build options.

  • 0 in reply to Nathan Flinn
    TI__Mastermind 22375 points

    Nathan,

    1) Legacy mode:

    The CPU branches to 0x18 (IRQ) or 0x1C (FIQ) to execute the main ISR.
    The main ISR routine reads the offset register (IRQIVEC, FIQIVEC) to
    determine the source of the interrupt.
    In this mode, it is easy to check if the CPU gets the IRQ or FIQ/NMI signal by setting a break point in 0x18 (IRQ) or 0x1C (FIQ/NMI)

    2) Vectored interrupts:

    The CPU executes the instruction placed at 0x18 or 0x1C (IRQ or FIQ/NMI vector).
    The instruction should be a LDR PC, [PC,#-0x1B0], the offset indicates the relative address of the interrupt vector register (IRQVECREG for IRQ interrupt, FIQVECREG for FIQ/NMI interrupt) within the vectored interrupt manager (VIM). This register will give the CPU the address of the Interrupt Service Routine (ISR) corresponding to the highest active interrupt request.
    In this mode, it is easy to check if the CPU gets the IRQ or FIQ/NMI signal by setting a break point in 0x18 (IRQ) or 0x1C (FIQ/NMI)

    3)  Hardware vectored interrupts (IRQ only)

    If the vectored interrupt interface is enabled within the CPU CP15 R1register, the CPU reads the vector address as part of the IRQ interrupt entry, i.e. the CPU will read a vector address from interrupt vector interface instead of branching to 0x18. The VIM will provide directly to the vector interface of the CPU the address of the highest pending request.
    The CPU will branch directly to the ISR.
    In this mode, the processor state after an IRQ interrupt entry is determined by bit 0 of the interrupt vector (T flag = VECTOR[0]), i.e. the
    LSB of the vector address will determine if the first instruction of the interrupt handler is an ARM or Thumb state instruction.
    In this mode, a break point at 0x18 cannot be used. The CPU will jump directly in your handler and will not stop on 0x18.

    Will it be possible to receive your project so I can try to see what is going on.
    You can send your code directly to my email address if you don't want to post it on the forum.

    Regards,

    Jean-Marc

  • 0 in reply to Jean-Marc Mifsud
    TI__Mastermind 22375 points

    Nathan,

    What is the status on this question?

    If it is answered, can you mark it as verified?

    Thanks and Regards,

    Jean-Marc

  • 0 in reply to Jean-Marc Mifsud
    Prodigy 30 points

    It was my mistake.  I verified my code to turn on the FIQ interrupts in the CPSR, but another programmer's code was turning off the FIQ interrupts in the CPSR a moment before I triggered the interrupt.  After discovering the "Registers" view, I was able to detect this and remedy it.  Everything else I was doing was correct and lined up with what you said two posts above.

  • 0 in reply to Nathan Flinn
    TI__Mastermind 22375 points

    Nathan,

    Thanks for your update.

    Anyway, I have a concern about your problem description.

    On this device family, FIQ interrupt are treated as NMI. That means, once FIQ are enable at the CPU level (via the CPSR) there is no way to disable FIQ anymore.
    Only a reset or entering FIQ/NMI mode will disable FIQ (set the FIQ disable bit in CPSR)

    Can you check this point?

    Regards,

    Jean-Marc