ADC7172-2 randomly converts 0x000000 or 0xFFFFFF

DOCX

Hi,
We are using our AD7172-2 AD converter in our prototype board ( AVDD1 = +5V, AVDD2 = +5V, IOVDD=+3.3V, AVSS = 0V) single ended mode (+=CNH0, GND=CHN1) with continuous conversion, running it from internal clock and internal reference voltage. The AD7172-2 is driven from the Silicon Labs’ Giant Gecko 32-bit ARM Cortex M4 MCU starter kit using its’ USART0 on 12MHz, in SPI3 mode. The problem is that our long-term stability test is failed. We have an error counter set to see how many times we have 0x000000 or 0xFFFFFF conversion result. (We have 660mVRMS  sine voltage, shifted to +1.25VDC, with +2.5V reference voltage, so the conversion result would never be 0x0000000 nor 0xFFFFFF) This counter and the elapsed time are printed on a small LCD screen of starter kit with the elapsed time and a small scope which shows the last 512 samples. Sometimes the AD converter works for 30-35 minutes without error, sometimes the error code is incremented within 1 minute. Once it happens, then we have to reset (re-initialize) the ADC7172-2 chip again in order to work for another XXX minutes. If we don’t reset the chip it converts forever 0x000000 or 0xFFFFFF. (We checked this state with scope) We have two prototype boards, both have this bug. Can you help? Thanks, Louis. (see attachment for the details)

Parents
  • 0
    •  Analog Employees 
    on Mar 9, 2020 2:17 AM over 1 year ago

    Hi,

    I've checked your register map settings and analog inputs, everything is valid except for one thing, I noticed your channel register setting is 0x8101, is that a typo and supposed to be 0x8001? Can you confirmed this please?

    Can you also try to disable the interrupt and just write a simple routine for debugging? I would suggest you should try writing to a couple different registers and reading back to check that these are working correctly. It would be important that you gets reliable read and write functions that work for all registers in basic linear code before adding in additional software techniques such as interrupts. 

    On power-up, it is advisable to perform a reset by writing consecutive 64 ones to the part. This will reset the serial interface, and it will also reset the on-chip registers to their default conditions. Upon initialization, can you monitor the DRDY pin if it is pulsing at default ODR? Take note that when /CS is taken high, the DRDY pin is tri-stated. Therefore, the DRDY pin will not indicate the end of the conversion. So with /CS low, monitor the DRDY pin to see if the pin is pulsing at the default output data rate. Then try to change the output data rate by writing to the appropriate register. Read back the register to ensure that the correct value was written. Again, with /CS low, check that the DRDY pin is pulsing at the new selected output data rate.

    When DRDY stops pulsing at any time and it stays high or low (even though the ADC is configured for continuous conversion mode), this indicates that the serial interface has become asynchronous (incorrect number of SCLK pulses, glitches on the SCLK line). Ensure that the correct number of SCLK pulses are being used for each read/write operation. It is also recommended to tie DIN and SCLK high when they are not being used to prevent glitches affecting the SPI interface.

    Using the AD7172-2 with CS tied low is okay but it makes the interface less robust to interference and can cause loss of interface synchronization. When CS is low the serial interface of the AD7172-2 is always waiting for a Falling edge (i.e. logic level goes from IOVDD to DGND) of SCLK to indicate that a serial transaction is being written to the part. When it receives a falling edge it checks DIN, if DIN is high then it ignores the falling edge, if DIN is low then it expects a write to the communications register and will take the next 7 SCLK pulses as the value. So if CS is always low and DIN is floating low any noise such as 50/60Hz interference on the SCLK line could be interpreted as a write to the comms register. Tying DIN high will mean any noise on SCLK will be ignored and tying SCLK high will make it less susceptible to noise and so makes a more robust serial interface.

    And yes, when /CS is high, the DRDY pin is in high impedance state. Therefore, the DRDY pin will not indicate the end of the conversion. However, taking the /CS high will not affect the conversion if the ADC is configured for continuous conversion mode. To determine when a conversion is ready, the status register can be read periodically, the RDY bit indicating when a conversion is ready. Alternatively, /CS can be taken low periodically and the DRDY pin can be monitored.

    Thanks,

    Jellenie

  • Hi Jellenie,

    Thank you for your expert answer. I am impressed.

    • "0x8101": Yes, it is typo, sorry.
    • "Disabling interrupts": I did it. I can read the Gain and Offset always, without any error.
    • "Power up reset": Yes, I send 4x8 0xFF as the first step of initialization. If I stop the code execution after the 4th 0xFF has been sent but before I would set the CS to high, I get 31250Hz on DRDY pin.
    • "DRDY stops pulsing": Never happens.
    • Incorrect SCLK/glitches: This might happen. The problem is that if the USART0 of EFM32GG11 MCU controls the CS line automatically then it sets CS=0 before sending the first bit and reset CS=1 after sending the last one. This means we have to manually control the CS line. Some glitches might happen especially when the last TX buffer empty interrupt raised. The TX interrupt service routine checks whether we need to send or receive more bytes and if not, then sets the CS=1. I thought scope screen shots when CS was set back to 1, but there were some clock pulses, but it is very hard capture this situation.
    • "Setting SCLK high when idle": yes, it is high when it is idle
    • "Setting DIN high when idle": not sure. I think the MCU leaves it on the level of the last written bit. I will force it to be high when the last byte is sent. Thanks for the idea.
    • "When /CS is high, the DRDY pin is in high impedance state": Can you explain what is good for? I have never seen this before. The DRDY should be stand alone output pin and it should not depend on CS. It should go low when the conversion is ready independently of the state of the CS line. Can you send me a document (sample app) how Analog Devices suggest to use this chip?
    • "To determine when a conversion is ready, the status register can be read periodically, the RDY bit indicating when a conversion is ready. Alternatively, /CS can be taken low periodically and the DRDY pin can be monitored.": Polling is not good for us. It takes time, plus we have to wait DRDY =0, this makes the ADC reading with not stable frequency. We need very stable sampling frequency and the time must be the same between sampling. This cannot be established with polling technique, only with DRDY interrupt handling (within a couple 100 nanoseconds jitter).

    It seems to me that we picked the wrong chip (wrong for us). Can you advise a “more traditional” ADC, with dedicated (standalone) DRDY pin, 24-bit, internal (preferable) VREF, internal (preferable) clock, single differential/single ended channel, preferable internal gain and probably an external start input pin? The start pin would be nice to start sampling at 256 times input sine frequency for stable FFT conversions (have the same sample count in every complete input sine wave cycle)

    Thank you for your help.
    Best regards,
    Louis

  • Hi Jellenie,

     

    Thanks for the ideas/remarks!. We use a single chip, but many thanks for daisy chain info.

    The problem with the “linear” code (communication without interrupts) is that you burn the CPU time in waiting for answers. We have 72MHz clock so every 100µs counts.

    Would you please check the following communication with AD7172-2 flow chart?

    During power on reset:

    1. Chip Initialization
    2. Setup a DRDY interrupt to the falling edge of the DOUT/RDY pin of the chip (SPIx_MISO) and disable it.
    3. Setup but disable SPIx_TX and SPIx_RX interrupts.

    Measurement:

    1. Enable DRDY interrupt.
    2. Set CS= 0.
    3. When DRDY interrupt fired, then disable it (In order to avoid receiving DRDY interrupts every time if DOUT = 0).
    4. Start reading data register (Enable SPIx_TX interrupt, but disable SPIx_RX interrupt, not to receive back what you send).
    5. Quit form DRDY interrupt.
    6. In the SPIx_TX interrupt handler send the command byte = 0x44). If command byte sent then enable SPIx_RX interrupt. Write dummy 0x00 in order to generate SCLK for reading data register. When the last data bytes is read (and TX shift register is empty) then set CS=1.
    7. Disable SPIx_TX and SIPx_RX interrupts.
    8. Convert the 24-bit data to 32-bit integer.
    9. Set the global adcNewData flag to notice the host app that you have a new conversion result.
    10. Continue with step 1.

     

    It seems to me a good plan.

    Thanks for your help!

    Best regards,

    Louis

  • 0
    •  Analog Employees 
    on Mar 18, 2020 1:47 PM over 1 year ago in reply to Louie88

    Hi,

    Yup I think that looks good. May I know what does 72MHz clock? is that an SPI clock? Please take note that the max SPI clock for this part is up tp 20MHz only.

    But in case you are having another issue, just let us know.

    Thanks,

    Jellenie

  • Hi Jellenie,

    Of course the 72MHz is not the SPI SCLK. I did not mention it, I am sorry about that. The 72MHz is the maximum clock frequency of the CPU we use. I am implementing the new ADD7172-2 handling and I will send you a scope screen shot soon.

    The SPI clock is about 168nsec, 6MHz measured on scope. There is no another issue.

    Best regards,

    Louis

  • +1
    •  Analog Employees 
    on Mar 20, 2020 5:31 AM over 1 year ago in reply to Louie88

    Hi Louis.

    Thanks for confirming. If you can close this issue as well then that would be great.

    Regards,

    Jellenie

  • Hi Jellenie,

    Many thanks for your very valuable support. But before I close the project please let me mention something:

    I noticed when I put a breakpoint in the beginning of the ADC initialization, and I single step the initialization commands, then let the CPU run, the AD7172-2 always worked perfectly. But why?

    Most of us, developers, do better to learn reading (again)…

    After inserting 10ms wait time after resetting the chip it works just fine. The AD7172-2 works without any 0xFFFFFF or 0x000000 since last night, more than 12 hours. The new access protocol and keeping the rules helped a lot.

     

    Thanks,

    Louis

Reply
  • Hi Jellenie,

    Many thanks for your very valuable support. But before I close the project please let me mention something:

    I noticed when I put a breakpoint in the beginning of the ADC initialization, and I single step the initialization commands, then let the CPU run, the AD7172-2 always worked perfectly. But why?

    Most of us, developers, do better to learn reading (again)…

    After inserting 10ms wait time after resetting the chip it works just fine. The AD7172-2 works without any 0xFFFFFF or 0x000000 since last night, more than 12 hours. The new access protocol and keeping the rules helped a lot.

     

    Thanks,

    Louis

Children
  • 0
    •  Analog Employees 
    on Mar 20, 2020 10:05 AM over 1 year ago in reply to Louie88

    Hi,

    Good catch. The analog circuitry needs some time to power up and settle before the conversion begins. The datasheet lists this extra time required.

    For AD717x family there is an extra delay time at the very first conversion which is the setup time for the signal chain before the first conversion is available when the ADC is power up, coming up from standby mode or when using SYNC pin. It is always 68MCLKs for AD717x but it varies from other parts. So for MCLK of 2MHz that is around 500uS.

    Thanks,

    Jellenie