SAADC Sampling Issue

RE: SAADC Sampling Issue

Jørgen Holmefjord — Wed, 11 Dec 2019 21:21:26 GMT

Do you have a sample application that you can share, which we can use to reproduce the behavior?

If you could also post the buffer with all the SAADC samples when this glitch happens, it would help with finding the root cause.

RE: SAADC Sampling Issue

rkb — Wed, 11 Dec 2019 01:06:41 GMT

Hi Jørgen,

I tried both of those suggestions, and I couldn't get a working solution. Moving nrf_drv_saadc_buffer_convert() call didn't seem to have an effect, likely since the buffer processing time is still shorter than the time it takes for the secondary buffer to fill up.

Moving the buffer processing outside of the interrupt handler to the timer handlers didn't seem to resolve the issue as well; there is still a small glitch in the output buffer that lines up with everytime the saadc_handler() gets past the if statement (I tested this by toggling a GPIO everytime the if statement in the interrupt handler was true). I am thinking

Let me know if you have any other suggestions about this issue, and thank you for your advice!

RE: SAADC Sampling Issue

Jørgen Holmefjord — Tue, 10 Dec 2019 13:02:22 GMT

Hi,

How does the buffer look when it is filled with the failing samples? Have you tried moving the processing of the buffer outside of the interrupt handler/callback handler (possibly copy the content to a third buffer or using a third buffer to allow double buffering and processing of one buffer)? I would also recommend that you move the nrf_drv_saadc_buffer_convert() call after you have processed/copied the buffer. Calling this function will trigger the START task, allowing the SAADC peripheral to overwrite the buffer while you process it.

There is a new SAADC driver coming in NRFX that will handle double buffering pointer updates better, and provide more advanced features, but unfortunately, we do not provide any examples of this yet as it is not integrated into the SDK.

Best regards,
Jørgen