Offset in SAADC samples with Easy DMA and BLE

[Velitsu]

I have a nrf52 application that samples four saadc channels at 1kHZ. That is: Map four pins to ADC input and let Easy DMA take care of the sampling so that the data is processed ten times a second (100 * 4 samples). This works pretty well, except...

When I enable the BLE connection, the data is shifted in the buffer. Without BLE enabled, the data layout in the memory is as following {{1,2,3,4}, {1,2,3,4}, ...}. But, when BLE is activated, the memory layout is: {{4,1,2,3}, {4,1,2,3}, ...} I really don't know what causes the difference. I have no way to check if the data is shifted, or did the samples just swap places. I wonder if the softdevice blocks some of the samples that would cause the problem.

The saadc implementation is double buffered, like in "saadc_sample_from_two_pins - scan mode" here

The BLE implementation is based on ble_app_hrs_freertos in SDK 12.1.0. That is also the SDK version I'm using.

Any help would be appreciated.

[Jørgen Holmefjord]

Hi,

There have actually been some progress with this issue. The reason why this swap/shift in the buffer occurs, is related to how samples are triggered, and how events are handled.

The EasyDMA chapter in the SAADC documentation show the order of tasks and events for proper operation.

The problem arise when the SAADC is configured in continuous mode using PPI to trigger the SAMPLE task at a regular interval, while the END event and START task is handled by CPU interrupt. When the SAMPLE task is triggered, each channel is sampled and written to RAM with DMA as fast as possible. When the buffer have been filled, the DMA transfer will be delayed until the START task have been triggered. You are triggering the START task in the interrupt handler after receiving the END event. If you receive the END event when IRQ is disabled or an interrupt with higher priority is executing, the triggering of the START task can get delayed until after the SAMPLE task have been triggered using PPI. Triggering of the SAMPLE task will generate a DMA transfer request, but this request will not be acknowledged until the START task have been triggered. The scan cycle of the SAADC will however expect the DMA transfer to finish, and will sample next channel. When the START task is triggered, the pending DMA transfer will be executed, but the transferred sample will correcpond to the latest sampled channel. Samples from previous channels will have been lost.

There are two possible solutions to this problem:

1. Use PPI to trigger START task on an END event. This will avoid the delayed triggering og the START task due to a queued interrupt generated by the END event, but in the case of high sample frequency and long delays, it can cause your buffer to be overwritten before you are able to process the buffer. In case of using this solution, it is neccessary to use double buffering and large enough buffers to avoid data loss.
2. Trigger sampling from CPU interrupt. If the SAMPLE task is triggered from an interrupt with lower priority than the SAADC IRQ handler, the START task will always be triggered between an END event and a new SAMPLE task. This solution will make the sampling vary a bit in time, as higher priority tasks can cause the triggering of SAMPLE task to be delayed.

This is a typical case of hard real-time requirements, that cannnot be guaranteed with a task/event based system. Since many users are experiencing this issue, we will try to update the documentation to make this requirement more visible.

Best regards,

Jørgen

[jpnio]

Jørgen Holmefjord said:

Trigger sampling from CPU interrupt. If the SAMPLE task is triggered from an interrupt with lower priority than the SAADC IRQ handler, the START task will always be triggered between an END event and a new SAMPLE task.

Can you elaborate on this strategy?  What source interrupt can/should be used for regular sampling of the ADC?  Need to sample continuously at something like 20 Hz and avoid this swapping issue.

[Jørgen Holmefjord]

RTC or TIMER could be used for regular sampling. The point is to not trigger the sample task using PPI, but trigger it manually in the interrupt handler/driver callback for the RTC/TIMER peripheral.

Are you seeing the issue at 20 Hz? I would not expect this to be a problem with double buffering and buffers large enough to hold some samples for each active channel.

[jpnio]

Thanks for your speedy response Jørgen.  Your help is much appreciated.

Yes, we are seeing this issue when sampling at 20Hz.  

I have attempted a solution using a nrf_drv_timer_t but I am confused on one important point:  The SAADC is by default, a priority of 6.  I create a hardware timer on channel 2, but, It seems I cannot run a timer with a priority lower (numerically higher) than 6!  See this:

nrf_drv_common_irq_enable.c

#ifdef SOFTDEVICE_PRESENT

    ASSERT((priority == APP_IRQ_PRIORITY_LOW) || (priority == APP_IRQ_PRIORITY_HIGH));

#endif

This blocks my timer config from setting the priority lower than the ADC:

nrf_drv_timer_config_t timer_cfg = NRF_DRV_TIMER_DEFAULT_CONFIG;

timer_cfg.interrupt_priority = APP_IRQ_PRIORITY_LOWEST;

So... I am at a loss on how this solution could work if I can't set the priority of the timer task to APP_IRQ_PRIORITY_LOWEST

[jpnio]

Jørgen Holmefjord said:

Are you seeing the issue at 20 Hz? I would not expect this to be a problem with double buffering and buffers large enough to hold some samples for each active channel.

We are using double buffering but each buffer is only 3 in size (because we're sampling from 3 channels... vdd, bat, and a motor).  

It's unclear to me - with my current understanding of how this issue manifests - how increasing the buffer size solves the problem?  I thought this was a timing issue essentially? 

[Jørgen Holmefjord]

Which SDK version are you using? For nRF52 series, priority level 2, 3, 5, 6, and 7 should be available to the application.

Yes, you are correct. The larger buffer size should not eliminate the issue, only delay it. I was thinking that the SAADC would be started when the first buffer is filled, but this would require implementing solution 1.