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.

Parents
  • 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.

Reply
  • 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.

Children
  • 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.

  • Hi Lluis,

    Our team has recently purchased an AD7616 evaluation board to try to isolate the problem that we are having. Currently we have discovered that the device requires operation in SPI mode 2 for proper operation, which is odd given that the no_os drivers use SPI mode 3. The improvement that came from switching SPI modes is consistent conversion results readings and register readings which line up with the default values provided in the debugging guide you previously linked. The problem that we are still experiencing is that we cannot write to registers. The oscilloscope view of our write command is previously linked in this thread. If there are any potential problems with the way that we are trying to change registers or other ideas you may have for troubleshooting please let me know. thank you

  • Hi Sam,

    Apologies for the late response, I was out of office. Glad to see you fixed the read operation by changing the SPI mode. It there is a problem with the driver I should report it to the Microcontroller no-OS Drivers team for review.

    If the issue still persists on writing registers, I would try the different SPI modes just to make sure. Otherwise, I would still be suspicious of the device not entering Software mode (although we have already discussed and apparently your digital input levels look good). Have you tried writing register on the AD7616 evaluation board and was that successful?

    Thanks,

    Lluis.

  • Yes we tried writing to the registers in the sample which I previously posted. We try to write all the voltage range registers to 0xAAAA for a +- 5V range, but as you can see the values all remain as the default values. We have also written other registers which also has no effect. As we are now using the eval board and have followed the jumper configuration to put it in software mode. In regards to whether or not there is a bug in the drivers, I can't really say given that we aren't using the drivers. However, the spi mode that works for arduino is 2 and the one which is provided there is 3. We have thoroughly gone through the debugging guide you have provided and all the voltages on the eval board look exactly correct.

  • Hi sam,

    Why 0xAAAA? It should be addressing+AA, being addressing either add 4,5,6 or 7?

    Regards,

    Lluis.

  • Apologies that was a miscommunication on my part, we are writing 0xAA to the registers 4, 5, 6, 7.

  • Understood. Had to ask just in case.

    Now, you can read the memory map default values so you are succesfully in Software mode, however you cannot write. That only leaves me to ask about timings on the write operation or wrong addressing (that seems correct). Have you checked different SPI modes for writing (for the sake of testing) .

    Can you compare side-by-side the scope shot of the eval board write frame to your software write frame, just to make sure. Checking timings and edges.

    Regards,

    Lluis.