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

ADC reads come in out of order from Driver

When reading in values from ADC under high noise conditions the ADC reads come into the handler out of order. This is causing application resets left and right, does anyone having experience dealing this this issue?

Parents
  • I'm wondering if it's not the other way around, high noise conditions are causing HW resets and the resets are messing up the order of the ADC. 

  • When I say the application resets I don't necessarily mean that the nrf chip gets a HW reset. Our application goes into an emergency protection mode and shuts off a high power device it's controlling. We have also seen HW resets, but not as often.

    Wouldn't a true HW reset actually reset the ADC reads using the driver??

    Thanks for the feedback.

  • "Wouldn't a true HW reset actually reset the ADC reads using the driver??" 
    The driver does not clear the memory of a buffer before it starts writing to it. 

    "When reading in values from ADC under high noise conditions the ADC reads come into the handler out of order."

    1. What do you mean by high noise conditions?
    2. Do you experience this issue when not in these high noise conditions?
    3. I think there's more likely a discrepancy between what you expect the SAADC to do and what you've configured it to do. Do you have more information on the configuration of the SAADC and what you aim to achieve?
    • What do you mean by high noise conditions?
      • SMPS in the 1000W range within 10 inches of the chip
    • Do you experience this issue when not in these high noise conditions?
      • Rarely, but it happens.
    • I think there's more likely a discrepancy between what you expect the SAADC to do and what you've configured it to do. Do you have more information on the configuration of the SAADC and what you aim to achieve?
      • I'm trying to configure the ADC to read in a single sample from 7 channels on a PPI interrupt at an interval of approximately 340us. 

  • "SMPS in the 1000W range within 10 inches of the chip"
    -It would be beneficial to get a scope of the supply voltage when the issue occurs. Large PSUs like that usually has a lot of ripple noise. 

    "Rarely, but it happens."
    -That is interesting. Is seems to indicate that issue occurs in the presence of the PSU, and the nature of the issue (samples out of order) seems to indicate a soft/hard reset or a broken logical state machine in SW. A scope of VDD and your source code would help a lot.

    "I'm trying to configure the ADC to read in a single sample from 7 channels on a PPI interrupt at an -interval of approximately 340us."
    I'd like to see your source code. 

    We can change from public to private Question if you do not want to share your IP with the public. 

Reply
  • "SMPS in the 1000W range within 10 inches of the chip"
    -It would be beneficial to get a scope of the supply voltage when the issue occurs. Large PSUs like that usually has a lot of ripple noise. 

    "Rarely, but it happens."
    -That is interesting. Is seems to indicate that issue occurs in the presence of the PSU, and the nature of the issue (samples out of order) seems to indicate a soft/hard reset or a broken logical state machine in SW. A scope of VDD and your source code would help a lot.

    "I'm trying to configure the ADC to read in a single sample from 7 channels on a PPI interrupt at an -interval of approximately 340us."
    I'd like to see your source code. 

    We can change from public to private Question if you do not want to share your IP with the public. 

Children
  • Unfortunately we won't be able to provide code at this time.

    We have however, after months of back and forth, determined that the system instability is likely due to a DAC being used to control the setpoint for the power supply.

    The current plan is to retest the conditions which led to out of order ADC reads. Will keep this up to date.

  • This sounds similar to the problem I once observed.
    I measured samples in two channels in "scan mode". After stopping the measurement, the samples were always correctly arranged. Next after resuming the measurement and stopping it again, I observed that the samples were swapped in places. I.e. the samples from the first channel were in the buffer in the place where the samples from the second channel should be.

    The good news is that there is quite a simple fix. Always after the first measurement (stopping SAADC) the samples in the buffer are well arranged. Therefore it is enough to re-initialize SAADC after each measurement: call uninit and init functions.

Related