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.

ADS127L01: SPI Register access not working

Part Number: ADS127L01
On our board we are using the device in SPI mode. Currently with a fixed MCLK speed of 3.2MHz, and SCLK of 20MHz. The issue we experience is when we try to access the internal ADC registers. Reading and writing the registers doesn't seem to work (RREG/WREG). Reading the ID by sending 0x20,0x00,0x00 returns only zeroes, not the value 0x00,0x00,0xX3 as described in the datasheet. Question: after device reset, should this reading just work or are there any undocumented dependencies? (e.g. that START must be asserted? or that first the CONFIG register must be written, ...) Is the SPI Timeout really deactivated by default? (we have long idle periods between the bytes on the spi bus) When the START pin is asserted, normal ADC Data can be read out without any problem (by just generating 32 SCLK after DRDY# becomes active) and the 4bit CRC is always correct (CS# remains asserted all the time). This suggests that we have no problem with unclean clocks edges. After deasserting START and CS#, and attempting new SPI reads, we seem to get back some stale ADC data followed by zeroes. In general it looks like the device is only returning ADC data and never internal register data. Also remarkable: sending the START and STOP command through SPI seems to work fine (DRDY activity could be started and stopped with this). So it looks like we use the correct bit order when sending command bytes. Repeatedly executing the RDATA command, seems to return changing ADC values, although START=0 (this might be normal?) Using slower SCLK speeds does not solve the issue. I did not investigate the signal integrity of the signals yet since the lines are difficult to measure on our prototypes.
  • In the meanwhile I found the problem: I was violating the td(DECODE) specification. This seems to be the minimum time between the SPI Bytes and depends on the MCLK. With my rather slow MCLK, the SPI interfacing should be slow as well...