HI All
Is there a way to get an interrupt when there is PRU cycle counter overflow ?
Thanks
I have the same question.
I’m using the PRU’s 200 MHz cycle counter to timestamp sensor measurements. At 200 MHz, this 32-bit counter overflows in 20 seconds. I would like to notify a C program running on the 1GHz host ARM processor as soon as it overflows.
Is it possible to configure the PRU cycle counter to trigger an interrupt in the host ARM when it overflows?
I know how to write PRU code to make the PRU trigger an interrupt in the host, but that’s not quite what I want, since my PRU will be busy doing other things. I would like the cycle counter to trigger an interrupt automatically, without the PRU having to check if it has overflowed.
Many thanks!
-Justin
I have the same question.
I'm using the PRU's 200 MHz cycle counter to timestamp sensor measurements. At
200 MHz, this 32-bit counter overflows in 20 seconds. I would like to notify a C
program running on the 1GHz host ARM processor as soon as it overflows.*Is it possible to configure the PRU cycle counter to trigger an interrupt in
the host ARM when it overflows?*
Do you mean the Cycle register (offset 0x0C in the PRU_ICSS_PRU_CTRL
register bank)? If so, this counter doesn't even wrap around (it
automatically stops when it hits 0xFFFFFFFF) much less generate an
interrupt.
I know how to write PRU code to make the PRU trigger an interrupt in the host,
but that's not quite what I want, since my PRU will be busy doing other things.
I would like the cycle counter to trigger an interrupt automatically, without
the PRU having to check if it has overflowed.
Try using the IEP timer. It will wrap automatically, and you can even
setup a configurable period by using compare register zero and setting
the CMP0_RST_CNT_EN bit. You can also route an IEP timer event
(pr1_iep_tim_cap_cmp_pend) to the ARM core to generate an interrupt.
Thanks Charles, that’s very helpful. I didn’t know about the IEP timer. TRM section 4.4.3.1 says I can hook up the IEP clock source to either iep_clk or ocp_clk. Which one of those clocks drives the PRU cycle counter?
Thanks,
Justin
Thanks Charles, that's very helpful. I didn't know about the IEP timer.
TRM section 4.4.3.1 says I can hook up the IEP clock source to
either iep_clk or ocp_clk. Which one of those clocks drives the PRU cycle
counter?
Maybe a better question is: Can the PRU read the IEP clock as
deterministically as it reads its own cycle counter (always 1 cycle)? Or
does it access the IEP clock over some bus that introduces
non-deterministic delays due to contention issues (like accessing the 512MB
RAM)? I'm concerned because I'm using the cycle counter for time-stamping
sensor and actuator measurements. If I switch to the IEP clock, I'd like to
know I'll have the same timing guarantees.
Thanks,
Justin
Interesting problem. I agree with the clock idea.
How I would do it is by looking holistically at the overall situation and getting a timer interrupt function to periodically look at the cycle counter and see if its over like FFFF0000, and if it is call the code that recalibrates it before it maxes out.
Maybe I’m saying the same thing here.
I’m attempting something very similar to what you were working on. If you are willing, please share how you eventually did this. Did you use the IEP clock or the PRU’s cycle counter? I have IEP working with the iep_clk (although I’m having terrible RPMSG problems right now).
Also, I can’t seem to correctly check the overflow bit in IEP_TMR_GLB_STS. I would bit 0 would be 1 if there has been an overflow but even at startup, when the counter only has maybe 1000 counts in it, the bit is 1 when I read it. Maybe I’m not reading it correctly?
This Might be helpful Justin
helpful https://e2e.ti.com/support/processors/f/processors-forum/209489/am335x-iep-interrupt
#Or does it access the IEP clock over some bus
Page 14 the block diagram in PRU Sub system pdf shows what’s local to PRU so I would say not possible in one cycle. I also saw a list of actual PRU cycle times perhaps in same pdf.
What ever I looked at everything is not done in one clock cycle on PRU but I’ve looked at so many doc’s I may be mistaken
Your question about clock source can be probably be best understood my reading the TRM clock section and looking at the the clicking sub system block diagram. Then maybe some code examples.
My guess is what you have is fastest for time stamps since the IRQ capability doesn’t exist like Charles said that question about clock source became don’t care.
Well the solution to the overflow was actually simple. I had used some example code from TI where they use the value 0xFFFFFFFF to clear the IEP’s counter. That didn’t really make sense to me except of course if your very next instruction was to start the timer which would cause it to overflow immediately and start counting in the main processing sequence at 0. In my case, my next step, also borrowed from their examples, was to reset the overflow event flag. Which, of course was immediately set back high because the counter incremented AFTER this reset instruction and not before. So when I issued the overflow event reset, the counter was still at 0xFFFFFFFF which caused an immediate overflow event.
Ugh. Live and learn.
Hello Walter
Which TI PRU examples are you using I’ve seen so many examples I’ve lost track. I’ve seen the archive that contains the labs1 to labs 6.
This isn’t directly from TI but I found essentially the same code on in a TI lab or online somewhere.