SDK_LOG_ENABLED causes saadc channels to shift.

[_Scott_]

So we have the SAADC configured to read using timer attached to ppi. We read from 5 adc channels. If we set NRF_LOG_ENABLED to 1 in sdk_config.h all the channels read fine. However, if we set NRF_LOG_ENABLED to 0, the values in the adc channels shift by 2 channels, eg channel 1 is now the values of channel 4.

I've seen posts saying saadc channels can get shifted if the saadc isn't uninitialized properly between reads. However, when we first started using the saadc, we ran into that issue and fixed our uninitialization. The other strange part, is that with the NRF_LOG_ENABLED issue I'm seeing, the very first read from the saadc is shifted, implying it isn't an issue with uninitialization, but rather the initialization itself. 

What is strange is that the nrf logger would somehow be causing this issue. I can't seem to find any posts with the same issue, but it has such a strange cause I'm also having trouble phrasing my search in a way that brings up relevant results.

Any thoughts on what/why the logger module is shifting the saadc channels?

[Priyanka]

Hi Scott,

Could you tell me what version of SDK are you working on?

Regards,

Priyanka

[_Scott_]

We are using v17.0.2 on a nRF52832

[Priyanka]

Hi Scott,

Is it possible to attach some logs or errors that you see? Also, kindly expect some delay owing to the holiday season in Norway.

Regards,

Priyanka

[_Scott_]

Hi Priyanka,

I was also out for the holiday season so sorry for the delay on my part. We don't get an error, so I can't pass on an error message. Is there an SDK logging feature to give detailed updates on what the SAADC is doing?

Otherwise, I'll upload some screenshots showing the output of each of the SAADC channels with and without NRF_LOG_ENABLED so you can see what I mean by the values in each channel shifting.

[Priyanka]

Hi Scott,

Happy New Year!

The shift could possibly be due to calibration problem or a small halt to the CPU, i.e how did you verify your buffer when the log is disabled? In case you used a debug breakpoint, this can cause a halt to CPU (while PPI is still functioning) and this can cause a shift.

Also, you could take a look at the calibration errata. A offset can be observed if there is a change in the order of events, i.e. if calibration is done before starting the sampling.

The solutions here too can be fruitful.

Regards,

Priyanka

[_Scott_]

Happy New Year Priyanka, thanks for helping me sort through this.

I'm verifying the buffer contents using printf() statements to output the values for each channel. I am not using any debug breakpoints so it may not be a cpu halt. We are running nrf_drv_saadc_calibrate_offset() between each batch of reads, then running nrfx_saadc_disable() followed by nrfx_saadc_enable() to ensure the calibration is used. If this is order of calls is incorrect please let me know.

I looked at the calibration errata, and the symptom does not match what we are seeing. The first sample in the buffer is a correct value, however for the wrong sensor. With NRF_LOG_ENABLED 1, we see the expected channel order of {1,2,3,4,5}, but with NRF_LOG_ENABLED 0 we see the shift where the channel order is now {4,5,1,2,3} but all the values are correct.

I looked through the other post you linked as well. The explanation by Jorgen describing how a DMA transfer can get stuck as pending makes sense. However, I see the shift starting with the very first read from the adc. So if there wasn't a DMA transfer prior to the first read, a pending transfer finally executing doesn't make sense for us. I would like to try his proposed solution 1, "Use PPI to trigger START task on an END event" just to be sure, but I'm not sure how to trigger a start task like that using the soft device.

On top of all that, I still have yet to see how having the NRF logging module enabled prevents me from having the shift issue, but disabling the logging module makes the shift occur. I make no changes to the code expect for the line in sdk_config.h, and I know the code can work, so I don't see how logging causes the issue.

Thanks for help,

Scott