Post Go back to editing

AD7616 Failed Serial Communication

Category: Hardware
Product Number: AD7616
Software Version: Custom Microcontroller Software

I am working on a project involving reading sensor data using an AD7616 in Software Serial mode. There are 3 problems that I have encountered: There is never any value returned in response to a read register command, the ADC appears to not change register contents in response to a write register command, the values that are returned from a conversion are inconsistent for a consistent input voltage. We have verified the electrical configuration of our PCB for Software Serial mode, that is HW_RNGSEL = 00, SER/PAR = 1, SER1W = 1. We use the internal reference with REFSEL = 1. The undriven analog input pins hover at around 2V. When the pins are driven and a conversion is done (asserting CONVST and waiting for BUSY) the result does correspond to the input voltage, but the slope of the output is very inconsistent, going from around 1000 counts for a 1V increase to less than 500 counts for the same increase. When I try to write to the channel register to change which channel is being selected it has no effect. When I read any register the result is always 0. The setup algorithm is to first reset the ADC, do a dummy conversion, then right to the range registers to the change to +- 5V (which seems to have no effect). Then read conversion results from all channels, by writing to the channel register followed by a CONVST. Please let me know any potential issues with either the setup or the algorithm that could be causing these issues.

  • Hi  

        Thanks for sharing these details. You mentioned that that you have driven the input with a DC 2V and you are having correct results. What do you mean when you say "slope of the output is inconsistent"? The way I understand is when changing voltage from 2V increasing by 1V, the result will have 1000 counts between the voltage change and sometimes 500 counts. By the way, how fast are you sampling? I think you have a correct sequence initializing the device, doing a reset after a power up. Is OK to send some snapshots of the digital signal on when you are writing/reading to the AD7616. This could give us a clue what is happening.

    Regards,

    Jonathan 

  • The sample rate is very slow, 1-2Hz at most. The SPI clock rate is also very slow, 10kHz. Here are the photos for writing the value 0x11 to register 3 and reading the contents of register 3.

    the above shows the MOSI or "controller" output "ADC" input. I read this value as 0b1000011000010001

    the above photo shows the "controller" output for a read command. The first 16 bits are the read command, the second 16 bits are all 0 (no output while holding cs low to wait for a response, the response is all 0's). I read the command as 0b0000011000000000.

  • Hi samb,

    I wrote a document some time ago helping debugging the use of AD7616 in standalone. The debug steps may help you as well. AD7616 Evaluation board in Standalone mode - Documents - Precision ADCs - EngineerZone (analog.com)

    If you can read data from the ADC, but cannot read/write registers, I´d suggest looking first at the HW_RNGSEL pins that they are effectively at 0 logic level. You need the part to enter software mode in order to access the memory map. 

    Regards,

    Lluis.

  • Hello Lluis,

    I have looking at your debugging guide and found all of the voltages to be as they should be. I have investigated the HW_RENSEL pins to make sure that they are low as well:

    The HW_RNGSEL0 pin is shown against RESET in this screen shot. This shows that the HW_RNGSEL pins are close to 0, and given the threshold of .8V it seems unlikely that this pin would be latched as a 1. I have also investigated the 5V and 3.3V supplies

    The 3.3V vs chip select:

    the 5V vs CONVST:

    note that the yellow lines representing voltage supply are magnified and using AC coupling. The DC offset of these is 3.3V and 5V respectively. Please let me know if any of these seem problematic in your experience. Thank you for your responses.

  • Hi,

    Are the HW_RNGSEL pins controlled by the microcontroller or tied to a given level? If tied, or have pull-down resistor, would you be able to short them to ground? Just to make sure they are robustly grounded. 

    Have you tried reseting the part after the HWSEL lines are tied to ground? Just to make sure the correct config is loaded to the device.

    Regards,

    Lluis.

  • Hi,

    the HW_RNGSEL pins are both tied to ground on our PCB. The traces to ground are a little long hence the noise on them but they are robustly grounded. The ADC is reset at the beginning of the code and multiple times during the code for testing purposes. All of the hardware config pins are tied to either high or low in the PCB, so it’s difficult to test if the ADC is somehow being setup in hardware mode. 
    thank you,

    sam

  • Hi sam,

    So far all you are reporting looks you are doing things right. Something we are missing. Can you send a zoom of the scope shot for a SPI read command so I can see it (just in case). 

    Are you using your custom software code or re-using the no-OS drivers provided at below link? Are you aware of the off-frame protocol described on the Figure 60 of the datasheet?

    AD7616 User Guide [Analog Devices Wiki]

    Regards,

    Lluis.

  • Hi Lluis,

    I have seen that figure. I have captured a read command for register 3:

    The yellow line is the clock and the purple line is MOSI. The command is 0b0000011000000000. The first bit is 0 to indicate a read. The next 6 bits are the register address, 3. This is follow by 9 data bits which are don't care in the case of the read command.

    I am aware of the protocol described in the data sheet for SPI, that being that the response to this read command will be on the ADC Serial output line the next time CS is low. I haven't shown a screen shot because it is very uninteresting: The value returned from a read command is always 0. This is regardless of which register is being read or whether or not that register has been written to previously. I am using custom code, but I have consulted the drivers which you mentioned to verify that they implement the same protocol for SPI and they appear to. 

    Here is a snippet of the code relevant to the SPI:

    SPI2.beginTransaction(SPISettings(100000, MSBFIRST, SPI_MODE3));

    This is using the Teensyduino library on the Teensy 3.6.