ADS124S06: ADS124S06 communication issues

Short answer

CS# tied to DGND is a supported configuration — the datasheet explicitly permits it when the ADC is the only device on the bus, reducing the interface to SCLK, DIN, and DOUT/DRDY 1. The failure you see is almost certainly loss of byte framing: with CS# static, nothing re-aligns the internal bit counter between transactions. A single extra or missed SCLK edge (or any SCLK ringing/glitch) permanently shifts the device by one bit, and every subsequent read/write is garbage 2.

What to do

1. Enable the serial-interface timeout. Set TIMEOUT = 1 in the SYS register (09h). The SPI interface then self-resets if no valid 8 bits are received within 2^15 · t_CLK, which is the mechanism intended to recover framing in exactly this CS#-grounded use case 3.

Note the ordering problem: you must successfully write 09h once to arm this. Do it immediately after the power-up/reset sequence, before any chance of desync — use hardware RESET# or the RESET (06h) command, wait the required delay, then write SYS.

2. Verify the startup sequence with its delays. Wait ≥2.2 ms after supplies settle, use SPI mode 1, send RESET (06h), wait ≥4096 · t_CLK, then configure and read back registers to verify 4. Reading STATUS first is a good communication sanity check 2.

3. Hold DIN low during readback. When clocking out data with no command intended, DIN must be low 1. With CS# high this was harmless; with CS# low, any stray level on DIN is interpreted as a command opcode.

4. Scope SCLK at the ADC pin. It must be free of ringing and overshoot — unintended clock transitions are the primary desync source 1. Check that your MCU does not emit idle/partial clock edges when the SPI peripheral is enabled, disabled, or reconfigured. Sweeping baud rate won't fix a framing offset, which is consistent with what you observed.

5. Confirm SCLK count per transaction is an exact multiple of 8. Any partial byte left behind becomes a permanent offset.

On your schematic

Your CS# (pin 9) is tied to GND_ISO through R31 (47 Ω) and START/SYNC (pin 8) through R33 (47 Ω) to GND_ISO. START/SYNC held low is correct — use START/STOP commands for command-controlled conversions 2. RESET# is pulled high via R34, so you have no hardware reset control; if the interface does desync before TIMEOUT is armed, your only recovery path is the 06h command — which itself requires correct framing

You can try temporarily making RESET# MCU-drivable so you always have an unconditional recovery mechanism. This will help reset the interface if the communication gets messed up again, and allows you a consistent method to reset the interface. This will be a good troubleshooting step

1. ADS124S06 Datasheet (SBAS660C), p.62
2. E2E: ADS124S06 Serial Communication Issues
3. ADS124S06 Datasheet (SBAS660C), p.63
4. ADS124S06 Datasheet (SBAS660C), p.90

Hi Bryan Lizon86 

thank you so much for your detailed suggestions.

At the moment I've figured out that adding a pulldown resistor to SCK fixes that strange behaviour. My guess is that the floating SCK pin at startup has some noise between MCU PON and GPIOs configuration (some microseconds) but enough to cause some bit offset.

Anyway I still need to verify the stability of this solution, but using the ADS124 in free-running conversion mode, with the TIMEOUT bit set the conversion time should be enough to trigger  a serial interface reset.