Peripheral interrupt setting with S112

[yf13]

Hi,

It seems that s112 soft device uses IRQ level 0,1,4 of nRF52832.

By default my counter has default IRQ level 6, my concern is about the delay of COMPARE interrupt by s112? Will the delay be smaller when I set counter IRQ to level 3? 

If my counter interrupt handler is fast (mainly a nrfx_spim_xfer() and app_sched_event_put()), can I set its IRQ level to level 0 or 1 as well to avoid delay by s112?

Regards,

yf13

[Vidar Berg]

Hi,

Do you have a certain timing requirement you need to meet? The Softevice is idle most of the time, so the timing impact is generally very low. You can read more about it in the "Interrupt model and processor availability" section of the Softdevice specification document.

[yf13]

My app collects data samples at 16000hz, my IRQ will be triggered when the DMA buffer is fully loaded by the last sample.  Thus before the next samples come in 1/16000sec=60us, my IRQ needs be finished so that the new SPIM xfer can be setup, otherwise the old SPIM xfer may corrupt memory.

So from this regard, the timing requirements for the IRQ seems shall be less than 60us. Will this be possible?

[Vidar Berg]

The 60us timing requirement will not be guaranteed with the Softdevice enabled, unfortunately. However, I think you should be able to reduce this requirement significantly by changing the way you use the SPIM. You can, for instance, connect the TIMER COMPARE event directly to the  SPIM start task through PPI. DMA double buffering and list feature will also help offload the CPU. I would recommend you to take a look at the  Advanced usage section of the SPIM driver if you haven't done it already. Also, the PS for a more low-level description of the peripheral: SPIM — Serial peripheral interface master with EasyDMA

[Turbo J]

Setup the SPIM transaction beforehand, use a PPI channel to actually start it (triggered via GPIOTE).

[yf13]

I have been using PPI to control the data collection in batches. The problem is that when the SPIM list buffer is full, the COMPARE interrupt happens and my IRQ is called. Within the IRQ, I must setup new SPIM list within 60us otherwise I am afraid the new data will cause old list to grow beyond allowed buffer. So offloading data collection to PPI doesn't solve the IRQ delay issue.

If 60us is too tight for s112, how about 120us? 

[Turbo J]

You can setup the easydma stuff in advance as the registers are double buffered.

The caveat is you need to wait for the STARTED event.

It it propably a good idea to handle this event in the SPIM interrupt and put the new DMA buffers in those TXD.PTR and RXD.PTR registers.

This way the only thing that requires 60µs timing is the actual PPI event itself.

[yf13]

To avoid interrupt CPU too much, I am using repeated SPIM with array list and use a counter to counter SPIM  END events and then interrupt CPU.

According to your description, I probably need another counter B for the STARTED events and in the IRQ handler B to setup the new xfer registers? won't the IRQ B gets delayed by higher priority interrupts of s112 for more than 60us?

[yf13]

Though I can't get clear info about the maximum IRQ delays caused by s112, so far with slower sampling rate everything looks fine. I would like to put this ticket to monitoring status but don't know how yet.

[Vidar Berg]

yf13 said:

Though I can't get clear info about the maximum IRQ delays caused by s112,

ISR (priority 0) processing times are specified for given Softdevice events: Bluetooth Low Energy processor usage patterns

[yf13]

Thanks for the highlights. Now I can see that the maximum delay is within 250us, as shown in the tISR(0),PostProcessing row.

I will close this ticket.