MAX14662 daisy-chain SPI: intermittent millisecond-delayed turn-off on one channel

Hello,

We are using two MAX14662 devices in SPI daisy-chain mode to multiplex external sensor power channels. See below schematics. We shift a 16-bit word every 10 ms so that only one switch channel should be closed at a time. Nothing is currently connected at the outputs.

We observe an intermittent issue on the second MAX14662, channel B7. When turning ON U23.B1 and turning OFF U24.B7, U23.B1 updates immediately at the CS rising edge, but U24.B7 sometimes remains on for approximately 2 ms before turning off. This creates a temporary overlap where both channels are on.

Below capture shows U24.B7 first turning OFF at the same time as U23.B1 is being turned ON. Next cycle it turns OFF approximately 2 ms too late.

Channel 1-4 is SPI communication

Channel 0 = U23.B1

Channel 7 = U24.B7

Things we have verified:

• CS is active low and deasserts well before B7 turns off.
• CS, SCLK, and data look the same at both MAX14662 devices.
• SPI clock is 6.25 MHz, with approximately 160 ns period, so it should satisfy the datasheet timing.
• The 16-bit SPI frame appears correct and the first device reacts immediately.
• We added a 10 kOhm pull-down from the B7 output to GND. B7 still remains flat at ~3.3 V until the delayed turn-off, so this does not appear to be a floating-node discharge artifact.
• The issue is intermittent; sometimes B7 turns off immediately as expected.
• There is no additional SPI communication at the time B7 finally turns off.

According to the datasheet, switches should update on the rising edge of CS, and tOFF is specified in the microsecond range. We would therefore not expect a millisecond-scale delayed turn-off after a valid SPI frame.

Questions:

1. Are there any known conditions where a MAX14662 channel can remain closed for milliseconds after the SPI register update?
2. Could marginal supply, SPI/I2C mode-select, SD, DOUT/DIN timing, or analog pin conditions cause one device in a daisy chain to update late or incompletely?
3. Are there recommended diagnostics to distinguish a device/control-latch issue from board-level soldering or signal-integrity problems?
4. Is there any errata or application guidance for daisy-chained MAX14662 devices where one downstream device intermittently fails to update on the same CS rising edge?

Best regards

/F