SAADC Missing/Incorrect Readings

RE: SAADC Missing/Incorrect Readings

hmolesworth — Wed, 27 Sep 2023 15:23:40 GMT

I just ran this code without modifications and it works fine on the first 3 readings:

void stuff(void)
{
   uint32_t task_count = 0;
    adc_samples[0][task_count] = Saadc_Oneshot_Sample(SAADC_CH_PSELP_PSELP_AnalogInput0);
    adc_samples[1][task_count] = Saadc_Oneshot_Sample(SAADC_CH_PSELP_PSELP_AnalogInput1);
    adc_samples[2][task_count] = Saadc_Oneshot_Sample(SAADC_CH_PSELP_PSELP_AnalogInput2);
   while(1)

Removing "++" from if(current_sampling_task_count++ and placing outside the if block would appear to fix the issue.

RE: SAADC Missing/Incorrect Readings

dlewis — Wed, 27 Sep 2023 14:06:25 GMT

I went and tested this using a variety of online C compiler emulators and it does look like it is dependent on which compiler is used. To me that seems like a silly thing to have be compiler dependent, but I have only ever seen it the one way until now.

I will change the code to follow your suggested incrementing procedure, as that way should operate the same no matter which compiler/optimization is used.

RE: SAADC Missing/Incorrect Readings

dlewis — Wed, 27 Sep 2023 14:01:00 GMT

I cannot speak on the differences in compilers, but when I run the code, Current_Measure_Task() does properly receive a '0' on first invocation. The issue I am having is that in the below portion of code, the call of Saadc_Oneshot_Sample(SAADC_CH_PSELP_PSELP_AnalogInput0); returns '0', when the other 2 calls of Saadc_Oneshot_Sample() for the other two pins return valid values. This occurs even if I change the order of which pin is sampled first.

RE: SAADC Missing/Incorrect Readings

hmolesworth — Mon, 25 Sep 2023 23:27:36 GMT

No offense, but I disagree - I just tested this and see that current_sampling_task_count is '1' (not '0') on the first invocation of Current_Measure_Task().

This may be compiler and optimisation dependent; I tested on IAR v8.34

RE: SAADC Missing/Incorrect Readings

dlewis — Mon, 25 Sep 2023 15:15:01 GMT

Hi hmolesworth,

As far as I am aware, in C, the "++" after the variable implies the value is not incremented until after the code in the if statement. I believe this is confirmed by the fact that Current_Measure_Task() is in fact receiving the parameter of '0' for "task_count". That is not the issue. The issue is that when Saadc_Oneshot_Sample() is called and sent the parameter of "SAADC_CH_PSELP_AnalogInput0", it always returns a value of '0' when "task_count" = 0. It is strange because that when "task_count" = 0, the other two calls of Saadc_Oneshot_Sample() for "SAADC_CH_PSELP_AnalogInput1" and "SAADC_CH_PSELP_AnalogInput2" return valid ADC readings. Even if you change the order of which channel is being sampled first, it is only problematic for "SAADC_CH_PSELP_AnalogInput0".

RE: SAADC Missing/Incorrect Readings

hmolesworth — Thu, 21 Sep 2023 19:04:31 GMT

Looks like a software bug, Current_Measure_Task() starts with 1 not 0:

    if(current_sampling_task_count++ >= (ADC_SAMPLE_COUNT - 1))
    {
       blah-blah
    }else{
        // current_sampling_task_count is already 1 not 0
        Current_Measure_Task(current_sampling_task_count);  //take samples for current measurements
        // nrf_gpio_pin_toggle(11);
        return CURRENT_SAMPLING_TASK_PERIOD_DEFAULT;
    }

Fix: Remove "++" from if(current_sampling_task_count++ and place after if stuff

RE: SAADC Missing/Incorrect Readings

dlewis — Thu, 21 Sep 2023 16:48:13 GMT

Hi Karl,

I will look into using nrfx_saadc_sample() early next week, I am out of the office till then.

To answer your question about what the register manipulation code is based on:
The code is taken directly from Wirepas, this is how they have implemented SAADC usage in their SDK. I will provide the source file it is based on. The only thing that I changed was the the source pin of SAADC_CH_PSELP_PSELP_Pos.

devzone.nordicsemi.com/.../voltage_5F00_52832.c

RE: SAADC Missing/Incorrect Readings

Karl Ylvisaker — Thu, 21 Sep 2023 16:40:31 GMT

Hello,

Thank you for getting this information from Wirepas - it is good to know that they are using the nrfx v2.5 drivers in their SDK.

In this case we will need to take a closer look at your code and your SAADC usage.
Could you make an attempt where you substitute the direct register manipulation with use of the nrfx saadc API instead?
For instance, to perform a single sampling you should then use nrfx_saadc_sample().

Just out of curiosity, what resource is the register-manipulation code in the current approach based on - is this something you have made inhouse based on the PS, or is it based on another reference from elsewhere?

Best regards,
Karl

RE: SAADC Missing/Incorrect Readings

dlewis — Mon, 18 Sep 2023 13:54:36 GMT

This is the response from Wirepas:

Hi David,

First in order to be clear in the SDK we do not deliver any SAADC driver. The necessary register definitions of peripherals, memory mapping and so forth which indeed comes from the nrfx library provided by Nordic.

In the SDK v1.4.0 required to develop with the stack v5.3, the nrfx v2.5.0 is used.

If you search into our SDK you will see that for nRF52 there is no mention of this CALIBRATEOFFSET.

One question:

Have you tested your ADC reading with a baremetal application i.e without any Wirepas SDK/Wirepas stack to know what is the behaviour?

If anything is unclear please let us know.

Looking forward to your reply.

Best regards,

Wirepas Customer Success team.

RE: SAADC Missing/Incorrect Readings

Karl Ylvisaker — Wed, 13 Sep 2023 17:31:44 GMT

Alright, great! :)
I look forward to hearing their reply.

In the unlikely case that they do not use the nrfx_saadc driver as part of their SDK (i.e that they have made their own driver implementation, or similar), please ask them specifically if this driver includes the workarounds for the Erratas I referenced in my previous comment.

Best regards,
Karl

RE: SAADC Missing/Incorrect Readings

dlewis — Wed, 13 Sep 2023 13:59:28 GMT

I've sent a ticket to Wirepas asking those questions about the nrfx version and use of calibrateoffset. Will reply with their response.

RE: SAADC Missing/Incorrect Readings

Karl Ylvisaker — Tue, 12 Sep 2023 14:09:41 GMT

Hello,

Thank you for your patience with this.

[quote user="dlewis"]It doesn't look like the same issue occurs here.[/quote]

Thank you for the update, this is very good debugging information, and it points to there being an issue with the other firmware, so now we can focus to try and isolate this error further.

[quote user="dlewis"]I also ran a test using my Wirepas code. On line 32 of current_measure.c I changed the value of "adc_result" to another non-zero value. The value still comes out to be 0 after the sample task completes, but only on the "first" iteration of the full sampling sequence. I still don't have any idea how or why the SAADC seems to "know" it's the first iteration when it only controls what array position the value gets written to and shouldn't influence the measurement itself. [/quote]

As mentioned I am not personally familiar with the Wirepas Massive SDK, but I would assume that they use the nRFX drivers behind the scenes, is this correct? If so, which version of the nRFX drivers are they using for the SAADC operation in the 5.3 SDK? Is there any chance that they are shutting down the SAADC in between each usage, and/or performing a calibration procedure? A calibration procedure will produce a junk sample to the buffer, which possibly could be what you are seeing here.

Best regards,
Karl

RE: SAADC Missing/Incorrect Readings

dlewis — Wed, 06 Sep 2023 14:17:15 GMT

I also ran a test using my Wirepas code. On line 32 of current_measure.c I changed the value of "adc_result" to another non-zero value. The value still comes out to be 0 after the sample task completes, but only on the "first" iteration of the full sampling sequence. I still don't have any idea how or why the SAADC seems to "know" it's the first iteration when it only controls what array position the value gets written to and shouldn't influence the measurement itself.

RE: SAADC Missing/Incorrect Readings

dlewis — Wed, 06 Sep 2023 14:11:46 GMT

Here is the output result of running the SAADC example from the SDK on my custom hardware:

It doesn't look like the same issue occurs here.

RE: SAADC Missing/Incorrect Readings

Karl Ylvisaker — Wed, 06 Sep 2023 11:14:13 GMT

Hello,

[quote user="dlewis"]I will run the example and reply with how it goes.[/quote]

Great, I look forward to hearing your results.

[quote user="dlewis"]I am not familiar with CALIBRATEOFFSET, is that something I would manually have to run, or could it happen as a result of something else? I am not specifically calling that procedure anywhere. Everything SAADC related being used is in the files provided already, as far as I am aware. Thanks for the help![/quote]

You should run CALIBRATEOFFSET at the start of your SAADC usage, and as a rule of thumb once every time the ambient temperature has changed by 10 degrees Celsius, to keep the SAADC output accurate.

[quote user="dlewis"]Here are the schematic screenshots of the adc pins used. The pins being measured are the "ISNSX_A2D" pins. [/quote]

Thank you for sharing this - I do not immediately see any reason why the one pin should behave differently. It will be interesting to see the results from your nRF5 SDK SAADC example tests.

Best regards,
Karl

RE: SAADC Missing/Incorrect Readings

dlewis — Tue, 05 Sep 2023 14:59:23 GMT

I will run the example and reply with how it goes.

I am not familiar with CALIBRATEOFFSET, is that something I would manually have to run, or could it happen as a result of something else? I am not specifically calling that procedure anywhere. Everything SAADC related being used is in the files provided already, as far as I am aware. Thanks for the help!

Here are the schematic screenshots of the adc pins used. The pins being measured are the "ISNSX_A2D" pins.

RE: SAADC Missing/Incorrect Readings

Karl Ylvisaker — Mon, 04 Sep 2023 13:01:49 GMT

Hello,

[quote user=""]The issue I am seeing is that the very first SAADC sample of each cycle, specifically when sampling AIN0, returns a reading of '0' no matter what. This happens at line 155 of current_measure.c. It only happens when measuring AIN0, and it doesn't matter if the order of lines 155 to 157, AIN0 always returns 0 the first time. Every other time after that it returns a valid value. I have confirmed this by printing out the array values for each. [/quote]

That sounds strange indeed.
I am not personally familiar with the Wirepas Massive SDK, so as a debugging step to isolate the issue, could you run the default SAADC example from the nRF5 SDK to see if this also exhibits the same behavior?

Could you also verify whether you are triggering the CALIBRATEOFFSET procedure anywhere in your application?
If so, you will need to be aware of Errate 86 and Errata 252.
I could not see this in your shared code, and I dont expect that this would happen anywhere else unexpectedly since you are not using any SAADC driver, but I ask just in case.

Could you possibly share the relevant parts of your schematics as well, for good measure?

Best regards,
Karl