iMX6 - How to enable TCCR/TCSR event channel IRQ

[justinfarrellya]

When we are setting the Timer Interrupt Enable bit (TIE) in the ENET_TCSRn register (and all the other bits we believe are necessary) the interrupt is not firing even though the event conditions for the interrupt are being met. (We are seeing the conditions match in the counter to fire the interrupt by use of instrumentation in the kernel).

We think we are missing some other enable bit in the interrupt structure that enables this particular interrupt  further up the chain. If someone would be kind enough to suggest some (any) places (registers)  to look for enables, or can make any other sensible suggestions we would appreciate it as we are having a little snow blindness right now!

Thanks in advance,

Justin.

Note: We believe the correct IRQ is 151 ENET - MAC 0 1588 Timer interrupt [synchronous] request, enabled by TIE (as above). I am guessing part of the question/answer is are we missing an interrupt mask for this somewhere?

[davidprice · Accepted solution]

I found the problem with the missing interrupts.  The event wasn't occurring because of a behavior that I do not find any documentation for.  The ENET_TCSRn and ENET_TCCRn registers are apparently hardware reset by some mechanism which is not a power-up reset.  I suspect that it is the RESTART bit in the ENET_ATCR register.  I had set up the ENET_TCSR0 and ENET_TCCR0 registers, and I read them back to confirm that they were set up correctly.  Later when PTP was running in Linux, I found that both of those registers were 0.  There does not appear to be any code writing them to 0.  Moving the ENET_TCSR0 and ENET_TCCR0 initialization after the ENET_ATCR initialization worked correctly.  EVENTn Timer Interrupts are working, and the EVENT0_OUT is toggling as configured. 

So beware the reset side effects on ENET_TCSRn and ENET_TCCRn when other timer config registers are modified. I haven't isolated it to a specific register or bit, but it's something to do with the timer config. I assume there was probably some valid reason the hardware was designed that way, possibly to avoid spurious events when the counter is restarted/reconfigured.