We are attempting to use the RDATA command from a ColdFire V1 to a single ADS131E06 without monitoring the DRDY signal; monitoring this signal would add considerable complexity into the system and we are willing to accept there will be timing jitter in the results. The ADS131 is using the internal oscillator (2.048 MHz) and an external reference. The chip is configured at power up (RESET, SDATAC, CONFIG1 = D2h, D4h, or D6h, START, all timing constraints duly observed).
We issue the RDATA command at about 1 msec intervals. However, we occasionally see corrupted data values returned by the RDATA command. Most of the time, the value of all channels are corrupted, but occasionally, it seems that only the data in some channels is corrupted (on these rare cases, no observed pattern of which channels). The corruption can take almost any form; there is no discernible pattern to the erroneous data. For example, it is not just a matter of bits being shifted one way or the other. The four most significant bits of the status register are always correct (the rest of the status register is currently ignored). Changing the output data rate (in CONFIG1, register 1, bits 0-2) changes the frequency of the observed errors. When the rate is set to 1 ksps, we see an average error rate of about 1 in every 128000 queries. At 4 ksps, the rate averages about 1 in every 26000 queries. At 16 ksps, the rate averages about 1 in every 7000 queries. These values are averaged over many minutes with millions of queries (again, the queries are at a 1 kHz rate); there is no observable pattern to when the errors occur.
While this chip shares a SPI bus with other chips, all other chips have been disabled during this testing. SPI bus speeds between 1 MHz and 13 MHz have been tested with no apparent influence on the frequency of the corrupted data. Delays have been added to ensure that tCSSC and tSCCS are many times longer than the minimums in the data sheet (delays of about 10 usec were tested); the additional delays seemed to have no effect on the rate of erroneous data being returned (it is believed that the original timing already met the minimum delays). Some tests have read registers 00h through 00Ch immediately before issuing the RDATA command; the returned register values are always the expected values, even when the immediately ensuing RDATA command yields corrupted data.
The same error rate has been observed when the normal input is selected in the MUX of each channel (CHnSET register bits 0-2) as well as when the MUX is set to use the shorted inputs (value = 001). Most tests have been performed with the MUX selecting the shorted input. As we are in very early testing, we are in a benign electrical environment; there have been no noise issues with the rest of the system (including other chips on the same SPI bus).
With the SPI parameters making no apparent difference in the reported error rate, along with the reported register values always being the expected values (and almost all of the data values seeming to be correct), I do not believe that there is an issue the with SPI bus or configuration.
The correlation between the output data rate of the ADS131 and the error rate lead me to believe that there is some other timing-related issue with when the RDATA command is issued. According to section 9.5.3.10 of the data sheet (p. 37), there are no restrictions on when the RDATA command can be issued (unlike using the RDATAC command, which must avoid an area near DRDY falling). In fact, the following quote is from that section:
RDATA is best suited for systems where register settings must be read or the user does not have precise control over timing. Reading data using the RDATA command is recommended to avoid data corruption when the DRDY signal is not monitored.
However, the same section recommends that DRDY go low before issuing the RDATA command, making me wonder if there is a keep out zone, similar to the RDATAC command, where issuing the RDATA command may return corrupted data. Looking at the observed error rates, it would seem to be about 16 * tCLK cycles.
Can you tell me if there is a keep out zone for the RDATA command, or give me other ideas about what may be going wrong?
Thank you very much for your assistance.
