NCS v2.6.0
nRF52840
Hello,
I'm trying to use GPIOTE + PPI to increment a TIMER in counter mode. Then when the counter reaches a compare value in channel 0 it triggers an interrupt in software and captures a different timer that is running in timer mode.
I use this peripheral setup to increment the counter:
GPIOTE_IN--->PPI--->COUNTER_INCREMENT
and this setup to get the zephyr callback and capture the other timer:
COUNTER_COMPARE_EVENT--->RTOS callback
'--->PPI---> capture other timer
another setup I've tried in order to get the zephyr callback and capture the other timer:
COUNTER_COMPARE_EVENT--->PPI--->EGU--->RTOS callback
'-----> capture other timer
Both variations work! But only at low frequency at less than about 25kHz. I've tried setting my compare value higher, at like 10,000. It doesn't seem to make any difference.
The expected behavior is like this:
- Attach Signal generator to board at 100kHz
- Turn on program which generates interrupt after counter reaches desired number of GPIOTE edges (say, 100,000 so it would trigger after 1 second at 100kHz)
- Reach the interrupt one second after turning on the signal generator
The actual behavior is like this:
- Attach Signal generator to board at 100kHz
- Turn on program which generates interrupt after counter reaches desired number of GPIOTE edges (say, 100,000 so it would trigger after 1 second at 100kHz)
- Turn on the signal generator, nothing happens indefinitely so long as it stays on
- Turn off the signal generator, the interrupt starts immediately as if it was queued and blocked by the signal generator.
Another example at low frequency:
- Attach Signal generator to board at 20kHz
- Turn on program which generates interrupt after counter reaches desired number of GPIOTE edges (say, 20000 so it would trigger after 1 second at 20kHz)
- Successfully reach the interrupt one second after turning on the signal generator (without turning off the signal generator)
The "blocking" behavior starts at about 25kHz and above. It's almost as if there is an RTOS interrupt somewhere that is blocking the scheduler so long as the signal generator is going.
Any ideas?
Pinging Sigurd Hellesvik since he has worked with me before on this same project.
