Strange Timer granularity issue on nRF53832 project

[RHTPaul]

I am attempting to use TIMER4 on an nRF53832 using SDK 12.2.0 but I seem to be running into some sort of granularity issue.

Specifically, if set up the timer with 16MHz clocking and 32 bit width and I then use compare register 1, I seem to only get a granularity of about 45 microseconds.

I am toggling a GPIO line and measuring how long it takes between the timer starting from a zero count until the compare event is received using an oscilloscope to measure the time difference. If I set the compare register for 60 microseconds (960) ticks, I measure the the time difference on the 'scope as 52.0 microseconds. I then tried increasing the compare register setting by 5 microseconds (80 ticks) each try. At 70 microseconds, the measured interval is 97.2 microseconds. The measured time difference remained at 97.2 microseconds for each 5 microsecond compare register value up to 95 microseconds where I stopped measuring.

I assume there is some setup value (maybe in sdk_config.h) that I need to set appropriately but I have not had any success in trying to figure this out. Any ideas on where I should look?

[Turbo J]

Are you toggeling in the Timer_IRQhandler? An IRQ handler needs at least 12 clock cycles (64 MHz main clock) for interrupt entry and exit each - and some more µs with the softdevice. Your 45 µs sounds about right when a softdevice is present.

[RHTPaul]

Yes I am toggling in the event handler and I do not have a softdevice in the project I am looking at.

[AmbystomaLabs]

You can't do that and have microsecond switching. An interrupt service request takes quite a while for a processor to handle. 12 cycles according to Turbo, but even more depending on how many local variables are in use when the request happens. The only way to do this is completely within ppi/gpiote (ie, hardware).

[RHTPaul]

OK I used the Nordic gpiote example as a basis and hacked it into my test project to toggle a debug pin when the events for two timer compare registers are reached. I can now get intervals that correcrtly track the intervals I am trying to set. I now have confidence that AmbystomalLabs is absolutely correct in asserting thatr it is necessary to use PPI/GPIOTE to get accurate intervals in the microsecond range.

I will now need to integrate such functionality into the handling of the control signals I am trying to control. Since I need to turn on and off multiple GPIO lines and, perhaps integrate this with triggering the capture of some ADC samples and turn control signals on and off when the ADC sample event occurs, I am somewhat daunted by this being new to using PPI and GPIOTE. Accordingly, I would be most grateful if anyone can provide more documentation on the use of this functionality (Nordic are execellent at documenting individaul calls and the like, but, in my opinion, not very good at documenting how to use the calls) or provide more complex examples than this simple Nordic GPIOTE example, I would be most grateful.

Thanks in advance for any additional help anyone can provide.

[RHTPaul]

I can now successfully use TIMER events to trigger GPIOTE tasks.

Looking at the Nordic SAADC example, I can see how to trigger ADC sampling from a TIMER event.

However, I cannot find anything to get an event from SAADC to trigger a GPIOTE task. Is this possible? If so, how do you do it?

[AmbystomaLabs]

I'm not sure what function you are trying to implement.

The outcome from the SAADC is a 16bit word, though it could probably get passed via DMA to a communications channel, normally software gets involved to do something with the sample. And, since this means a software handler for the SAADC, you can just trigger your GPIOTE task from there. Or, at that point you really don't need a GPIOTE task you could also just toggle the gpio using the registers.