Glitches in adc sampling

RE: Glitches in adc sampling

Edvin — Tue, 28 Aug 2018 12:54:54 GMT

Hello,

Ususally, we don't recommend disabling softdevice interrupts. If the softdevice misses a timing critical interrupt it may cause an application reset. I know that 3 µs is a very short amount of time, and it may not cause any harm, but I can't say that "it's fine".

You will have to do some testing. If it works for your application, and you don't run into any softdevice issues, then it will probably be fine.

Best regards,

Edvin

RE: Glitches in adc sampling

Omri Friedman — Tue, 28 Aug 2018 06:49:39 GMT

Hi Edvin, I gave up on trying to make this work and switched to another approach where i need to sample just one ADC channel instead of 3 and this seems to work for me.

However, in order to do that i need to disable all interrupts for a duration of 3us once every 500us on average. Will that cause any problem to the soft device proper functionality?

RE: Glitches in adc sampling

Edvin — Thu, 23 Aug 2018 07:29:35 GMT

Hello,

Moving the typedef uint32_t ret_code_t somehow solved the issue. I was able to compile after changing ble_advertising_start_with_map() ble_advertising_start() on line 765 in ble.c. where did you declare ble_advertising_start_with_map()? I could not find it.

I was never able to compile in IAR. I am sorry, but I have had some bad experience with IAR before, so I ported the project to Keil. However, after programming the slightly modified project to Keil, and programming it, I can't see any logging. I used the preprocessor defines from IAR, but with no luck.

Can you try to unzip the project in a fresh unmodified version of the SDK and see whether you can make it run (in IAR)? If not, please try to find out what files you have to modify to make it run, and let me know.

Best regards,

Edvin

RE: Glitches in adc sampling

Omri Friedman — Wed, 22 Aug 2018 05:08:21 GMT

Hן Edvin

In file components\libraries\util\sdk_errors.h i justed moved the 'typedef uint32_t ret_code_t;' line to the top of the file above the '#include' lines:

typedef uint32_t ret_code_t;

#include <stdint.h>
#include "nrf_error.h"
#include "sdk_config.h"

#ifdef __cplusplus
extern "C" {
#endif

RE: Glitches in adc sampling

Edvin — Tue, 21 Aug 2018 12:01:12 GMT

Hello,

Sorry for the late reply. I have tried a couple of times to compile your project, but for some reason, which I can't figure out, I get a problem that ret_code_t is not defined. I just want to check with you whether you have done something that you can think of to cause that compiler error with any of the files in the "tj" folder?

Best regards,

Edvin

RE: Glitches in adc sampling

Omri Friedman — Thu, 16 Aug 2018 11:47:06 GMT

In the above code that works for me there is one thing that is very timing sensitive.

This is the end of my above code::

NRF_PPI->CHENCLR = PPI_CHENCLR_CH1_Clear << PPI_CHENCLR_CH1_Pos;
NRF_PPI->CH[1].EEP = (uint32_t) &NRF_SAADC->EVENTS_END;
NRF_PPI->CH[1].TEP = (uint32_t) &NRF_SAADC->TASKS_STOP;
NRF_PPI->CHENSET = PPI_CHENSET_CH1_Enabled << PPI_CHENSET_CH1_Pos;
while ( NRF_SAADC->EVENTS_STOPPED==0 );

nrf_delay_us(2); // problem !!!

NRF_SAADC->ENABLE = (SAADC_ENABLE_ENABLE_Disabled << SAADC_ENABLE_ENABLE_Pos);

If i add the 2us delay i get stuck in the 1.2mA excessive power consumption.

This delay is the exact latency of the ADC interrupt, when i try to implement it using an interrupt.

Do you know why is that?

RE: Glitches in adc sampling

Omri Friedman — Tue, 14 Aug 2018 12:40:27 GMT

devzone.nordicsemi.com/.../pump_5F00_ble-for-nordic-devzone.zip

The attached project runs on IAR 8.20.1.xxx

It runs as is on our target board and on Nordic EVAL board.

Every 4 seconds it performs SAADC sampling of 90 samples and shuts down the SAADC.

When ADC_TEST is defined 1 the test runs fine (polling mode).

When ADC_TEST is defined 2 the test runs fine for the first few times and then it stuck consuming 1.2mA forever (even though all seems to keep on running as before - sampling every 4 seconds).

The test is triggered by calling "void a2d_test(void)"

RE: Glitches in adc sampling

Edvin — Tue, 14 Aug 2018 10:56:45 GMT

When you are writing here, you should see a button near the top called "Insert". Press Insert->Insert image/video/file->From: File upload->Browse, and you can browse to the zip folder that you want to send.

BR,

Edvin

RE: Glitches in adc sampling

Omri Friedman — Tue, 14 Aug 2018 10:55:11 GMT

How do i send the ZIP file?

RE: Glitches in adc sampling

Edvin — Tue, 14 Aug 2018 07:03:13 GMT

I realize I forgot to tell you how to upload a project:

If you have not modified any files outside the project folder, then you can zip the project folder.

E.g. if I wanted to send you my ble_app_uart folder located in the folder: SDK\examples\ble_app_uart.

To check if you have modified any files outside this folder, try to unzip the folder in a fresh unzip of the SDK. If the project runs fine, it is ok. If you get any errors, then you have probably changed some files outside the project folder. Please include these files as well (add them inside the project folder, and I can include them in the project).

BR,

Edvin

RE: Glitches in adc sampling

Edvin — Tue, 14 Aug 2018 06:06:09 GMT

Hello,

That seems like a reasonable solution. I believe that the problem when doing SAADC sampling fast is that the events are showing up in the wrong order, and the difficult part is to stop the sampling at the correct time, so that you don't do an extra sample, causing a shift in the buffer.

Imagine that you are sampling channels: 1,2,3,1,2,3,1,2,3, ...You want to stop after channel 3, but a delayed stop may cause it to stop on channel 1, that is one more than you intended.

Another approach you can test is to disable the CHEN, which I see that you do:

NRF_PPI->CHENCLR = PPI_CHENCLR_CH1_Clear << PPI_CHENCLR_CH1_Pos; which should stop the "ADC train".

I will talk to someone in the ADC group. Please keep me updated if you find anything new.

Best regards,

Edvin

RE: Glitches in adc sampling

Omri Friedman — Mon, 13 Aug 2018 13:48:00 GMT

Thanks for all the effort. I appreciate it.

I have already connected EVENTS_END to TASKS_START and this is the way i am working ever since.

The problem is that when i STOP the ADC i do it manually (not through PPI) and get excessive 1.2mA power consupmption.

In the last hour i may have a breakthrough by using PPI to connect EVENTS_END to TASKS_START as you suggested, but on the last SAADC buffer i sample, i overwrite this PPI channel such that EVENTS_END will do TASKS_STOP instead.

This approach seems to work.

I will try to use it in my real code (now i am using jut a side SAADC test) and see if it works.

Can you consult with the SAADC expert to see if my solution makes sense?

I will send you the project later on (how d oi do that?).

This is what i do at init with PPI:

// connect the timer to adc sampling
NRF_PPI->CH[0].EEP = (uint32_t) &NRF_TIMER1->EVENTS_COMPARE[0];
NRF_PPI->CH[0].TEP = (uint32_t) &NRF_SAADC->TASKS_SAMPLE;

// connect end to start
NRF_PPI->CH[1].EEP = (uint32_t) &NRF_SAADC->EVENTS_END;
NRF_PPI->CH[1].TEP = (uint32_t) &NRF_SAADC->TASKS_START;

And this is what i do at run time after the last buffer EVENTS_STARTED is set:

NRF_SAADC->ENABLE = (SAADC_ENABLE_ENABLE_Disabled << SAADC_ENABLE_ENABLE_Pos);

RE: Glitches in adc sampling

Edvin — Mon, 13 Aug 2018 13:33:50 GMT

Hello,

I am sorry that this is taking a while. Trust me, if I knew exactly what to do to fix this, I would have told you at once. I have also consulted with our SAADC guys, and they only point to Jørgens answer in the ticket that I linked to in an earlier post:

Use PPI to trigger START task on an END event. This will avoid the delayed triggering og the START task due to a queued interrupt generated by the END event, but in the case of high sample frequency and long delays, it can cause your buffer to be overwritten before you are able to process the buffer. In case of using this solution, it is neccessary to use double buffering and large enough buffers to avoid data loss.

I am sorry. I meant that you should connect EVENTS_END with TASKS_START.

Then you only need to start the SAADC by calling the first sample call.

Is it possible to send the project, and I can look at it, or maybe get the SAADC experts to do it. Is it possible to reproduce on a regular DK, or do you have a custom board?

Best regards,

Edvin

RE: Glitches in adc sampling

Omri Friedman — Mon, 13 Aug 2018 09:31:08 GMT

Nothing happens when i do that. No sampling at all.

Nothing also happens when i do:

NRF_PPI->CH[0].EEP = (uint32_t) &NRF_TIMER1->EVENTS_COMPARE[0];
NRF_PPI->CH[0].TEP = (uint32_t) &NRF_SAADC->TASKS_SAMPLE;
NRF_PPI->FORK[0].TEP = (uint32_t) &NRF_SAADC->TASKS_START;

RE: Glitches in adc sampling

Edvin — Mon, 13 Aug 2018 08:27:07 GMT

Did you try to change the TASKS_SAMPLE to TASKS_START (now at NRF_PPI->CH[0].TEP = (uint32_t)&NRF_SAADC->TASKS_START;

Like I suggested in the previous reply?

Best regards,

Edvin

RE: Glitches in adc sampling

Omri Friedman — Mon, 13 Aug 2018 08:11:09 GMT

I still haven't solved the excessive power consumption issue.

In order to isolate the problem i have this code here that i use to test:

void a2d_test(void)
{
  // timer that clocks the adc once every 18us 
  NRF_TIMER1->MODE = (TIMER_MODE_MODE_Timer << TIMER_MODE_MODE_Pos); 
  NRF_TIMER1->PRESCALER = 4; // 1mhz --> 1us 
  NRF_TIMER1->CC[0] = 18; 
  NRF_TIMER1->SHORTS = TIMER_SHORTS_COMPARE0_CLEAR_Msk;

  // connect the timer to adc sampling 
  NRF_PPI->CH[0].EEP = (uint32_t) &NRF_TIMER1->EVENTS_COMPARE[0];
  NRF_PPI->CH[0].TEP = (uint32_t) &NRF_SAADC->TASKS_SAMPLE;

  // enable ppi 
  NRF_PPI->CHENSET = PPI_CHENSET_CH0_Enabled << PPI_CHENSET_CH0_Pos;

  // configure the adc to sample 3 channels 111 samples per channel (total 333 samples)
  NRF_SAADC->ENABLE = (SAADC_ENABLE_ENABLE_Enabled << SAADC_ENABLE_ENABLE_Pos);
  NRF_SAADC->RESOLUTION = NRF_SAADC_RESOLUTION_12BIT;
  NRF_SAADC->OVERSAMPLE = NRF_SAADC_OVERSAMPLE_DISABLED;
  NRF_SAADC_EVENTS_CLEAR(EVENTS_END)
  NRF_SAADC_EVENTS_CLEAR(EVENTS_STARTED)
  for ( int i=0; i<3; i++ )
  {
    NRF_SAADC->CH[i].PSELN = NRF_SAADC_INPUT_DISABLED;
    NRF_SAADC->CH[i].CONFIG =
            ((NRF_SAADC_RESISTOR_DISABLED   << SAADC_CH_CONFIG_RESP_Pos)   & SAADC_CH_CONFIG_RESP_Msk)
            | ((NRF_SAADC_RESISTOR_DISABLED << SAADC_CH_CONFIG_RESN_Pos)   & SAADC_CH_CONFIG_RESN_Msk)
            | ((NRF_SAADC_GAIN1_4           << SAADC_CH_CONFIG_GAIN_Pos)   & SAADC_CH_CONFIG_GAIN_Msk)
            | ((NRF_SAADC_REFERENCE_VDD4    << SAADC_CH_CONFIG_REFSEL_Pos) & SAADC_CH_CONFIG_REFSEL_Msk)
            | ((NRF_SAADC_ACQTIME_3US       << SAADC_CH_CONFIG_TACQ_Pos)   & SAADC_CH_CONFIG_TACQ_Msk)
            | ((NRF_SAADC_MODE_SINGLE_ENDED << SAADC_CH_CONFIG_MODE_Pos)   & SAADC_CH_CONFIG_MODE_Msk)
            | ((NRF_SAADC_BURST_DISABLED    << SAADC_CH_CONFIG_BURST_Pos)  & SAADC_CH_CONFIG_BURST_Msk);
  }
  NRF_SAADC->CH[0].PSELP = NRF_SAADC_INPUT_AIN1;
  NRF_SAADC->CH[1].PSELP = NRF_SAADC_INPUT_AIN2;
  NRF_SAADC->CH[2].PSELP = NRF_SAADC_INPUT_AIN3;
  NRF_SAADC->RESULT.PTR = (uint32_t)train_adc_buffer[0];
  NRF_SAADC->RESULT.MAXCNT = 333;
  NRF_SAADC_EVENTS_CLEAR(EVENTS_STARTED)
  
  // trigger the timer that clocks the adc 
  NRF_TIMER1->TASKS_START = 1; // 

  // repeat 10 times 
  for ( int i=0; i<10; i++ )
  {
    // trigger the adc 
    NRF_SAADC->TASKS_START = 1;
    
    // wait until adc ends its sampling (not stopped)  
    NRF_SAADC_EVENTS_CLEAR(EVENTS_END)
    while (NRF_SAADC->EVENTS_END==0);

    // set its pointer to the desired location 
    NRF_SAADC->RESULT.PTR = (uint32_t)train_adc_buffer[0];
  }

  // stop the ADC 
  // problem - any delay i add here or any interruption between EVENTS_END and STOP casues permaenent 1.2ma consumtion nrf_delay_us(3);
  NRF_SAADC_EVENTS_CLEAR(EVENTS_STOPPED)
  NRF_SAADC->TASKS_STOP = 1;
  while (NRF_SAADC->EVENTS_STOPPED==0);
  
  // disable the adc 
  NRF_SAADC->ENABLE = (SAADC_ENABLE_ENABLE_Disabled << SAADC_ENABLE_ENABLE_Pos);
  NRF_SAADC->CH[0].PSELP = NRF_SAADC_INPUT_DISABLED;
  NRF_SAADC->CH[1].PSELP = NRF_SAADC_INPUT_DISABLED;
  NRF_SAADC->CH[2].PSELP = NRF_SAADC_INPUT_DISABLED;

  // disaple the ppi   
  NRF_PPI->CHENCLR = (PPI_CHENCLR_CH0_Clear << PPI_CHENCLR_CH0_Pos); 

  // disable the timer   
  NRF_TIMER1->TASKS_STOP = 1;
  NRF_TIMER1->SHORTS = 0;
  NRF_TIMER1->TASKS_SHUTDOWN = 1;
}

Please look at the comment where i say "problem" right when stopping the ADC.

Whenever i have a delay between EVENTS_END and NRF_SAADC->TASKS_STOP=1; i get excessive permanent power consumption of ~1.2mA.

From this point on there is no way to reduce the power unless i RESET the chip.

If i use PPI to STOP the ADC, the problem is gone since EVENTS_END and TASK_STOP occur at the same time. But in my system i cannot do this.

Do you now about this issue and why it occurs?

RE: Glitches in adc sampling

Edvin — Tue, 31 Jul 2018 14:03:15 GMT

Hello,

I haven't worked with the workaround in that post, but I see that you trigger TASKS_SAMPLE from the &NRF_TIMER1->EVENTS_COMPARE[0]; in PPI, so it might very well be the issue.

What happens if you try to change TASKS_SAMPLE with TASKS_START in NRF_PPI->CH[5].TEP ?

Best regards,

Edvin

RE: Glitches in adc sampling

Omri Friedman — Sat, 21 Jul 2018 12:08:30 GMT

Thanks, Edvin. I have already seen the link you have provided and also posted my question over there as well few days ago.

I believe my situation is different since i have used PPI to chain END event to START task of the SAADC sampling (one of the solution suggested in the link you have provided), and this works fine. i do not have any channels swaps during an on-going continuous sampling.

My problem is that the channels swap occurs when restarting SAADC sampling some time after i aborted a previous sampling. When doing that i have a constant channels swap.

To overcome this i need to add 10us delay in the SAADC abort routine (as i already explained above in the last provided code example).

All i need is for you to confirm that that my SAADC abort patch with the 10us delay makes sense.

I have added 10us delay here:

NRF_SAADC->TASKS_STOP = 0x1UL;
uint32_t timeout = 10000;
while (NRF_SAADC->EVENTS_STOPPED==0 && timeout > 0)
{
--timeout;
}
ASSERT(timeout > 0);
nrf_delay_us(10); // new - delay equal to two samples (3us sampling rate + 2us convert)
NRF_SAADC->ENABLE = (SAADC_ENABLE_ENABLE_Disabled << SAADC_ENABLE_ENABLE_Pos);

RE: Glitches in adc sampling

Edvin — Fri, 20 Jul 2018 12:23:08 GMT

Hello,

I have spoken with some of out ADC engineers. They say that this is most likely related to a bug.

Can you please check Jørgen's answer marked in green on this page:

https://devzone.nordicsemi.com/f/nordic-q-a/20291/offset-in-saadc-samples-with-easy-dma-and-ble

Best regards,

Edvin

RE: Glitches in adc sampling

Omri Friedman — Thu, 19 Jul 2018 08:01:11 GMT

yes. readings are ok, they just appear in the wrong location in the RAM buffer. As if the EasyDMA starts from the 2nd sample and thus a constant offset occurs - {ch1,ch2,ch0,ch1,ch2...} instead of {ch0,ch1,ch2,ch0,ch1,ch2...}

I did registers dump before i start the SAADC each time, and when i disable the SAADC before i start it again (the "if 0" code), i see some leftover value in the RESULT.AMOUNT register that its value is somewhere in between 0x00000000 and 0x00000192 (0x192 is the buffer size - 402). I also see EVENTS_STOPPED=1.

how can i clear down RESULT.AMOUNT before i start SAADC samling?

I modified the code used to shut down the ADC and added delay and it seems to work,

This is the code:

  uint8_t val;
  sd_nvic_critical_region_enter(&val); // new - prevent interruption 
  NRF_SAADC->INTENCLR = NRF_SAADC_INT_ALL; 
  NVIC_DisableIRQ(SAADC_IRQn);
  while ( NRF_SAADC->EVENTS_END==0x0UL ); // new - ensure end alignmnet 
  NRF_SAADC->EVENTS_STOPPED = 0x0UL;
  volatile uint32_t dummy = NRF_SAADC->EVENTS_STOPPED;
  (void)dummy;
  NRF_SAADC->TASKS_STOP = 0x1UL;
  uint32_t timeout = 10000;
  while (NRF_SAADC->EVENTS_STOPPED==0 && timeout > 0)
  {
    --timeout;
  }
  ASSERT(timeout > 0);
  nrf_delay_us(10); // new - delay equal to two samples (3us sampling rate + 2us convert)
  NRF_SAADC->ENABLE = (SAADC_ENABLE_ENABLE_Disabled << SAADC_ENABLE_ENABLE_Pos);
  sd_nvic_critical_region_exit(val); // new

Look at "new" comments to see what i have added.

Seems like the proper sampling of SAADC is directly affected by the timing i use to shut down the SAADC.

I must understand why is that and what am i doing wrong?

I also saw this issue that seems relevant:

https://devzone.nordicsemi.com/f/nordic-q-a/16885/saadc-scan-mode-sample-order-is-not-always-consistent/134614#134614

RE: Glitches in adc sampling

Edvin — Thu, 19 Jul 2018 07:37:56 GMT

Does this mean that the readings, other from that the channels are swapped, are ok? They are not suppose to have the same pattern as before the brake in the readings?

I.e. in the graph from your original post, only the colors are wrong after X = 4561?

BR,

Edvin

RE: Glitches in adc sampling

Omri Friedman — Wed, 18 Jul 2018 10:05:43 GMT

1. Yes - shutting down the SAADC (the "#if 0" code) causes the problem to occur in most of the times.

2. I did check the 3 PSELP registers and they all contain correct values when the problem occur, so this is not the root cause. You can also see that my code has very simple in that respect:

NRF_SAADC->CH[0].PSELP = NRF_SAADC_INPUT_AIN1;
NRF_SAADC->CH[1].PSELP = NRF_SAADC_INPUT_AIN2;
NRF_SAADC->CH[2].PSELP = NRF_SAADC_INPUT_AIN3;

3. My guess is that when re enabling the SAADC the ADC samples one channel, but not to the EasyDMA and when it starts filling up the DMA buffer the entire sampling shifts one sample causing me to see the 2nd channel where the 1st channel is expected. Instead of {ch0,ch1,ch2,ch0,ch1,ch2...} i see {ch1,ch2,ch0,ch1,ch2...}.

RE: Glitches in adc sampling

Edvin — Wed, 18 Jul 2018 09:18:45 GMT

Hello,

I understand. If you replace "#if 0" with "#if 1", the problem occurs.
I assume that you have set flag_stop_sampling to false before start_adc_sampling, right?

Can you try to break in the handler when the issue occurs, and try to read the registers:
NRF_SAADC->CH[0].PSELP,
NRF_SAADC->CH[1].PSELP,
NRF_SAADC->CH[2].PSELP,

And see whether they are still configured to the right pins, or if any of them are disabled?

Best regards,
Edvin

RE: Glitches in adc sampling

Omri Friedman — Wed, 18 Jul 2018 05:14:18 GMT

I start the sampling again at least few seconds later from stopping it. It is done from main() by calling start_adc_sampling()

What i think i am looking is to understand why the initial call to start_adc_sampling works, while a call after stopping the sampling does not work (it only work if i do NOT do the code the is commented out by '#if 0 ... #endif').

By the way - the attached code is just part of a bigger chunk of code involving 9 PPI channels, all 4 timers and 4 GPIOTE. It deals with rotating a stepper motor and sampling input from 2 encoder channels + another sensor (these are shown in the picture i placed)

RE: Glitches in adc sampling

Edvin — Tue, 17 Jul 2018 14:57:55 GMT

Hello,

Where do you re-enable the SAADC? That is, if flag_stop_sampling was set to 1, and then you start the sampling again?

Best regards,

Edvin