ADC7172-2 randomly converts 0x000000 or 0xFFFFFF

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 4^th 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,

May I know what is your target applications and system performance? What do you mean by start sampling at 256times the input frequency? Is that your target output data rate? If you can provide more details about these then we can recommend a product or solution that suits your application.

The DOUT and RDY functions share a pin on the ADC. So, the DRDY pin functions as a ready pin when /CS is low. Most of our new products have a shared DRDY pin. 

Some of our older products such as AD7730, the DOUT and DRDY lines are separate and DRDY indicates when conversions are ready even when CS is high. However, we do not recommend old products in terms of performance because newer have better performance and more added features.

One possible solution is to use the SYNC pin as the start pin and you can calculate the expected time and time out the conversion availability upon releasing the SYNC pin. From here you can determine when will be the correct time to pull the /CS low. 

One thing to note here is when AD7172 is using SYNC pin as the start of conversion there is about 68MCLKs additional time as a processing time in the very first conversion upon releasing the SYNC pin. The extra delay is 68MCLKs, so if you have MCLK=16MHz. Then delay = 68(1/16MHz) = 4.25uS. The delay is always present at the very first conversion upon power up, when the ADC is coming up from standby mode or when SYNC pin is used to start the conversion, or if there is a manual switch of channel or a change in configuration. In terms of the timing requirement, I would suggest to check on VE tool to see the expected timing for every configuration. 

http://beta-tools.analog.com/virtualeval/#tool_pid=AD7172-2&tab=fbd

Thanks,

Jellenie

Hi Jellenie,

Thank you for your answer.

1.    We would use the AD7171-2 in flow meters (Magnetic, Coriolis).

2.    I exactly understand that the DOUT is shared with RDY. I just can’t understand what is good for? With this sharing we never know whether a conversion is ready or not. If we keep the CS = 0, then the AD7172-2 might measure 0x000000 or 0xFFFFFF always. It is just matter of time. Can you send me a flow chart how Analog Devices imagines using the shared DOU/RDY pin? (Polling status register is not the option for us)

3.    Thanks for the link to the Virtual Eval Tool Beta. It is an amazing tool. But, may I suggest/ask to add a second diagram on Timing tab which shows, how to initialize all the registers to the user selected mode? Currently the ADC mode and IF mode registers are shown on the timing diagram, but those are always the same (The written values do not change when I enable the internal reference or change the mode to unipolar, etc….). This would be a big help for the users.

4.    Using the SYNC pin to start the ADC manually is an option, but it is complicated. For reliable FFT conversion we need to know the input frequency of the measured sine wave, multiply it by – say – 256 (with a PLL) and start the ADC at the next zero cross and take 256 samples. This technique ensures that you will get always 256 samples per period of input sine wave with the same time between samples regardless the frequency of input sine wave. (It is limited by the max sampling frequency of the AD converter)

5.    On the timing diagram, CS is always low, like in our design. Earlier you mentioned it is not too “healthy”.

Thank you for your help.
Best regards,
Louis

Hi Jellenie,

I have new observations.

I modified the initialization of AD7172-2 and I set it to send the Status byte with the conversion results, so I receive 4 data bytes at every read data register command. When the ADC works good the status register is always 0x00. I also removed resetting the AD7172-2 when I set CS = 0. Currently the CS = 0 for 33.3ms (30Hz sine wave). While CS = 0 I am collecting the conversion results of the ADC and the status byte belongs to the sample. When the 33,3ms elapsed (one complete sine wave cycle) I set CS = 1 and I stop reading the chip. I process the data, draw the waveform to the LCD display, display the RMS voltage, period time, frequency of the input sine wave signal. Then the data collection (CS = 0) / LCD refresh phase are repeated.

• It worked for 1 hour, 28 minutes then the AD7172-2 begun to convert to 0x000000.
• Every sample is 0x000000.
• The sampling frequency did not change. It is 15625Hz.
• The status register contains 0x40 in every sample. This is the ADC_ERROR bit. It is set when the ADC converts 0x000000 or 0xFFFFFF. (Under and over the normal range = 0V to +2.5V) The ADC_ERROR = 1 since AD7172-2 begun to convert 0x000000. But this is not under range error. The chip has 660mVRMS sine wave shifted to +1.25VDC. I measured it on the AIN1 pin (22).
• If the AD converter didn’t get input voltage then it still could measure +1.25VDC always. This is the null voltage. It should convert around 0x800000.
• I reset the CPU. (Not the power) The CPU also reset the AD7172-2 and rewrote all the (necessary) registers the AD7172-2 and the chip begun to work normally.

Now I will reset the AD7172-2 if I have 16 times ADC_ERROR=1 continuously. I will also measure the time to elapsed since the last ADC_ERROR.

Best regards,

Louis

PS: Meanwhile I was writing this comment it happened again. This time the AD7172-2 converts 0xFFFFFF forever. I attached two scope screen shots. the 20200313-full-read-cmd.jpg shows one cycle of reading AD data register and Status byte.

Yellow = CS, Blue = SCLK, Pink = MOSI (Command = 0x44), Green = MISO (Conversion result + Status byte)

The 20200313-dataonly-read-cmd.jpg shows the answer part of the read command. You can see the bit6 set in the status byte.

Hi,

1. I believe AD717x may suit this application. We also have available articles that may help you in terms of system design especially designing the AFE for your application. Please see link below.

https://www.analog.com/en/analog-dialogue/articles/electromagnetic-flow-meters.html

2. We understand and appreciate your concern about the shared DOUT and RDY functions. We did this so that the part can fit in the smallest package. It is certainly something that we will review on future products.

I am not sure about the flowchart that you are requesting. But I can give you the details on how the shared pin works. The DOUT and RDY functions share a pin on the ADC. So, the DRDY pin functions as a ready pin when /CS is low. Every time a conversion is completed, this pin goes low, indicating to the microprocessor that a valid conversion is available. When the user requests a read of the data register, the DRDY pin functions are a DOUT pin. When pulses are applied to the SCLK pin, the data is placed on the DOUT pin. The change from the DOUT to the RDY function occurs on the last SCLK rising edge. However, using the DOUT_RESET bit, the instant at which the DRDY pin changes from being a DOUT pin to RDY pin is programmable.

3. Again, thanks for your feedback we will consider this on our future updates.

4. In terms of the sampling requirements and target output data rate, you may want to consider using AD7175 instead, it can operate up to 250ksps and could meet your timing requirement.

5. Apologies for misunderstanding my statement. What I meant with this is if you hardwire/tied your /CS pin to 0 (GND) externally and cannot be controlled by your MCU. Like I pointed above the part is less robust when /CS is always low. The part is more robust in that taking CS high resets the serial interface. So when /CS is pulled high the read/write transaction is being aborted and returns to expecting a write to the Comms register. You will just need to modify your code so CS only frames the entire SPI transaction, that is /CS has to be low for the whole of the data transmit and receive. Same thing when you tried to monitor the DRDY pin for conversion, /CS has to be low until it triggers the end of conversion.

Thanks,

Jellenie

Hi,

Writing 64 1s should reset the AD7124 if the problem is due to spikes on the serial interface causing the serial interface to become asynchronous. We normally recommend that a customer perform a reset after powering up to ensure that all registers are in a good known stage. Writing 64 1s will do this. If writing 64 1s does not reset the part, then the problem is more likely due to the ADC latching up - the problem may be due to over voltages on input pins.

Have you tried to monitor the ADC inputs at the whole time conversion process and see if there are overvoltage occurring? If you can also monitor the digital interface and see if there are some spikes/glitches affecting the serial interface.

Thanks,

Jellenie

Hi Jellenie,

Thanks for the detailed answers and your help.

Flow chart:

Here is how a „traditional” ADC data read looks like. Traditional means: it has 4-pin SPI and a dedicated DRDY pin which goes down when the new conversion result is available in ADC, regardless of the state of CS pin.

1. Set up an interrupt for the falling edge of DRDY pin of the ADC
2. Set CS = 1 of the ADC
3. When the DRDY interrupt happens then set CS = 0, start reading the data register of the ADC, clear the DRDY interrupt flag and quit from DRDY IRQ service routine. (The data should be read with interrupt driven SPI handler)
4. When the last byte is read by SPI (and the RX shift register is empty) then set CS=1.
5. Convert the 24-bit data to 32-bit integer.
6. Set the adcNewData flag to notice your app that you have a new conversion result.
7. Wait for the next DRDY interrupt

If your SPI is fast enough, then you will capture all conversion results (Max sampling rate 31250Hz in case of AD7171-2) The time elapsed between samples will be the same +/- interrupt latency.

I wonder how you can do this if the DOUT is shared with DRDY? I would like to see the same procedure which works with AD7172-2 shared DOUN/DRDY pin.

Thank you for your help.

Best regards,

Louis

Hi Jellenie,

Thanks for the detailed answers and your help.

Flow chart:

Here is how a „traditional” ADC data read looks like. Traditional means: it has 4-pin SPI and a dedicated DRDY pin which goes down when the new conversion result is available in ADC, regardless of the state of CS pin.

1. Set up an interrupt for the falling edge of DRDY pin of the ADC
2. Set CS = 1 of the ADC
3. When the DRDY interrupt happens then set CS = 0, start reading the data register of the ADC, clear the DRDY interrupt flag and quit from DRDY IRQ service routine. (The data should be read with interrupt driven SPI handler)
4. When the last byte is read by SPI (and the RX shift register is empty) then set CS=1.
5. Convert the 24-bit data to 32-bit integer.
6. Set the adcNewData flag to notice your app that you have a new conversion result.
7. Wait for the next DRDY interrupt

If your SPI is fast enough, then you will capture all conversion results (Max sampling rate 31250Hz in case of AD7171-2) The time elapsed between samples will be the same +/- interrupt latency.

I wonder how you can do this if the DOUT is shared with DRDY? I would like to see the same procedure which works with AD7172-2 shared DOUN/DRDY pin.

Thank you for your help.

Best regards,

Louis

Hi,

I think one thing to change there is to set CS=0 upon waiting for the DRDY to go low. You can put CS=1 after every read/write transaction but when monitoring the DRDY pin and writing/reading to/from the registers you have to put your /CS low. I imagine this easy to implement when you are using a single device and the SPI is not sharing with other devices. However, for a system that uses multiple AD717x devices, the interface can be simplified by synching the devices. The customer would then only need to monitor the DRDY signal from the master device. When the master DRDY goes low, read its conversion. At this point, the other ADCs will also have conversions available so their DRDY signals do not need to be monitored. This architecture would simplify the connections between the ADCs and the uC.  

It would be also important and a good practice  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.

Thanks,

Jellenie

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

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

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

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