• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 701 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.

sys_core.asm file in spna106a.zip archive contains WRITE to Readonly INTREQ Register of VIM

Pashan None
Genius 5660 points

Hello Support,

There is a file called sys_core.asm within spna106a.zip archive. [spna106a.pdf]

There is a function called _esmCcmErrorsClear_ within sys_core.asm file.

In that function, there is a WRITE to VIM INTREQ Register.

But according to the TRM, VIM INTREQ is a READONLY Register.

So, is the code wrong or TRM wrong?

Please help.

Thank you.

Regards

Pashan

 

  • 0
    TI__Mastermind 49120 points

    Pashan,

    The TRM needs to be updated to include the write-clear functionality added to the pending interrupt status register in the VIM. Thanks for identifying this issue with our documentation.

    Regards, Sunil

  • 0 in reply to Sunil Oak
    Genius 5660 points

    Hello Sunil,

    Do I have to clear INTREQ Register within the Interrupt Routine before returning in order to clear the Pending Interrupt Flag?

    Please elaborate more on the INTREQ Register usage from end-user perspective because you mentioned that it is WRITE_CLEAR Register.

    Under what conditions, end-user must perform WRITE_CLEAR to INTREQ Register?

    Any more information will be helpful for debugging my code.

    Thank you.

    Regards

    Pashan

     

  • 0 in reply to Pashan None
    TI__Mastermind 49120 points

    Hello Pashan,

    The INTREQ flag gets cleared under either of the following conditions:

    1. In hardware vectored mode of operation, when the CPU fetches the ISR using the address provided by the VIM
    2. Reading the IRQVECREG or FIQVECREG register using the "ldr pc, [pc, #-0x1b0]" instruction at addresses 0x18 and 0x1C
    3. Reading the IRQIVEC or FIQIVEC register to determine the highest priority pending interrupt
    4. Writing a '1' to the INTREQ(i) flag. This write-clear functionality is basically provided to clear the history of "pulse interrupts" that are not required to be serviced.
    It is generally recommended to write-clear the INTREQ flags for interrupt conditions that have happened prior to enabling or unmasking these interrupts.
    Regards,
    Sunil
  • 0 in reply to Sunil Oak
    Genius 5660 points

    Hello Sunil,

    INTREQ bit is edge-triggered or Level-Triggered w.r.t. ESM Error Sources [Like Group 2 Bit 2 -- CCM-R4 Compare Error]?

    I am assuming Level-Triggered.

    If it is Level-Triggered, then once I clear the ESM Group 2 Status Register, then will INTREQ Bit revert back to ZERO state and hence no subsequent FIQ Interrupt?

    I am just trying to understand the behaviour.

    Thank you.

    Regards

    Pashan

     

  • 0 in reply to Pashan None
    TI__Mastermind 49120 points

    Pashan,

    If the application follows either of the first three methods of servicing the interrupts, the INTREQ flag is automatically cleared and the application does not have to do anything else after that. The INTREQ flag needs to be explicitly cleared only for the case where the application chooses to not use the vectored mode for servicing the interrupt and does the interrupt prioritization completely in software. In this case, it is better for the application to not assume (or care) about whether a particular interrupt is indicated as a pulse or a level to the VIM. It needs to explicitly write-clear the INTREQ just to account for the possibility of a pulse interrupt.

    Regards, Sunil