SAADC scan + burst?

RE: SAADC scan + burst?

ftjandra — Fri, 04 Sep 2020 14:46:47 GMT

Thanks for the update and all your hard work in getting to the bottom of this!

RE: SAADC scan + burst?

Karl Ylvisaker — Fri, 04 Sep 2020 10:49:39 GMT

Hello again,

The HW engineers have taken an initial look at the demonstration I provided, and they concur that this is an issue that must be looked into further.
However, some of the HW engineering team are out of office this and the following week, so it will probably take some time to investigate and debug this fully.
Thank you for your continued patience. Please know that we are determined to get to the bottom of this.

I will update this ticket as soon as I have any new information. In the meantime, please do not hesitate to reach out to your contact Gene if there should be anything you would like to discuss.

Best regards,
Karl

RE: SAADC scan + burst?

Karl Ylvisaker — Mon, 31 Aug 2020 11:52:47 GMT

Hello again,

Thank you for your patience.

I just wanted to update you that I have spoken with our HW engineers and provided them with a minimal application to demonstrate the problem.
They will take a look and get back to me shortly, before scheduling a deeper investigation into the issue.
I will keep your updated.

Best regards,
Karl

RE: SAADC scan + burst?

Karl Ylvisaker — Fri, 28 Aug 2020 09:11:54 GMT

Hi,

[quote user="ftjandra"]I can confirm that adding the 3ms delay stops the buffer shift. But isn't it odd that before adding the delay it only shifted once after the first calibration and never again? I would expect it to shift every time.[/quote]

Yes, I too find this odd as I would expect it to happen at other times also. All my tests thus far indicate that it does not, however. So, it is absolutely interesting.
I am in the process of creating a bare-metal demonstration of this behavior, to begin debugging of the hardware and to isolate the driver from the problem.
I hope to know more about this soon.

[quote user="ftjandra"]I will wait for your follow up before I put this into production firmware.[/quote]

Great, I will get back to you on this as soon as I have got something to share.
I have asked for a meeting with the HW and SAADC driver engineers as soon as possible to discuss this.

Best regards,
Karl

RE: SAADC scan + burst?

ftjandra — Thu, 27 Aug 2020 18:45:50 GMT

I can confirm that adding the 3ms delay stops the buffer shift. But isn't it odd that before adding the delay it only shifted once after the first calibration and never again? I would expect it to shift every time.

I will wait for your follow up before I put this into production firmware.

Thanks.

RE: SAADC scan + burst?

Karl Ylvisaker — Thu, 27 Aug 2020 10:21:01 GMT

Hello again,

I have done some more testing, and I might have identified the source of the error.
The START task seems to be called too fast after the CALIBRATE DONE event happens.
I observe that adding a >= 3 ms delay to the CALIBRATE DONE event handler, in before the buffer convert function calls, negates the buffer shift all together.
I have ran this multiple times now, for extended periods, and not seen any buffer shifts happening. Please try this on your end as well, and let me know what you observe.
This is the addition which you might make to your project:

    else if(p_event->type == NRF_DRV_SAADC_EVT_CALIBRATEDONE) {
        __LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "SAADC calibration complete\n");
        saadc_calibrate_stage = 0; //reset
      
        // INSERTED DELAY
        // 2 ms delay yields buffer shift by 1 position following 2nd calibration.
        // 3 ms delay yields constant buffer, no shift.
        nrf_delay_ms(3);

        //Need to setup both buffers, as they were both removed with the call to nrf_drv_saadc_abort before calibration
        ERROR_CHECK(nrf_drv_saadc_buffer_convert(saadc_buffer_pool[0], SAADC_SAMPLES_IN_BUFFER));
        ERROR_CHECK(nrf_drv_saadc_buffer_convert(saadc_buffer_pool[1], SAADC_SAMPLES_IN_BUFFER));

        nrf_drv_timer_enable(&m_saadc_timer);
    }

You will also have to add the nrf_delay.h file to your project.

This issue is especially strange since the way you have implemented the CALIBRATE DONE event handler is the normal way to setup the buffers following a calibration, which leads me to believe this might be an artifact of the scan + oversampling + burst configuration. This is just my current suspicion, which I will continue working on to verify. I have opened an internal request to have this reviewed by the module's engineers too.
Thank you for bringing this up, this is absolutely an interesting find!

Best regards,
Karl

RE: SAADC scan + burst?

Karl Ylvisaker — Wed, 26 Aug 2020 11:57:00 GMT

Hello,

Thank you for your patience.
I just ran the project you provided. My only modifications were to some of the preprocessor include directories, and setting the DEBUG flag.
I am able to reproduce the issue, and I clearly see the behavior you have described about the buffer being shifted by one following the first calibration, and afterwards staying consistent.

[quote user="ftjandra"]I set the PPI to trigger every second. You make it sound like when low_power_mode is set to 1, it should take longer to sample, but when I set it to 1, it is sampling much faster, around 10 times per second.[/quote]

I tested with LP_mode as well, with the same result.
I was not able to see the behavior you described here regarding seemingly more frequent sampling occurring in Low-Power mode, but on my end the buffer shift happens with Low-Power mode as well.

I will now delve deeper into this issue, and see if I can not figure out its root cause and how to negate it. I will update you as soon as I have something.

Best regards,
Karl

RE: SAADC scan + burst?

ftjandra — Mon, 24 Aug 2020 23:51:52 GMT

Adding DEBUG to the preprocessor defines didn't change anything, no assert.

I set the PPI to trigger every second. You make it sound like when low_power_mode is set to 1, it should take longer to sample, but when I set it to 1, it is sampling much faster, around 10 times per second.

Thanks.

RE: SAADC scan + burst?

Karl Ylvisaker — Mon, 24 Aug 2020 14:04:22 GMT

Hello,

[quote user="ftjandra"]Ok, I started from a fresh light switch server and only added what was needed to test this. The project is attached (SDK16.0.0 + Mesh SDK 4.1.0)[/quote]

Thank you for providing me with this project. I have allocated time to test this tomorrow.

I have just gotten back from conferring with our SAADC expert, and he had some thoughts on the matter:

First, on the subject of Low-Power mode negating the buffer shift:
This might be because Low-Power mode stops the SAADC between every sample, which in turn ensures that the workaround for the Errata 237 is in place.

To test if this is the case, could you define DEBUG in your preprocessor defines ( like showed in the included picture ) and see if your call to _abort asserts due to hardware timeout when waiting for the SAADC to be stopped?
In this case, it points to the fact that the SAADC never truly was stopped, and thus the calibration is called as described in the errata I mentioned earlier, leaving an unexpected sample in the buffer.

[quote user="ftjandra"]What is low power mode?[/quote]

The documentation is indeed a little sparse on this, so it is good that you ask! Low-power mode stops the SAADC between each sample.
It is ideal for low-frequency sampling, however it does add some time to the conversion time.

[quote user="ftjandra"]With low_power_mode set to 1, it looks like the buffer stays correct, but the timing is not working anymore.[/quote]

What is your sampling frequency? Since you are using PPI, there is a change when using Low-Power mode. Instead of the PPI trigger TASK_SAMPLE, it will instead trigger TASK_START, which will add some time to your conversion time.

Best regards,
Karl

RE: SAADC scan + burst?

ftjandra — Wed, 19 Aug 2020 20:06:59 GMT

Ok, I started from a fresh light switch server and only added what was needed to test this. The project is attached (SDK16.0.0 + Mesh SDK 4.1.0)

With low_power_mode set to 0, you can see that the buffer gets offset by one after the first calibration.

With low_power_mode set to 1, it looks like the buffer stays correct, but the timing is not working anymore. It's not sampling every second, but instead it seems to be sampling continuously as fast as possible? What is low power mode?

Thanks.

devzone.nordicsemi.com/.../server_5F00_light_5F00_switch_5F00_saadc.zip

RE: SAADC scan + burst?

Karl Ylvisaker — Wed, 19 Aug 2020 12:06:19 GMT

Hello,

Thank you for the clear illustration.

[quote user="ftjandra"]Instead of nrf_pwr_mgmt_run(), I used sd_app_evt_wait(). I think they do the same thing when the Soft Device is used.[/quote]

Yes, using sd_app_evt_wait will function just as well - the CPU will be sleeping until an application event is generated.

[quote user="ftjandra"]I just realized, isn't nrf_drv_saadc_calibrate_offset() being non-blocking already being taken care of in the saadc_event_handler() event handler. This is where I reset the buffers and restart the timer.[/quote]

Yes, come to think of it this should already be taken care of, actually. Keenly spotted.
Then, only the _abort needs to be called from the main context, not the wait_for_calibrate_done.

A colleague of mine mentioned that he had experienced something similar when testing some combination of burst + scan + oversampling and LP modes.
Are you currently using the SAADC Low Power mode? -If not, could you set it to 1 and see if this changes anything in regards to your buffers?

Perhaps you could share you project with me, so that I could attempt to replicate and debug this on my end?
I can convert the ticket to private if you would like me to, just let me know.

Best regards,
Karl

RE: SAADC scan + burst?

ftjandra — Tue, 18 Aug 2020 16:44:15 GMT

Instead of nrf_pwr_mgmt_run(), I used sd_app_evt_wait(). I think they do the same thing when the Soft Device is used.

    for (;;)
    {
        //SAADC Calibration
        if(saadc_calibrate_stage == 1) {
            __LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "Calling nrf_drv_saadc_abort()\n");
            nrf_drv_saadc_abort();
            saadc_calibrate_stage = 2;
        }
        else if(saadc_calibrate_stage == 4) {
            saadc_calibrate_stage++;
            __LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "Starting new SAADC calibration\n");
            while(nrf_drv_saadc_calibrate_offset() != NRF_SUCCESS); //trigger calibration task
            while(!nrf_saadc_event_check(NRF_SAADC_EVENT_CALIBRATEDONE)) {
                __LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "a\n");
                //nrf_pwr_mgmt_run();
                (void)sd_app_evt_wait();
            }
        }
        (void)sd_app_evt_wait();
    }

After initiating the first recalibration, It gets stuck in that new while loop and never gets out. Everything looks like it's still running since it's no different than the 'outer' sd_app_evt_wait(). Except that it doesn't do any more recalibrations after the first time because it doesn't get out to check 'saadc_calibration_stage'.

But, this didn't make a difference because the values are still shifted after calibration:

Right before Calibration
00> saadc_value_current[0]: 987
00> saadc_value_current[1]: 2384
00> saadc_value_current[2]: 0
00> saadc_value_current[3]: 381

Right after calibration
00> saadc_value_current[0]: 986
00> saadc_value_current[1]: 986
00> saadc_value_current[2]: 2383
00> saadc_value_current[3]: 0

2nd reading after calibration, buffer values are shifted by one spot
00> saadc_value_current[0]: 381
00> saadc_value_current[1]: 986
00> saadc_value_current[2]: 2384
00> saadc_value_current[3]: 4294967295

Stays shifted by one spot (even after subsequent recalibrations)
00> saadc_value_current[0]: 381
00> saadc_value_current[1]: 987
00> saadc_value_current[2]: 2384
00> saadc_value_current[3]: 0

I just realized, isn't nrf_drv_saadc_calibrate_offset() being non-blocking already being taken care of in the saadc_event_handler() event handler. This is where I reset the buffers and restart the timer.

    else if(p_event->type == NRF_DRV_SAADC_EVT_CALIBRATEDONE) {
        __LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "SAADC calibration complete\n");
        saadc_calibrate_stage = 0; //reset

        //Need to setup both buffers, as they were both removed with the call to nrf_drv_saadc_abort before calibration
        ERROR_CHECK(nrf_drv_saadc_buffer_convert(saadc_buffer_pool[0], SAADC_SAMPLES_IN_BUFFER));
        ERROR_CHECK(nrf_drv_saadc_buffer_convert(saadc_buffer_pool[1], SAADC_SAMPLES_IN_BUFFER));

        nrf_drv_timer_enable(&m_saadc_timer);
    }

Thanks.

RE: SAADC scan + burst?

Karl Ylvisaker — Tue, 18 Aug 2020 10:48:20 GMT

[quote user="ftjandra"][/quote]

Then in main() when the calibrate flag is set, I call nrf_drv_saadc_abort().

Then 2 seconds later also from main I re-initiate the calibration with while(nrf_drv_saadc_calibrate_offset() != NRF_SUCCESS). I picked two seconds to account for any pending NRFX_SAADC_EVT_DONE events.

This is better, but please keep in mind that the nrfx_saadc_calibrate_offset function is non-blocking, so the program will move on before the calibration necessarily is finished.
Could you attempt to add these lines right below your while(!=NRF_SUCCESS) call?

while(!nrf_saadc_event_check(NRF_SAADC_EVENT_CALIBRATEDONE ))
{
    nrf_pwr_mgmt_run();
}

[quote user="ftjandra"]After the calibration everything in the buffer is still shifted by spot.[/quote]

Is it a particular number they are shifted by?
Some samples may be placed in the buffer during / following calibration, so please make sure that you supply new buffers to the SAADC following a completed calibration.

Best regards,
Karl

RE: SAADC scan + burst?

ftjandra — Mon, 17 Aug 2020 19:12:12 GMT

Ok, still no luck.

I am now calling nrf_drv_timer_disable(&m_saadc_timer) and setting a calibrate flag from within the SAADC event handler.

Then in main() when the calibrate flag is set, I call nrf_drv_saadc_abort().

After the calibration everything in the buffer is still shifted by spot.

RE: SAADC scan + burst?

Karl Ylvisaker — Mon, 17 Aug 2020 14:38:44 GMT

Hello again,

[quote user="ftjandra"]My nRF52840 is rev2.[/quote]

Great, thank you for confirming this. There is only 2 SAADC erratas for the rev 2, one of which is not the issue in question here, and the other one which we have already spoken about.

[quote user="ftjandra"]Eventually I will trigger calibration on temperature change, but for testing it's easier to just do it every xx samples.[/quote]

I understand, this is all right during the testing and development phase.

[quote user="ftjandra"]Do I need to disable the timer, ppi channel, both? Seems like disabling the timer should be enough.[/quote]

This is correct, by disabling the task trigger you have disabled sampling.
However, it seems you might be using the _abort incorrectly - please see the nrfx_saadc_abort documentation, it reads:

Note

NRFX_SAADC_EVT_DONE event will be generated if there is a conversion in progress. Event will contain number of words in the sample buffer.

Warning

This function must not be called from the context of event handler of the SAADC driver or from the context of interrupt with priority equal to or higher than priority of the SAADC interrupt.

You can not call _abort from the event handler of the SAADC, or from an interrupt with priority equal to or higher than the SAADC interrupt.
So, for instance, if you call it from main ( or anywhere else with lower priority ) then it will work.

[quote user="ftjandra"]Do I need the nrf_drv_saadc_abort()?[/quote]

Yes, but it can not be used as you are using it now.

[quote user="ftjandra"]I know you mentioned that I need to wait for the END event before calibrating, how do I do that?[/quote]

My apologies, when using the NRFX driver it is the DONE event you will have to wait for.
The END event is from the HAL, which you should not use directly together with the NRFX driver, since this may place the driver in an invalid state.

[quote user="ftjandra"]After trying the above, I followed this thread and stopped and restarted everything so it would start from the very beginning with the initial calibration, but the buffer was out of order again![/quote]

As I said, you can not call abort from the SAADC event handler context.
Please resolve this, and let me know if this resolves the issue of getting stuck in the calibrate loop for earlier.

Looking forward to resolving this issue together!

Best regards,
Karl

RE: SAADC scan + burst?

ftjandra — Fri, 14 Aug 2020 16:32:08 GMT

My nRF52840 is rev2. Eventually I will trigger calibration on temperature change, but for testing it's easier to just do it every xx samples.

I modified the saadc_event_handler() as follows:

static void saadc_event_handler(nrf_drv_saadc_evt_t const * p_event) {
    static uint16_t saadc_event_counter = 1;

    if(p_event->type == NRF_DRV_SAADC_EVT_DONE) {
        //Read buffer
        for(int i=0; i<SAADC_SAMPLES_IN_BUFFER; i++) {
            saadc_value_current[i] = p_event->data.done.p_buffer[i];
        }
        
        if((saadc_event_counter % SAADC_CALIBRATION_INTERVAL) == 0) {
            saadc_event_counter = 0;    //reset
            nrf_drv_timer_disable(&m_saadc_timer);
            nrf_drv_saadc_abort();
            while(nrf_drv_saadc_calibrate_offset() != NRF_SUCCESS); //trigger calibration task
        }
        else {
            //Set buffer, double-buffering
            ERROR_CHECK(nrf_drv_saadc_buffer_convert(p_event->data.done.p_buffer, SAADC_SAMPLES_IN_BUFFER));
        
            //Print samples
            __LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "\nsaadc_value_current[0]: %u\nsaadc_value_current[1]: %u\nsaadc_value_current[2] %u\nsaadc_value_current[3]: %u\n", saadc_value_current[0], saadc_value_current[1], saadc_value_current[2], saadc_value_current[3]);
        }
        
        saadc_event_counter++;
    }
    else if(p_event->type == NRF_DRV_SAADC_EVT_CALIBRATEDONE) {
        __LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "SAADC calibration complete\n");

        //Need to setup both buffers, as they were both removed with the call to nrf_drv_saadc_abort before calibration
        ERROR_CHECK(nrf_drv_saadc_buffer_convert(saadc_buffer_pool[0], SAADC_SAMPLES_IN_BUFFER));
        ERROR_CHECK(nrf_drv_saadc_buffer_convert(saadc_buffer_pool[1], SAADC_SAMPLES_IN_BUFFER));

        nrf_drv_timer_enable(&m_saadc_timer);
    }
}

Do I need to disable the timer, ppi channel, both? Seems like disabling the timer should be enough. I also moved enabling the timer to the NRF_DRV_SAADC_EVT_CALIBRATEDONE event instead of in saadc_init(). So the timer gets started after the initial calibration and after any re-calibration.

But with the above code, it gets stuck in the while(nrf_drv_saadc_calibrate_offset() != NRF_SUCCESS);

Do I need the nrf_drv_saadc_abort()?

I know you mentioned that I need to wait for the END event before calibrating, how do I do that?

Edit: After trying the above, I followed this thread and stopped and restarted everything so it would start from the very beginning with the initial calibration, but the buffer was out of order again!

https://devzone.nordicsemi.com/f/nordic-q-a/32982/can-t-stop-saadc/127979#127979

static void saadc_event_handler(nrf_drv_saadc_evt_t const * p_event) {
    static uint16_t saadc_event_counter = 1;

    if(p_event->type == NRF_DRV_SAADC_EVT_DONE) {
        //Read buffer
        for(int i=0; i<SAADC_SAMPLES_IN_BUFFER; i++) {
            saadc_value_current[i] = p_event->data.done.p_buffer[i];
        }
        
        if((saadc_event_counter % SAADC_CALIBRATION_INTERVAL) == 0) {
            saadc_event_counter = 0;    //reset
            nrf_drv_timer_disable(&m_saadc_timer);
            nrf_drv_timer_uninit(&m_saadc_timer);
            nrf_drv_ppi_channel_disable(m_saadc_ppi_channel);
            nrf_drv_ppi_uninit();
            nrf_drv_saadc_abort();
            nrf_drv_saadc_uninit();
            while(nrf_drv_saadc_is_busy());
            saadc_init();
            saadc_sampling_event_init();
            saadc_sampling_event_enable();
        }
        else {
            //Set buffer, double-buffering
            ERROR_CHECK(nrf_drv_saadc_buffer_convert(p_event->data.done.p_buffer, SAADC_SAMPLES_IN_BUFFER));
        
            //Print samples
            __LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "\nsaadc_value_current[0]: %u\nsaadc_value_current[1]: %u\nsaadc_value_current[2] %u\nsaadc_value_current[3]: %u\n", saadc_value_current[0], saadc_value_current[1], saadc_value_current[2], saadc_value_current[3]);
        }
        
        saadc_event_counter++;
    }
    else if(p_event->type == NRF_DRV_SAADC_EVT_CALIBRATEDONE) {
        __LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "SAADC calibration complete\n");

        //Need to setup both buffers, as they were both removed with the call to nrf_drv_saadc_abort before calibration
        ERROR_CHECK(nrf_drv_saadc_buffer_convert(saadc_buffer_pool[0], SAADC_SAMPLES_IN_BUFFER));
        ERROR_CHECK(nrf_drv_saadc_buffer_convert(saadc_buffer_pool[1], SAADC_SAMPLES_IN_BUFFER));

        nrf_drv_timer_enable(&m_saadc_timer);
    }
}

Thanks.

RE: SAADC scan + burst?

Karl Ylvisaker — Fri, 14 Aug 2020 09:40:54 GMT

[quote user="ftjandra"]Also, when does saadc_timer_handler() get called. In the example it was empty and I see that it never gets called.[/quote]

I did not see this question when writing my last post, sorry.
The timer handler can be empty since the CC event is directly tied to the SAADC START task through PPI, which is all it is meant to do.

Best regards,
Karl

RE: SAADC scan + burst?

Karl Ylvisaker — Fri, 14 Aug 2020 09:39:08 GMT

[quote user="ftjandra"]I am now successfully triggering the sample via PPI.[/quote]

I am glad to hear that, well done!

[quote user="ftjandra"]lets say every 1000 samples?[/quote]

Is there a particular reason for why you would like a calibration to be done every 1000 samples? Is the temperature changing during this time?

[quote user="ftjandra"]What is now the correct process to trigger a calibration[/quote]

Which nRF52840 SoC revision are you working with?
As I mentioned before, calibration should be done when you enable the SAADC and when the temperature has changed significantly.
You will also need to make sure that CTASKS_ALIBRATEOFFSET is never called between TASKS_START and EVENT_END, due to Errata 237.
So, to calibrate every 1000 sample you will need to make a counter that keeps track of the sampled number, and when it reaches 1000 samples the START task PPI timer is stopped, and when the END event is generated calibration can start.

Best regards,
Karl

RE: SAADC scan + burst?

ftjandra — Thu, 13 Aug 2020 22:53:14 GMT

Ok, I am now successfully triggering the sample via PPI. All my SAADC code is below. What is now the correct process to trigger a calibration, lets say every 1000 samples?

static void saadc_event_handler(nrf_drv_saadc_evt_t const * p_event) {
    if(p_event->type == NRF_DRV_SAADC_EVT_DONE) {
        //Read buffer
        for(int i=0; i<SAADC_SAMPLES_IN_BUFFER; i++) {
            saadc_value_current[i] = p_event->data.done.p_buffer[i];
        }
        
        //Set buffer, double-buffering
        ERROR_CHECK(nrf_drv_saadc_buffer_convert(p_event->data.done.p_buffer, SAADC_SAMPLES_IN_BUFFER));

        //Print samples
        __LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "\nsaadc_value_current[0]: %u\nsaadc_value_current[1]: %u\nsaadc_value_current[2] %u\nsaadc_value_current[3]: %u\n", saadc_value[0], saadc_value[1], saadc_value[2], saadc_value[3]);
    }
    else if(p_event->type == NRF_DRV_SAADC_EVT_CALIBRATEDONE) {
        __LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "SAADC calibration complete\n");

        //Need to setup both buffers, as they were both removed with the call to nrf_drv_saadc_abort before calibration
        ERROR_CHECK(nrf_drv_saadc_buffer_convert(saadc_buffer_pool[0], SAADC_SAMPLES_IN_BUFFER));
        ERROR_CHECK(nrf_drv_saadc_buffer_convert(saadc_buffer_pool[1], SAADC_SAMPLES_IN_BUFFER));
    }
}

static void saadc_timer_handler(nrf_timer_event_t event_type, void * p_context) {
    __LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "saadc_timer_handler\n");
}

static void saadc_init(void) {
    nrf_drv_saadc_config_t saadc_config = NRF_DRV_SAADC_DEFAULT_CONFIG;
    saadc_config.resolution = NRF_SAADC_RESOLUTION_12BIT;
    saadc_config.oversample = (nrf_saadc_oversample_t)NRF_SAADC_OVERSAMPLE_256X;
    saadc_config.interrupt_priority = NRFX_SAADC_CONFIG_IRQ_PRIORITY;
    saadc_config.low_power_mode = NRFX_SAADC_CONFIG_LP_MODE;

    nrf_saadc_channel_config_t channel_0_config = NRF_DRV_SAADC_DEFAULT_CHANNEL_CONFIG_SE(NRF_SAADC_INPUT_AIN0);
    channel_0_config.gain = NRF_SAADC_GAIN1_6;
    channel_0_config.reference = NRF_SAADC_REFERENCE_INTERNAL;
    channel_0_config.burst = NRF_SAADC_BURST_ENABLED;

    nrf_saadc_channel_config_t channel_1_config = NRF_DRV_SAADC_DEFAULT_CHANNEL_CONFIG_SE(NRF_SAADC_INPUT_AIN1);
    channel_1_config.gain = NRF_SAADC_GAIN1_6;
    channel_1_config.reference = NRF_SAADC_REFERENCE_INTERNAL;
    channel_1_config.burst = NRF_SAADC_BURST_ENABLED;

    nrf_saadc_channel_config_t channel_2_config = NRF_DRV_SAADC_DEFAULT_CHANNEL_CONFIG_SE(NRF_SAADC_INPUT_AIN5);
    channel_2_config.gain = NRF_SAADC_GAIN1_6;
    channel_2_config.reference = NRF_SAADC_REFERENCE_INTERNAL;
    channel_2_config.burst = NRF_SAADC_BURST_ENABLED;

    nrf_saadc_channel_config_t channel_3_config = NRF_DRV_SAADC_DEFAULT_CHANNEL_CONFIG_SE(NRF_SAADC_INPUT_AIN4);
    channel_3_config.gain = NRF_SAADC_GAIN1_6;
    channel_3_config.reference = NRF_SAADC_REFERENCE_INTERNAL;
    channel_3_config.burst = NRF_SAADC_BURST_ENABLED;

    ERROR_CHECK(nrf_drv_saadc_init(&saadc_config, saadc_event_handler));

    ERROR_CHECK(nrf_drv_saadc_channel_init(0, &channel_0_config));
    ERROR_CHECK(nrf_drv_saadc_channel_init(1, &channel_1_config));
    ERROR_CHECK(nrf_drv_saadc_channel_init(2, &channel_2_config));
    ERROR_CHECK(nrf_drv_saadc_channel_init(3, &channel_3_config));

    //https://devzone.nordicsemi.com/f/nordic-q-a/63074/buffer-order-swap-of-saadc-used-with-nrf-mesh
    nrf_ppi_channel_t saadc_buffer_swap_ppi_channel;
    ERROR_CHECK(nrf_drv_ppi_init());
    ERROR_CHECK(nrf_drv_ppi_channel_alloc(&saadc_buffer_swap_ppi_channel));
    ERROR_CHECK(nrf_drv_ppi_channel_assign(saadc_buffer_swap_ppi_channel,
                                           (uint32_t)&NRF_SAADC->EVENTS_END,
                                           (uint32_t)&NRF_SAADC->TASKS_START));
    ERROR_CHECK(nrf_drv_ppi_channel_enable(saadc_buffer_swap_ppi_channel));

    __LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "Starting initial SAADC calibration\n");
    while(nrf_drv_saadc_calibrate_offset() != NRF_SUCCESS); //trigger calibration task
    saadc_calibrate = false;
}

static void saadc_sampling_event_init(void) {
    //ERROR_CHECK(nrf_drv_ppi_init());

    nrf_drv_timer_config_t timer_cfg = NRF_DRV_TIMER_DEFAULT_CONFIG;
    timer_cfg.bit_width = NRF_TIMER_BIT_WIDTH_32;
    ERROR_CHECK(nrf_drv_timer_init(&m_saadc_timer, &timer_cfg, saadc_timer_handler));

    // setup m_saadc_timer for compare event every 1000ms
    uint32_t ticks = nrf_drv_timer_ms_to_ticks(&m_saadc_timer, 1000);
    nrf_drv_timer_extended_compare(&m_saadc_timer,
                                   NRF_TIMER_CC_CHANNEL0,
                                   ticks,
                                   NRF_TIMER_SHORT_COMPARE0_CLEAR_MASK,
                                   false);
    nrf_drv_timer_enable(&m_saadc_timer);

    uint32_t timer_compare_event_addr = nrf_drv_timer_compare_event_address_get(&m_saadc_timer,
                                                                                NRF_TIMER_CC_CHANNEL0);
    uint32_t saadc_sample_task_addr   = nrf_drv_saadc_sample_task_get();

    // setup ppi channel so that timer compare event is triggering sample task in SAADC
    ERROR_CHECK(nrf_drv_ppi_channel_alloc(&m_saadc_ppi_channel));
    ERROR_CHECK(nrf_drv_ppi_channel_assign(m_saadc_ppi_channel,
                                           timer_compare_event_addr,
                                           saadc_sample_task_addr));
}

static void saadc_sampling_event_enable(void) {
    ERROR_CHECK(nrf_drv_ppi_channel_enable(m_saadc_ppi_channel));
}

Also, when does saadc_timer_handler() get called. In the example it was empty and I see that it never gets called.

Thanks.

RE: SAADC scan + burst?

Karl Ylvisaker — Thu, 13 Aug 2020 07:24:10 GMT

Hello,

[quote user="ftjandra"]NRFX_SAADC_CONFIG_IRQ_PRIORITY is set to 6 in sdk_config.h[/quote]

With your current solution - using CPU to trigger sampling - I would suggest increasing the priority of the SAADC, to see if this may prevent it from being interrupted by some other peripheral.

[quote user="ftjandra"]I could set it up through PPI if you show me how. I haven't used PPI.[/quote]

I would highly recommend making use of the PPI peripheral. The PPI and easyDMA is two very powerful features that drastically reduce the necessary CPU intervention to perform sampling.
In essence, what the PPI does is create a hardware connection between two peripherals. In your case, that would be to connect the timer interrupt directly to the SAADC sample task, so that there is no need for the CPU to do anything between processing of the buffers.

A clean example of how you may use the PPI to connect a timer to your SAADC is demonstrated in the SAADC peripheral example. Please have a look at this example, and let me know if anything should be unclear, or if you have any questions!

[quote user="ftjandra"]So far it has only messed up immediately after it calibrates. If I never re-calibrate after the initial calibration it has been fine (24 hours). But, if there is a risk from using the app_timer, I want to fix that.[/quote]

Using the app_timer is fine. You might switch to using the app_timer v2 if you are not already, but none of them should be causing the SAADC buffer troubles, they are very well behaved.

Looking forward to resolving this issue together!

Best regards,
Karl

RE: SAADC scan + burst?

ftjandra — Wed, 12 Aug 2020 15:56:45 GMT

NRFX_SAADC_CONFIG_IRQ_PRIORITY is set to 6 in sdk_config.h

I could set it up through PPI if you show me how. I haven't used PPI.

So far it has only messed up immediately after it calibrates. If I never re-calibrate after the initial calibration it has been fine (24 hours). But, if there is a risk from using the app_timer, I want to fix that.

Thanks.

RE: SAADC scan + burst?

Karl Ylvisaker — Wed, 12 Aug 2020 15:27:14 GMT

Hello again,

Thank you for providing the additional information.

[quote user="ftjandra"]I think all the relevant code should be in my first post[/quote]

Reading the code and hearing your intentions are both useful.

I see that you are using an app_timer to call the nrf_drv_saadc_sample function.
The nrf_drv_saadc_sample is a call that is handled by the CPU. I suspect that a higher priority task could interrupt the SAADC sample handling at an inopportune time, potentially causing the shift in the buffered samples.
Is there a particular reason for why you are having the CPU start each sampling, or could you instead set up the timer to trigger the sample task through PPI?
This would greatly reduce the CPU time necessary to perform each sample.

Additionally, what is your NRFX_SAADC_CONFIG_IRQ_PRIORITY defined as?

Best regards,
Karl

RE: SAADC scan + burst?

ftjandra — Tue, 11 Aug 2020 23:33:27 GMT

I think all the relevant code should be in my first post (plus the modification to saadc_init().

1. saadc_init(). Does initial calibration.

2. On NRF_DRV_SAADC_EVT_CALIBRATEDONE set up double-buffer.

3. App timer: Every second call nrf_drv_saadc_sample() if calibrate flag is not set. If calibrate flag is set call nrf_drv_saadc_calibrate_offset()

4. On NRF_DRV_SAADC_EVT_DONE, copy out readings and either:

set up next buffer, nrf_drv_saadc_buffer_convert(p_event->data.done.p_buffer, SAADC_SAMPLES_IN_BUFFER)

- or -

every 4096 samples do a calibration by nrf_drv_saadc_abort() and setting calibrate flag.

Thanks.

RE: SAADC scan + burst?

Karl Ylvisaker — Tue, 11 Aug 2020 08:08:11 GMT

Hello,

[quote user="ftjandra"]Line 294 or nrfx_saadc.c that you mentioned doesn't seem to affect me, it's not asserting with that line as-is.[/quote]

Strange, I would expect it to assert when you combine scan mode with oversampling.

[quote user="ftjandra"]It's fine after the initial calibration that I do, but after I trigger another one, the buffer is still out of sync.[/quote]

I see. Could you elaborate on how and when you perform calibrations?
If you could share the code snippets of the calibration that would be beneficial as well.

[quote user="ftjandra"]Are you saying that even if I don't do periodic calibrations that the buffer will eventually mess up?[/quote]

No, absolutely not. The buffer-swap issue was an older issue, which is resolved by the modification you added to your saadc_init - the buffer swaps you are seeing now is therefore likely caused by something else, perhaps an incorrectly aborted conversion or similar. Lets look further into how you perform the calibrations, and what else is going on in the application.

Looking forward to resolving this issue together!

Best regards,
Karl

RE: SAADC scan + burst?

ftjandra — Mon, 10 Aug 2020 17:25:15 GMT

Ok, so I added Jørgen's changes to the end of saadc_init():

static void saadc_init(void) {
    nrf_drv_saadc_config_t saadc_config = NRF_DRV_SAADC_DEFAULT_CONFIG;
    saadc_config.resolution = NRF_SAADC_RESOLUTION_12BIT;
    saadc_config.oversample = (nrf_saadc_oversample_t)NRF_SAADC_OVERSAMPLE_256X;
    saadc_config.interrupt_priority = NRFX_SAADC_CONFIG_IRQ_PRIORITY;
    saadc_config.low_power_mode = NRFX_SAADC_CONFIG_LP_MODE;

    nrf_saadc_channel_config_t channel_0_config = NRF_DRV_SAADC_DEFAULT_CHANNEL_CONFIG_SE(NRF_SAADC_INPUT_AIN0);
    channel_0_config.gain = NRF_SAADC_GAIN1_6;
    channel_0_config.reference = NRF_SAADC_REFERENCE_INTERNAL;
    channel_0_config.burst = NRF_SAADC_BURST_ENABLED;
    //nrf_saadc_burst_set(0, NRF_SAADC_BURST_ENABLED);

    nrf_saadc_channel_config_t channel_1_config = NRF_DRV_SAADC_DEFAULT_CHANNEL_CONFIG_SE(NRF_SAADC_INPUT_AIN1);
    channel_1_config.gain = NRF_SAADC_GAIN1_6;
    channel_1_config.reference = NRF_SAADC_REFERENCE_INTERNAL;
    channel_1_config.burst = NRF_SAADC_BURST_ENABLED;
    //nrf_saadc_burst_set(1, NRF_SAADC_BURST_ENABLED);

    nrf_saadc_channel_config_t channel_2_config = NRF_DRV_SAADC_DEFAULT_CHANNEL_CONFIG_SE(NRF_SAADC_INPUT_AIN5);
    channel_2_config.gain = NRF_SAADC_GAIN1_6;
    channel_2_config.reference = NRF_SAADC_REFERENCE_INTERNAL;
    channel_2_config.burst = NRF_SAADC_BURST_ENABLED;
    //nrf_saadc_burst_set(2, NRF_SAADC_BURST_ENABLED);

    nrf_saadc_channel_config_t channel_3_config = NRF_DRV_SAADC_DEFAULT_CHANNEL_CONFIG_SE(NRF_SAADC_INPUT_AIN4);
    channel_3_config.gain = NRF_SAADC_GAIN1_6;
    channel_3_config.reference = NRF_SAADC_REFERENCE_INTERNAL;
    channel_3_config.burst = NRF_SAADC_BURST_ENABLED;
    //nrf_saadc_burst_set(3, NRF_SAADC_BURST_ENABLED);

    ERROR_CHECK(nrf_drv_saadc_init(&saadc_config, saadc_event_handler));

    ERROR_CHECK(nrf_drv_saadc_channel_init(0, &channel_0_config));
    ERROR_CHECK(nrf_drv_saadc_channel_init(1, &channel_1_config));
    ERROR_CHECK(nrf_drv_saadc_channel_init(2, &channel_2_config));
    ERROR_CHECK(nrf_drv_saadc_channel_init(3, &channel_3_config));

    //https://devzone.nordicsemi.com/f/nordic-q-a/63074/buffer-order-swap-of-saadc-used-with-nrf-mesh
    nrf_ppi_channel_t saadc_buffer_swap_ppi_channel;
    nrf_drv_ppi_channel_alloc(&saadc_buffer_swap_ppi_channel);
    nrf_drv_ppi_channel_assign(saadc_buffer_swap_ppi_channel,
                               (uint32_t)&NRF_SAADC->EVENTS_END,
                               (uint32_t)&NRF_SAADC->TASKS_START);
    nrf_drv_ppi_channel_enable(saadc_buffer_swap_ppi_channel);

    __LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "Starting initial SAADC calibration\n");
    while(nrf_drv_saadc_calibrate_offset() != NRF_SUCCESS); //trigger calibration task
    saadc_calibrate = false;
}

I commented out the NRF_SAADC_TASK_START on line 128 of nrfx_saadc.c

Line 294 or nrfx_saadc.c that you mentioned doesn't seem to affect me, it's not asserting with that line as-is.

It's fine after the initial calibration that I do, but after I trigger another one, the buffer is still out of sync.

Before these modifications, I ran it for a whole day without having it do any periodic calibration and everything was fine. Are you saying that even if I don't do periodic calibrations that the buffer will eventually mess up?

Thanks.