Offset in SAADC samples with Easy DMA and BLE

RE: Offset in SAADC samples with Easy DMA and BLE

Jørgen Holmefjord — Fri, 17 Apr 2020 15:05:38 GMT

1. This should prevent you from triggering the SAMPLE task while the SAADC is not started, so I believe this solution should work.

2. The frequency and length of the glitches will depend on the BLE activity and other higher priority events. But this solution will shift the sampling point around in time when you start/stop the timer, is this not a problem as long as the time between the samples is constant?

RE: Offset in SAADC samples with Easy DMA and BLE

Mike Melbot — Thu, 16 Apr 2020 17:38:15 GMT

I've just hit a similar issue.
I'm using the nRF52810. I'm using the driver to sample 4 channels (AIN0 through AIN3) at 120 Hz to a 32-sample long double buffer using TIMER1 as a hardware timer. It's very important to sample at precise intervals, so I can't trigger the SAMPLE task via software.

My PPI setup used to be:
TIMER1->EVENTS_COMPARE[0] ==== (short) ====> TIMER1->TASKS_CLEAR
TIMER1->EVENTS_COMPARE[0] ==============> SAADC->TASKS_SAMPLE

(TIMER1 is started on boot via software after the SAADC is initialized)

It worked fine apparently. however, when hitting a breakpoint or on some BLE events, the channel order gets swapped from 1, 2, 3, 4 to 2, 3, 4, 1.

Then I stumbled upon this thread and changed the PPI setup as follows:
TIMER1->EVENTS_COMPARE[0] ==== (short) ====> TIMER1->TASKS_CLEAR
TIMER1->EVENTS_COMPARE[0] ==============> SAADC->TASKS_SAMPLE

SAADC->EVENTS_END ===============> TIMER1->TASKS_STOP

SAADC->EVENTS_STARTED ===========> TIMER1->TASKS_START

(TIMER1 is not started via software on boot)

This way I prevent the SAMPLE task to be triggered before the driver swaps the buffers.

My questions:
1.- Can you foresee any further issues with this fix?.
2.- I don't care about occasional glitches in the sampling interval due to the CPU being too busy to swap the buffers and trigger the SAADC START task on time when the current buffer runs out as long as they are few and sparse. Is there potential for severe or frequent glitches with this approach, or can you suggest an alternative workaround to avoid the glitches at all?

Thanks for your assistance and take care!!

RE: Offset in SAADC samples with Easy DMA and BLE

bart — Mon, 27 Jan 2020 13:30:35 GMT

So you fixed it by calling nrf_saadc_enable() after the last nrf_saadc_channel_init() ?

Would that mean you have to disable the SAADC when you want to reconfigure channels?

RE: Offset in SAADC samples with Easy DMA and BLE

DerPMO — Thu, 16 Jan 2020 10:47:55 GMT

Since this just cost me a day of work:

This also relates to Anomaly 74 of the nRF52832!

From the Errata:

3.15 [74]

SAADC: Started events fires prematurely

This anomaly applies to IC Rev. Rev 1, build codes QFAA-B00, QFAB-B00, CIAA-B00. It was inherited from the previous IC revision Engineering C.

Symptoms False EVENTS_STARTED

Conditions TACQ <= 5 µs

Consequences The EVENTS_STARTED can come when not expected

Workaround The module must be fully configured before it is enabled, and the TACQ configuration must be the last configuration set before ENABLE.

There is a flag in the SDK to apply the workaround, NRF52_PAN_74, but from what I can see the problem still arises when the last channel to be added has TACQ >5µs and therefore the workaround is not applied!

RE: Offset in SAADC samples with Easy DMA and BLE

bart — Mon, 04 Feb 2019 08:42:30 GMT

Hi, as mentioned before in this thread, I ended up fixing it with a timeout timer. It's rather complicated, but I've never had any channel skips anymore.

I described it all in this document, with text and uml diagrams. Code can be found on the repository too, but it's part of a large whole.

RE: Offset in SAADC samples with Easy DMA and BLE

Hemabas — Sat, 02 Feb 2019 13:44:14 GMT

hey jorgen & others,

i am trying to sample 3 channels at 10khz with BLE. I have tried to do what users velitsu and Mathew have implemented (suggestion 1).

I am still seeing data swap between channels. I am sure how to increase size of buffers either.

any futher suggestions ?

RE: Offset in SAADC samples with Easy DMA and BLE

Jørgen Holmefjord — Fri, 18 Jan 2019 13:55:20 GMT

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.

RE: Offset in SAADC samples with Easy DMA and BLE

jpnio — Thu, 17 Jan 2019 22:15:20 GMT

[quote userid="14926" url="~/f/nordic-q-a/20291/offset-in-saadc-samples-with-easy-dma-and-ble/166161"]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.[/quote]

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?

RE: Offset in SAADC samples with Easy DMA and BLE

jpnio — Thu, 17 Jan 2019 22:06:46 GMT

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

RE: Offset in SAADC samples with Easy DMA and BLE

Jørgen Holmefjord — Thu, 17 Jan 2019 09:02:55 GMT

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.

RE: Offset in SAADC samples with Easy DMA and BLE

jpnio — Wed, 16 Jan 2019 19:22:33 GMT

[quote userid="14926" url="~/f/nordic-q-a/20291/offset-in-saadc-samples-with-easy-dma-and-ble/79053"]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.[/quote]

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.

RE: Offset in SAADC samples with Easy DMA and BLE

Jørgen Holmefjord — Mon, 19 Nov 2018 15:30:16 GMT

The SAADC buffer pointer is double buffered in hardware, meaning that you can set the next buffer immediately after the STARTED event is received. If you look at the implementation of nrf_drv_saadc_buffer_convert, you can see that the START task is triggered right after the first buffer is set. When you call it a second time to set the second buffer, the application will block until the STARTED event is received, before setting the second buffer. When you connect the END event to START event, the second buffer will be used without any CPU activity.

"Large enough buffers" will depend on your application. If you have high sample rate on SAADC and heavy BLE activity, you could require large buffers to make sure there is some CPU time available to setup a new buffer before the current one is filled. Lowering sample rate and increasing priority could increase the possibility for the interrupt to be handled in time, but I would not count on it without heavily testing.

RE: Offset in SAADC samples with Easy DMA and BLE

eyalasko — Sat, 10 Nov 2018 23:19:33 GMT

Hi,

As I'm experiencing same problems, I would like to try solution #1 above.

I can trigger START task on END event using a ppi channel, however I don't see how this can solve the problem as switching to the secondary buffer (nrfx_saadc_buffer_convert()) runs within SAADC interrupt handler.
So DMA will be 're-armed' (on START event) in real time but it will overwrite the original buffer rather than the secondary buffer if interrupt is delayed...

What did you mean when recommending using "...large enough buffers" ?

me other questions:

My use case is sampling 4 channels ('scan set') @ 1KHz. There are other interrupts on the system but these are extremely 'light'. How vulnerable my app is to the described problem?
Will lowering sample rate to e.g. 800Hz alleviate/solve the problem ? (I assume yes but want to verify)
Will setting SAADC interrupt priority to 3 (its the default, 7, at the moment) alleviate/solve the problem? I assume so but there are still SD interrupts at levels 0/1 running.

Following the '...large enough buffers' advise, I was thinking of allocating large buffers (e.g. to hold 100 'scan sets' each - buffers[2][100*4]) and trigger START task by END event(ppi). This will enable up to 99 'lost' interrupts without loosing data. The thing is that I can't find a way to tell how many saadc 'scans' were actually written to the buffer before the interrupt was triggered (ideally 1 'scan set' but up to 99 sets in this example). RESULT.AMOUNT seems to reflect the number of samples since last START and not how many were written since setting RESULT.PTR (nrfx_saadc_buffer_convert())

Thanks for any advise

RE: Offset in SAADC samples with Easy DMA and BLE

Jørgen Holmefjord — Tue, 23 Oct 2018 08:40:24 GMT

Triggering the SAMPLE task should not have any effect if there is ongoing conversion, but you will lose the sample if you expect it to fill the buffer. You can also check the STATUS register of the SAADC peripheral, to make sure that no ongoing conversions are in progress when triggering the task.

RE: Offset in SAADC samples with Easy DMA and BLE

dlip — Mon, 22 Oct 2018 18:47:01 GMT

Jorgen,

Since the CPU interrupt is low priority for option 2, it's possible that a sample task could be delayed and two triggered close to each other (i.e. before the previous conversion is complete) and wouldn't this also cause a similar buffer order problem?

RE: Offset in SAADC samples with Easy DMA and BLE

Jørgen Holmefjord — Wed, 01 Aug 2018 14:57:17 GMT

Have you tried to stop the SAADC (triggering STOP task) and setup the buffers again after you init it again? If you uninit the SAADC in the middle of a scan cycle, you might end up in the same situation, with incomplete DMA events. You should also call abort function and wait for the SAADC to complete ongoing tasks before uninit.

RE: Offset in SAADC samples with Easy DMA and BLE

bart — Mon, 23 Jul 2018 09:13:32 GMT

I ended up fixing it with a timeout timer. It's rather complicated, but i've never had any channel skips anymore.

I described it all in this document, with text and uml diagrams. Code can be found on the repository too, but it's part of a large whole.

RE: Offset in SAADC samples with Easy DMA and BLE

Omri Friedman — Fri, 20 Jul 2018 09:18:27 GMT

I am using PPI to connect END to START but i still DO see channels swaps.

I use 3 channels and i abort ADC sampling and shut down the ADC to save power/

Later on, when i re enable the sampling using the exact same code, i see one or two channels skipped so i get constant channels mismatch in my ram buffer.

The number of skipped channels depend on how much delay i add before stopping the ADC when aborting.

When i use 15us delay (exactly equal to 3 samples = 3us acq + 2 us convert x 3), i do get good results.

But this concerns me a lot since i do not understand why is that and how to make sure timing issues will not cause the problem to re appear

RE: Offset in SAADC samples with Easy DMA and BLE

Jørgen Holmefjord — Tue, 08 May 2018 15:12:28 GMT

We do not have measurements on how long time it will take from START task until STARTED event. You can test this yourself by setting and clearing a GPIO using PPI and GPIOTE, and a logic analyzer to see the time the pin is set.

RE: Offset in SAADC samples with Easy DMA and BLE

bart — Fri, 04 May 2018 08:16:32 GMT

Hi jorgen, if i look at figure 101 of PS v1.3, the next RESULT.PTR is set after the STARTED event. What I think happens for me sometimes, is that the RESULT.PTR is set only after the next START, and I guess that also leads to the same issue as reported in this forum post.

What i'm now planning to use as solution is to stop the timer that triggers the SAMPLE task, if the RESULT.PTR is not set yet a few samples before the END. In that case, i will restart the ADC. (for this to work, i was wondering how much time it can take for the STARTED event to be sent after START has been called).

If you have other suggestions, let me know :)

RE: Offset in SAADC samples with Easy DMA and BLE

Jørgen Holmefjord — Wed, 02 May 2018 08:15:07 GMT

If you trigger START task when no new buffer is "queued", the currently configured buffer will be overwritten. What do you mean by "SAMPLE before setting RESULT"? RESULTDONE is an event generated by the peripheral, it is not something you set (you can however clear it). You should not be able to get any "swaps" if using the PPI solution, as the buffer will always be ready to store samples. Please provide an example showing swapped buffers with PPI solution implemented.

RE: Offset in SAADC samples with Easy DMA and BLE

bart — Mon, 30 Apr 2018 09:30:08 GMT

Hi, this answer helped me a lot, and it seems to be working well!

I was wondering though: what will happen if the START task is triggered while, for some reason, no buffer is queued up?

***edit***

So, i checked the docs and nrf_drv_saadc.c, and it seems like things can still go wrong if you SAMPLE before setting RESULT?

I also did a test where i sample for a long time, using the PPI solution, and did manage to still get a swap.

I was wondering: will it help if i'd use the ADCs internal timer? **Edit** Ah, that can't be combined with scan mode.

RE: Offset in SAADC samples with Easy DMA and BLE

Velitsu — Wed, 25 Oct 2017 08:17:41 GMT

Could you describe the problem a bit more? Does your code take the samples correctly, but the results get mixed up? Or is there some other kind of error?

nrf_drv_ppi_channel_assign(m_ppi_channel0, nrf_saadc_event_address_get(NRF_SAADC_EVENT_END), nrf_saadc_task_address_get(NRF_SAADC_TASK_START));

This is pretty much how I implemented it, although I first alloc and assign the channels and enable when everything is in place.

I see no call to nrf_drv_saadc_buffer_convert function, that is needed to prepare the Easy DMA conversions.

RE: Offset in SAADC samples with Easy DMA and BLE

Mathew — Wed, 25 Oct 2017 00:31:39 GMT

Are you able to elaborate on the code required to implement the first solution? I have tried the code below as a first attempt, but it hasn't resolved the issue and this is probably because I haven't interpreted the description of the first solution correctly.

err_code = saadc_init();
APP_ERROR_CHECK(err_code);

nrf_drv_timer_config_t timer_config = NRF_DRV_TIMER_DEFAULT_CONFIG;
err_code = nrf_drv_timer_init(&m_timer, &timer_config, timer_handler);
RETURN_IF_ERROR(err_code);

/* setup m_timer for compare event */
uint32_t ticks = nrf_drv_timer_ms_to_ticks(&m_timer, meas_interval_ms);
nrf_drv_timer_extended_compare(&m_timer, NRF_TIMER_CC_CHANNEL0, ticks, NRF_TIMER_SHORT_COMPARE0_CLEAR_MASK, false);
nrf_drv_timer_enable(&m_timer);

uint32_t timer_compare_event_addr = nrf_drv_timer_compare_event_address_get(&m_timer, NRF_TIMER_CC_CHANNEL0);
uint32_t saadc_sample_event_addr = nrf_drv_saadc_sample_task_get();

err_code = nrf_drv_ppi_init();
RETURN_IF_ERROR(err_code);

/* setup ppi channel so that timer compare event is triggering sample task in SAADC */
err_code = nrf_drv_ppi_channel_alloc(&m_ppi_channel);
RETURN_IF_ERROR(err_code);

err_code = nrf_drv_ppi_channel_enable(m_ppi_channel);
RETURN_IF_ERROR(err_code);

err_code = nrf_drv_ppi_channel_assign(m_ppi_channel, timer_compare_event_addr, saadc_sample_event_addr);
RETURN_IF_ERROR(err_code);

err_code = nrf_drv_ppi_channel_alloc(&m_ppi_channel0);
RETURN_IF_ERROR(err_code);

err_code = nrf_drv_ppi_channel_enable(m_ppi_channel0);
RETURN_IF_ERROR(err_code);

err_code = nrf_drv_ppi_channel_assign(m_ppi_channel0, nrf_saadc_event_address_get(NRF_SAADC_EVENT_END), nrf_saadc_task_address_get(NRF_SAADC_TASK_START));
RETURN_IF_ERROR(err_code);

RE: Offset in SAADC samples with Easy DMA and BLE

Velitsu — Tue, 12 Sep 2017 10:56:31 GMT

Thanks Jørgen. I confirm that the first solution works. Triggering NRF_SAADC_TASK_START on event NRF_SAADC_EVENT_END solves the problem.