TIMER1 with PPI to GPIOTE

RE: TIMER1 with PPI to GPIOTE

LS — Mon, 27 Apr 2015 18:49:54 GMT

Found this in the release notes for S110 version 8.0, "The default behaviour is now that the application can use the CPU while the radio is active. In previous versions of the S110, the CPU execution was blocked by the SoftDevice during radio activity." I was using S110 V7.1, so I'm updating to 8.0.

I believe your third method is the correct approach. I can't implement it with my project, because TIMER2 is being used to time other events that start before TIMER1 and end after TIMER1 is stopped. So I'm going to implement method 2 and relax the smallest timing constraints to see if that works.

In case it helps anyone, I received another suggestion to connect an SPI channel to my GPIOTE pin and send the bit toggling pattern as bytes through SPI. This would allow me to set the speed fast enough, and control the on/off time with 1s and 0s. We may experiment with this approach in the future.

RE: TIMER1 with PPI to GPIOTE

Susheel Nuguru — Fri, 24 Apr 2015 07:15:36 GMT

you said

Every time CC[1] is reached I want to stop the CC[0] compare, check if I've sent a certain number of toggles and if so, stop TIMER1, else I'll re-enable the CC[0] compare and continue running

but you are not stopping CC[0] compare, you are just disabling its interrupt, the event will be generated anyways and through PPI and GPIOTE it will toggle the pin. Instead of just disabling the interrupt at this time, you need to also disable that compare event. you are doing things in few microseconds, yes you are very close to check its limits.

RE: TIMER1 with PPI to GPIOTE

RK — Fri, 24 Apr 2015 01:47:29 GMT

25/5 = 5microseconds = 80 clock cycles. That is probably right on the limit, it's what I guessed above. 50 for the softdevice overhead, 16 for the cortex interrupt. If you absolutely can guarantee there's nothing else will interrupt you then making your IRQ handler more efficient (no debug compile, remove the unecessary sets of the compare events to zero) you may get away with it .. or try the second method where you schedule the extra PPI to turn off the counter on the last cycle, that buys you 20 microseconds.

RE: TIMER1 with PPI to GPIOTE

LS — Fri, 24 Apr 2015 01:36:33 GMT

Thank you for the very detailed response! I'm using a period of 25 microseconds, and sub_period is equal to the period divided by a value from 1 to 5. I think I'm pushing the limits with such small timer increments. The softdevice broadcaster is only called after this cycle is complete, but it may still be affecting the timing. Let me discuss your recommendations with my team and see what we can do!

RE: TIMER1 with PPI to GPIOTE

LS — Fri, 24 Apr 2015 01:27:30 GMT

The period I have to use is fixed at 25 microseconds. The sub_period varies and is equal to period divided by a number from 1 to 5. I'm thinking I might be pushing the limits of the microcontroller since I only have a 16MHz clock.

RE: TIMER1 with PPI to GPIOTE

RK — Fri, 24 Apr 2015 00:27:00 GMT

I'm assuming that sub_period < period.

As soon as CC[1] triggers, that clears the timer (via PPI) and you have only subperiod ticks until the CC[0] compare is going to trigger the next toggle. I would assume you see this issue mostly when subperiod is small, close to zero, what kind of numbers are you using for subperiod and period?

What's likely is that indeed TIMER1_IRQ doesn't get run before the timer hits CC[0] again and you get the extra toggle. The softdevice performs regular interrupts and blocks other things happening for up to milliseconds at a time. The more the softdevice is doing, the longer it blocks things for (eg doing nothing does very little, advertising does something, sending data in a connection you can get some very long blocks). Even just having the softdevice loaded and disabled adds 50 cycles to the interrupt start time. I would estimate that in the code above with a softdevice on the chip, the interrupt + the softdevice overhead + the code before you disable the timer is around 80 cycles. That's the best case if the SD isn't servicing its own high priority interrupt when TIMER1 is raised, the worst case is milliseconds.

You gave TIMER1 an interrupt priority of 3, you could raise that to 1, but if you're talking the kind of microsecond timings you mention, as soon as you start doing things with the softdevice even at priority 1 on the interrupt you're going to have that interrupt delayed, quite possibly by enough to get several toggles of the pin before you turn it off.

Relying on interrupts for any kind of precise timing when the softdevice is running really doesn't work, not unless you're talking times of the order of 10s of milliseconds or more. Basically assume that TIMER1 interrupt can be delayed by up to 4ms in the worst cases.

Things you could try:

Raise the TIMER1 interrupt priority to 1 - but that's not going to work

Add another PPI channel to stop the timer on CC[1] compare which you only enable in the TIMER1 interrupt one cycle before remainingToggles is 0. So the final toggle also turns off the timer. That will work better, especially if the period value is close to 0xffff, but will still glitch in the worst case. The lower 'period' is, the worse it will glitch.

Use TIMER2 in count up mode triggered by CC[1] compare using another PPI, clear it, load its compare with the number of toggles you want and set up yet another PPI to stop TIMER1 when you get the compare. Now you have a solution entirely within PPI which should be immune to interrupts, at the cost of 2 timers and 4 PPIs.

RE: TIMER1 with PPI to GPIOTE

Susheel Nuguru — Fri, 24 Apr 2015 00:15:28 GMT

What are the values of your period and sub_period?

in your timer_check(), the first thing I would do inside the if statement would be to disable the timer, I think shutdown takes longer than disable. after this i would disable PPI and GPIOTE.

RE: TIMER1 with PPI to GPIOTE

Nick Pelis — Thu, 23 Apr 2015 22:42:54 GMT

But you've already incurred that overhead just by having TIMER1_IRQHandler() exist. To set a bit in NRF_GPIO->OUTSET is probably only a few instructions--an LDR to contain the new bit pattern, another LDR to contain the base address of NRF_GPIO, and an STR to store the new bit pattern at the offset in NRF_GPIO where the OUTSET field is.

RE: TIMER1 with PPI to GPIOTE

LS — Thu, 23 Apr 2015 22:24:26 GMT

My timer period is in microseconds and the time between toggles could be in nanoseconds. So ideally I'd like to avoid the overhead of toggling the pin in software, to get the most precise timing possible. If it's not possible to prevent the extra toggle I'm seeing, I may do it through software to guarantee the proper sequence.

RE: TIMER1 with PPI to GPIOTE

Nick Pelis — Thu, 23 Apr 2015 22:14:05 GMT

What's the reasoning behind having hardware toggle the pin, instead of software? You could insert code into the else clause of your if() statement in timer_check() which toggles the pin instead.