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

VIM IRQINDEX - need more information

Jiri Dobry
Expert 1810 points

Hello,

We have problem with IRQINDEX reading (TMX570LS3137 silicon rev B, Herkules HDK board.).

When we read this once, it work fine.

But second try to read return 0 sometimes. It looks, that reading of IRQINDEX clear it. And Technical reference manual not uncover it.

But it is more strange:

  • Value at second reading probably depend to vector number. 3 (from RTI) is OK, but 77 and 79 (from ethernet) not.
  • When I read IRQVECREG before first IRQINDEX, then IRQINDEX is invalid sometimes.
  • When I try use "Hardware Vector Interrupt", then IRQINDEX is invalid sometimes.

How it is strange is clear on this snipplet. This code work fine for RTI interrupt 3, but fail for Ethernet interrupts 77,79

    .....
    ldr r2, IRQINDEXvector
    ldr r3, [r2]  ; <= after remove this line, it will work fine
    ldr r3, [r2]
    ....
IRQINDEXvector:
   .word 0xFFFFFE00

I found this problem when we try use  "Hardware Vector Interrupt" where few interrupts (not all) point to only one function to pass event to RTOS signal/trigger. But inside this function I need translate interrupt number to signal/trigger number and reading of IRQINDEX not work.

Jiri

PS: another minor problem on documentation: see to SPNU499A–November 2012 Table 15-10. Column "Field" contain invalid string FIRQPR, correct string is INTREQ probably.

 

  • 0
    TI__Expert 4225 points

    Hi Jiri,

    Are you using Hardware Vector Mode when you see these errors?  Sound like it is the case, but i would like to confirm with you.

    Assume it is true that you are using Hardware vector Mode, reading the IRQINDEX will not give you the accurate information of who is the source of the interrupt.

    As interrupt comes into VIM module, the IRQINDEX got updated and IRQ is asserted to CPU.  

    The IRQVECREG got updated about 2*VCLK cycles after IRQINDEX got updated.

    If there is new interrupt coming while CPU is finishing out its pipeline and memory management update, the IRQINDEX register will update again as well as IRQVECREG.

    In hardware vector mode, once the CPU is ready to fetch the ISR, it asserts the IRQACK signal.  The VIM then assert IRQADDRV to tell CPU that the address is valid and hold the vector address while CPU is holding IRQACK high.  You can see that if there is new interrupt coming during that time, the IRQINDEX got updated, but that is not matching with the IRQVEC address that CPU is fetching.

    The only way you can get around this is to decode the vector address back to the interrupt source.

  • 0 in reply to Henry Nguyen
    Expert 1810 points

    Hi Henry,

    Many thanks for answer. For clarification: we was try to use all interrupt modes:

    • Index interrupts mode - only first read from IRQINDEX returns correct value always. (Just a test. We don't want use this way, It's slowest method)
    • Register vectored interrupts - with instruction "ldr pc,[pc,#-0x1b0]" at IRQ vector. Problem is, that this read IRQADDRV and have influence to following IRQINDEX read.
    • harware vectored interrupts - looks same as register vectored intterrupt.

    I understand, why new interrupt can hide old inside registers. It not clarify, where is difference between RTI and ethernet interrupt. And why I can read 0 (zero!) form IRQINDEX inside vectored interrupts or as second read.

    But one fact is absolutely clear: We can't use VIM register value to identify IRQ request inside HW/SW vectored interrupts.

    Jiri

    PS: I sleep badly. Frankly spoken, problem is too many missing information in TRM. When I count all documentation pages (ARM+TI) its almost 10000. When I found on ARM documentation "IMPLEMENTATION DEFINED", I am very surprised if I find anything about this inside TI documentation. Usually is useful to read some RO information register from chip. And mainly: in development for secure application, it is no space for "trial and error". Therefore I am happy from this e2e TI support.

  • 0 in reply to Jiri Dobry
    TI__Expert 4225 points

    Hi Jiri,

    Thank you for your clarification and understanding.  I hope you continue to find this e2e forum to be helpful.

    You can find ARM information on the following pages (note that these are not TI nor my documents, but information i found by google search; TI and I are not responsible for this documents - just passing on the public google search information)

    http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0363e/index.html (cortex R4 TRM)

    http://web.eecs.umich.edu/~prabal/teaching/eecs373-f10/readings/ARMv7-M_ARM.pdf (ARM V7 M Arch TRM).

    http://www.cs.utsa.edu/~whaley/teach/FHPO_F11/DDI0406B_arm_architecture_reference_manual_errata_markup_9_0.pdf (ARM V7 R Arch TRM)

    when there is no pending interrupt, reading IRQINDEX will return zero.  So, if you have only one interrupt source, then the IRQINDEX will present the current interrupt.  Reading it once will cause IRQINDEX to be zero (if there is no more interrupt coming in during the time you read IRQINDEX).  Your interrupt events are asynchronous, so it makes sense sometimes you read 0x0 (after second read of IRQINDEX) or sometimes you can get a new value.

    Hope this helps.

  • 0 in reply to Henry Nguyen
    Expert 1810 points

    Hi Henry,

    Thanks for support.

    OK you wrote that " Reading it once will cause IRQINDEX to be zero". But it is not complete information again. It is true for ethernet, but not for RTI. It looks, like first is "edge" interrupt type and RTI is "level" interrupt.  But it is not significant. For us this problem is solved. By my mean, IRQINDEX value is not defined after IRQINDEX read or after IRQVECREG or inside HW vectored interrupt.

    Old/new problem is not this behavior. Problem is that this information is not in TRM or somewhere else!

    Jiri 


  • 0 in reply to Jiri Dobry
    TI__Expert 4225 points

    Hi Jiri,

    Now with the information, hope you can find a solution to fix your issue by not using IRQINDEX register with the information giving.  

    we will try to clarify IRQINDEX behavior in next TRM release.

    Now, for the IRQINDEX to be zero case, let talk about it a little more from hardware behavior.

    The VIM has internal interrupt edge detection so, regardless of level or edge trigger interrupt, it will hold the pending interrupt on rising edge and know when to clear the pending based on accessing the IRQVECREG on different interrupt mode.

    I can not fully explain why sometimes you see 0x0 return on second read of IRQINDEX and sometimes you don't.  This probably needs to be understood from how these interrupts are triggered and how async they are, are they being nested, etc.  but i don't have all of that knowledge.

    All I can say is the hardware behavior:

    - The IRQINDEX will keep looking at all pending interrupts and tries to pick the highest one and update its IRQINDEX register accordingly.

    - If there is no pending interrupt, then, the value of IRQINDEX will be 0x0.

    Hopefully with this hardware description of IRQINDEX, you can relate to your system and how these interrupts are triggered and how async they are to each other, whether they are nested or not, etc to make sense a little more of the behavior you are seeing.