This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

ADS8674: Error reading registers

Part Number: ADS8674
Other Parts Discussed in Thread: ADS8678

The SPI signals for an ADS8674/ADS8678 device are connected to GPIO lines on a processor and controlled through software to implement the SPI protocol for the device.  After power on, the first command to the device is to read the AUTO_SEQ_EN register (0x01), which should return a value of 0x0F (ADS8674) or 0xFF (ADS8678).  However, the value received is 0x0E or 0xFE, depending on the device.  Multiple devices have been used with the same results. 

The timing for the operation is shown in the scope trace, and it seems to match the requirements in the data sheet.  Please note the clock frequency is quite slow in order to maintain the duty cycle specification for the device, but there is no minimum specification for the clock frequency.

Also, reading and writing other registers does not seem to operate correctly.  Are there any actual timing traces available from the evaluation module that can be used as reference to try to find the problem? 

Thanks

  • Hello Fred,

    I believe you are writting to the device. SDI bit 8 should be low to read and high to write

    So you are currently writting 0x00 to register address 0x00. 

    I would suggest looking at page 50 and onward of the datasheet

    Hopefully that helps

    Cynthia

  • Hi Cynthia,

    Thanks for the response. However, it looks like the SDI line is low on the eighth falling edge of SCLK, which would be a read of register 0x01.  Also, if the register were being written, I would expect the written data to be repeated on the SDO line during clock cycles 17-24 as described in the data sheet. 

    Thanks,

    Fred

  • Hello Fred,
    Seeing how you are not able to read or write to registers, I am guessing you're communicating to the device incorrectly. Usually writting and reading to the device is the first step to ensure you're communicating as desired.
    I am working on getting the hardware, but this will take some time. Meanwhile would you be able to share other shoots that show other efforts to coomunicate to the device. Also it would be good to reset the device inbetween each try to be sure there is no residue errors.
    Regards
    Cynthia
  • Hi Fred,

    I'm not able to get the device to communicate either. All I get is 0's no matter the spi mode. However in your case of the picture provided you send out 32 clks (4 bytes). The protocol for "Program Register Read/Write Operation" is 24 clks (3 bytes). The first byte is the address plus the read/write bit the following byte should be either, don't cares for a read operation, or the byte to be written for a write operation. The last byte is for reading the current setting irregardless.

    If you get this to work I would love some source code for initializing the chip. I can't seem to get my device to function at all, and I have tried all 4 spi modes with various commands, performing a reset etc.
  • We purchased an evaluation board for the ADS8678 and verified that the timing for read/writes to the device matched what we were doing, but at a much higher speed.  In fact, the SCLK rate seems to be about 25MHz on the eval board, which is greater than the specified 17MHz.  This also results in a conversion time of 640 ns, which is  below the 850 ns spec.

    The documentation for the eval board mentions using 49.9 ohm series termination resistors for the SPI signals.  Adding these to our hardware corrected the problem without changing any of the signal timing.  We have occasionally had to use termination resistors for SPI interfaces before, but I can't remember ever using a value that large.  Everything seems to be working as expected at this point.

    The scope trace shows a read of register 0x01 with a value of 0x81 from the eval board.

  • FYI I fixed my problem.  I had an unrelated issue with the host micro-controller.  The pin being used to control the RST/PD signal was being erroneously consumed by another peripheral which took control of the pin's direction register.  Once I found and corrected this issue the ADC behaved as expected.

  • Glad that the issues are resolved!