ADS1292 SPI data errors

Hi David,

Thanks for your question and the details on your initialization. Were you trying to attach an image? It did not go through.

Begin we dive in, I want to make sure that I understand your ADS1292 configuration and test routine first.

• I'm not very familiar with the F5528, but the DCO/4 (4.096MHz) should be fine to use for the ADS1292 SCLK.
• You are using a delay of 4*t_MOD? I believe you are referring to the command decode time, t_SDECODE, which is in terms of "CLK" periods (4*t_CLK). I'm not sure which master clock frequency you are using (512kHz or 2.048MHz), but the 8ms or 10ms delays you are using would still be more than enough to meet this requirement. Other critical timing specs are also in terms of t_CLK, so please double-check all your timings.
• Every 5,000 samples received, you power down the ADS1292 and you repeat the delays and initialization? In some instances, the ADS1292 provides correct data, but not always?

I can see that even the 24-bit STATUS is not coming correctly - the last 13 bits should always be '0'.  Does the Device ID read back correctly?

When the error data occurs, have you tried pulsing the /RESET pin (or sending the RESET op code)? Ensure that you keep the minimum pulse width in mind. After RESET, it takes 18*t_CLK for the registers to assume their default states and for the modulator to begin converting. The same delay must be observed when you write to CONFIG1, RESP1, and RESP2.

How repeatable is this issue? For example, is it always correct the first time, but erroneous after that?

Please confirm your clock frequencies and timing delays for me once more and reattach any images you were trying to share.

Best Regards,

Andrew

We are observing the delays required, I have checked all these many times. Upon further investigation it appears that it is the process following the samples that somehow leaves the ADS1292 internal data state machine in a mess. We stop the 2.048MHz (SMCLK) to the device following the last sample to save power, at the same time as placing the START line low and disabling the /DRDY interrupts.

During testing, I implemented a delay of 1 second prior to putting the device to power down, and observed that the SPI data out line sometimes hangs high for around 668ms. I found that trying to put the device to power down by holding reset low with the clock applied during this 668ms period causes the problem, and any subsequent data sets are corrupted. Adding a delay of say 700ms before I put the ADS1292 into power down results in no data corruption. Having found this out there is no need to add any logic analyser traces. Testing of values of SPI_RXD registers in debug and using a breakpoint confirms the above, as the delay is altered below around 668ms the problem returns.

We don't want to wait this long to put the ADS1292 into power down. Perhaps you can advise a sequence that will not cause a data problem. Does the 2.048MHz clock need to continue for while after STOP is taken low? Do we need to read the a data set if /DRDY is low after stopping it?

Each time the device is run up again the ADS1292 registers are writing and reading OK.

We are using the hardware pins alternative rather than SPI commands to drive the ADS1292, with the exception of the RDATAC and SDATAC commands, and have our own specific set register settings we load into the ADS1292 before we run it.

Best Regards

Hi David,

I believe the data corruption is coming from stopping SCLKs immediately after pulling START low. There are two delays listed on page 32 that are required when stopping the modulator conversions: t_SDSU and t_DSHD. These delays are needed for the converter to stop converting and for the current conversion to complete. Each timing spec is equal to 8*t_MOD. For a 512kHz CLK and a 128kHz mod clock, each delay works out to 62.5 us for a total of 125 us. 

Can you try inserting this delay after pulling START low before stopping SCLK?

Best Regards,

Ryan

Thanks for the advice on this looks like we were removing the clock too soon, now have a 250µs delay before we do anything after taking START line low and disabling the /DRDY interrupt on the micro.

Data corruption still there on third time we run the ECG chip from a micro reset or re flash.

Regards David

Hi David,

I just wanted to check in on your progress with this issue. With a 250us delay, during which you continue sending clocks (CLK and SCLK), I am surprised to learn that the data is still corrupted. Sending clocks should clear the output shift register completely. If the power-on reset sequence is followed correctly, the STATUS byte should precede the channel data once again as expected.

The power supplies are still valid during the device /PWDN period, correct? Once the device is brought out of power-down, it should only take 18 t_CLK cycles to initialize the default configuration registers and start conversions again.

Please let me know if you have any further questions or new findings to update on.

Best Regards,

Hi Ryan

I can confirm the power supplies and clock are valid during the power down period, while we wait 250µs for the data registers to flush. The ADC clock is retained but we do not send any SCLK pulses. Sending SCLK pulses would require us to do dummy reads during this 250µs period. If this is a requirement as well as supplying the ADC clock we will have to test again. Can you advise how many times we need to read the SPI registers, or should we just do this each time /DRDY is asserted via the normal interrupt mechanism?

Regards David