• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 45 subscribers
  • Views 788 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

ADS8684: ADS8684: impossible to properly read SDO line

JOEL GUITTET
Prodigy 70 points
Part Number: ADS8684
Other Parts Discussed in Thread: ADS8688, SN74HCS72

Hello all,

I experience some issues with ADS8684 (same device than ADS8688 but with only 4 analog inputs). The SDO lines is moving very quickly just after the falling edge of the SPI clock. It's so closed with the clock that my SPI master is not properly reading the data transmitted on SDO.

I have capture some screenshots with my Saleae logic analyser which is showing similar issues. Below I'm trying to read register 0x01 (AUTO_SEQ_EN) after power up of the device.

The logiciel analyzer displays the data on SDI and SDO lines:

- SDI = [0x02, 0x00, 0x00] => correct

- SDO = [0x00, 0x01, 0xFF] => not correct. Sometimes this is [0x00, 0x01, 0xFE], still not correct.

Here is a detail at the green mark at the end of the 3 bytes from ADS8684 device:

We see the SDO line is changing 41ns after the falling edge of the clock !! Sometimes this is so much closed that the logic analyzer is not making the difference and I'm able to see SDO changing at the same time.

Do you know why it's changing so much quickly after the falling edge? I was thinking the line should change at the rising edge of the clock to avoid issues, but it seems that's not what the ADS8684 is doing....

I you have used this device, have you experienced this kind of issues? How have you solved them ?

My configuration:

- SPI master is a Linux target with spi-gpio driver (this is not a true SPI peripheral, it's driving GPIOs, this explains the clock is not very accurate)

- SPI MODE 1 (CPOL = 0 and CPHA = 1, because it's required for this device).

- Logic analyzer sampling frequency at 24MHz.

Thanks,

Joel

  • +1
    TI__Mastermind 45745 points

    Hi Joel,

    The phenomenon you observed on the SDO is correct, the minimum time between the falling edge of SCLK and the data valid on the SDO is 10ns, please see the tHT_CKDO parameter in the timing diagram (figure 1) and the timing requirement table in the ADS8684 data sheet.

    Your controller should be able to retrieve the data during tHT_CKDO time frame. A hardware SPI peripheral on the controller should be used, not a software SPI interface. Also, your controller should be fast enough to retrieve the data.

    Best regards,

    Dale

  • 0 in reply to Dale Li
    Prodigy 70 points

    Thanks , this answer my question, I just double checked with the datasheet and you point the right information. 10ns minimum so the behavior is correct. This is something I have missed.

    I'm not able to use the SPI peripheral because I'm using RPI CM3 SPI1 which is not compatible with SPI MODE 1. I have imagine two solutions right now to solve the issue:

    - reading the MISO pin just before setting SCLK low, so I'm sure it has not changed yet (only requires a patch of the driver so it's pure software and easy to do - but disadvantage is that the driver is modified globally so this prevent using the driver for another bus or even for another SPI device on the same bus),

    - adding a hardware latch gate circuit at the output of the ADS8684 on SDO line triggered by falling edge of SCLK. This requires a modification of the circuit but will probably ensure avoiding unwanted SDO changes when reading MISO input on the controller just after falling edge of the clock.

    Will post my definitive solution here for other people interested by this.

    Joel

  • 0 in reply to JOEL GUITTET
    TI__Mastermind 45745 points

    Hi Joel,

    Look forward to seeing your experiment result, thanks.

    Regards,

    Dale

  • 0 in reply to Dale Li
    Prodigy 70 points

    Hello 

    At the moment I have tried patching the driver, this is as simple as moving 2 lines in one file (patch below) and after several testing, no issue to be reported. I think this is a viable solution.

    Something interesting is that this modifying a function only used by SPI modes 1 and 3, so it's still possible to use other SPI devices if they are using mode 0 or 2.

    --- a/drivers/spi/spi-bitbang-txrx.h	2021-04-02 19:12:08.253013080 +0200
+++ b/drivers/spi/spi-bitbang-txrx.h	2021-04-02 19:13:37.981013080 +0200
@@ -96,13 +96,13 @@
 		}
 		spidelay(nsecs); /* T(setup) */
 
-		setsck(spi, cpol);
-		spidelay(nsecs);
-
 		/* sample MSB (from slave) on trailing edge */
 		word <<= 1;
 		if ((flags & SPI_MASTER_NO_RX) == 0)
 			word |= getmiso(spi);
+
+		setsck(spi, cpol);
+		spidelay(nsecs);
 	}
 	return word;
 }

    I have not tried hardware solution but I think SN74HCS72 (https://www.ti.com/product/SN74HCS72-Q1 - D flip flop with negative edge triggered input) can be a solution.

    Joel