This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Consecutive ADC PPI triggered by RTC1 offset problem - ADC event trigger on the wrong sample

Hi All

I am using S130, nRF51822, SDK12, My RTC1 compare events is connected by PPI to ADC, I have set it to generate an adc_ppi_event_handler after 6 consecutive compare events, or after 2 events of 3 consecutive samples (so I get 2 adc_ppi_event_handler events for 6 compare events), this usually works fine, I count the NRF_RTC1->EVENTS_COMPARE[2] at the RTC1_IRQHandler to see I get a total of 6 samples, expect to count 6 events from beginning of the process and I assure I counted until 6 when I get my adc_ppi_event_handler.

Lately I encounter a bug in which the ADC fails to properly get 6 sample counts at the point of adc_ppi_event_handler , I was able to recreate this and saw using a scope a change in behavior, the adc_ppi_event_handler event actually is triggered, for example, after the 5th compare events, sometimes there is a different offset, as if there was already one sample in the buffer when the process began. I recreated the problem by purposely interfering with the RTC-compare register during sampling process, I am not sure what causes those offset or interfere with the register when I am not the one generating the problem through a backdoor, it takes a lot of time for it to happen "naturally".

I would like to know 

1. if you have any idea of what causes it and how can I prevent it.

2. How can I reset the adc-ppi-rtc1 cycle, and eliminate this "offset".

Would appreciate any help, ideas and inputs

Thanks!

Parents
  • Hi,

    The only thing that comes to mind is that the ADC interrupt handler is not able to read out the result before the next sample is triggered by PPI, for instance if it is blocked by the softdevice.

    What is the sample interval? Can you post the code you used for configuring the ADC and PPI?

    Best regards,
    Jørgen

  • Hi,

    PPI does not have any awareness of the state of the ADC buffers and sample counts, this is simply a hardware signal going from an EVENT generated by one peripheral to a TASK of another peripheral. 

    The ADC in nRF51 series ICs also does not have any buffering functionality for the ADC, every sample needs to be read out from the peripheral by the CPU, before the next sample can be started. Storing of multiple samples into a single buffer is handled by the ADC driver. 

    When you say "resetting the ADC-PPI before every time I start sampling", when exactly do plan to do this? Do you start the RTC at a given time to start sampling, i.e., it does not sample continuously into 6 sample buffers? There seems to be no APIs to stop an ongoing conversion in the ADC driver, but you can check nrf_drv_adc_is_busy() and then trigger nrf_drv_adc_sample() until you get the NRF_DRV_ADC_EVT_DONE event.

    Best regards,
    Jørgen

Reply
  • Hi,

    PPI does not have any awareness of the state of the ADC buffers and sample counts, this is simply a hardware signal going from an EVENT generated by one peripheral to a TASK of another peripheral. 

    The ADC in nRF51 series ICs also does not have any buffering functionality for the ADC, every sample needs to be read out from the peripheral by the CPU, before the next sample can be started. Storing of multiple samples into a single buffer is handled by the ADC driver. 

    When you say "resetting the ADC-PPI before every time I start sampling", when exactly do plan to do this? Do you start the RTC at a given time to start sampling, i.e., it does not sample continuously into 6 sample buffers? There seems to be no APIs to stop an ongoing conversion in the ADC driver, but you can check nrf_drv_adc_is_busy() and then trigger nrf_drv_adc_sample() until you get the NRF_DRV_ADC_EVT_DONE event.

    Best regards,
    Jørgen

Children
No Data
Related