ADS1292R: Intermittently, experiencing an issue where all received data from the device is zero.

Hi Ryan,

Thank you for your response.

Initially, I had set the reset pulse width to 1 ms, which is shorter than the recommended 4 ms.
Later, in an attempt to resolve the issue, I increased the reset pulse width to 100 ms.

I also noticed that in several examples and open-source projects (such as GitHub repositories), many implementations apply a reset pulse longer than 4 ms.
Even if the longer reset pulse causes the device to enter power-down mode, my understanding is that it will still go through a reset and wake-up process, so it shouldn't cause any functional issues.

Therefore, I don't believe that the entry into power-down mode due to a longer reset pulse is the root cause of the problem.
If there’s anything I might have misunderstood, I’d appreciate your guidance.

Additionally, I’m currently using the internal clock, not an external one.
Since the main board is built with very small BGA packages, it’s extremely difficult to perform hardware-level measurements or probing.

Thank you again for your support.

Hi, Ryan

• As previously mentioned, I have already used a RESET pulse of 1 ms, which is shorter than the 4 ms threshold for entering power-down mode.
  Therefore, based on test results, I believe that unintended entry into power-down mode is not the root cause of the issue.

• Ryan Andrews said:

  However, we still recommend a reset pulse after power-up to ensure the internal OTP (one-time programmable) registers are loaded properly. If the device enters power-down mode, then it will read the OTP again during the next power-up (same as initial power-up sequence). For reliability, it is best to reset the device after supplies have fully ramped to ensure OTP is read properly.

  • However, I’m not fully clear on what specific issue this is intended to prevent, and how this recommendation serves as a countermeasure in principle and practice, considering that I am already issuing a proper RESET after power-up, and the pulse duration is well above the minimum required.
• Ryan Andrews said:

  Before sending the 10 dummy bytes, can you check the /DRDY pin and confirm it is toggling at the default data rate?
• What exactly is this check intended to confirm? 

  Unfortunately, due to hardware constraints on the mainboard, I am unable to measure the /DRDY pin directly with an oscilloscope or logic analyzer.
  However, I confirmed its behavior indirectly using debug messages:

  • After issuing a RESET pulse (100 ms), I inserted a 1000 ms delay for the test.

  • During this delay, /DRDY toggled every 2 ms, which matches the default data rate (500 SPS).

  • After completing my configuration, /DRDY toggled every 4 ms, which is exactly what I configured via the CONFIG1 register.

Thanks in advance.

Hi Ryan,

You're right — when the issue occurs, I can read back the register values before sending the SDATAC command, and all the settings appear to be correct.
This indicates that the RDATAC command was not properly accepted or executed, and the device remained in SDATAC mode.

What I find puzzling is that all other SPI commands, such as register writes, register reads, and measurement data reads, seem to work flawlessly —
yet only the RDATAC command intermittently fails to take effect.

Do you have any insights or suggestions as to why this particular command would be more prone to intermittent failure, despite the rest of the SPI interface working correctly?

Any guidance or direction would be greatly appreciated.

Hello Young,

Thanks for confirming. I'm not entirely sure why the RDATAC command would have intermittent failures.

• Can you capture a single SPI frame when sending RDATAC and confirm that the timings are meeting the specifications in section 6.6?
• Are you toggling /CS in between commands?
• Are you using the correct CPOL and CPHA settings?
• Do you notice any noise artifacts or overshoot/undershoot on DIN which might corrupt the communication?

Instead of reinitializing the device, a potential solution might be to resend the RDATAC command in separate, consecutive SPI frames. 

Regards,

Ryan

Hi Ryan,

In addition to following the timing requirements in section 6.6, I have also ensured that my software complies with the guidance in section 8.3.7 (Clock), which states:

“SCLK can be only twice the speed of fCLK during a register read or write… Having the 2.048 MHz option allows for register read and writes to be performed at SCLK speeds up to 4.096 MHz.”

For reference, I am using the internal clock (512 kHz) and have configured SCLK at 625 kbps, which satisfies the requirement that SCLK ≤ 2 × fCLK.
Hardware-based waveform measurements are unfortunately not feasible in my current setup, but I have carefully configured CPOL and CPHA as specified in the datasheet.

/CS is toggled appropriately for each command.

This setup works reliably in almost all cases, and I am able to read measurement data normally. The issue only arises very rarely, perhaps once every few dozen power cycles, as mentioned earlier.

Is there a way to configure the ADS1292R to continuously transmit a known fixed pattern via SPI, so that I can measure SPI communication error rate on the receiving side (i.e., the MCU)?

I'm looking for a method to validate the integrity of the SPI link by having the device send predictable data that can be checked for consistency.

Regards,

Young

Hi Ryan,

I found that when the issue occurs, I can recover normal operation simply by re-sending the RDATAC command.

At this point, I believe any further investigation falls within the scope of what I should handle on my own.

Thank you very much for your valuable support so far. I will consider this issue closed.

Regards,

Young