• Resolved

ADS8698: ADS8698

Prodigy 40 points

Replies: 5

Views: 59

Part Number: ADS8698

My ADS8694 is not responding on SPI, similiar to this question:

The platform is Raspberry PI 4, and on this platform, the SPI writes are per byte, and the clock stretches in between the bytes, as shown in the linked topic.  I have spent a lot of time searching for a SPI fix on the Raspberry Pi, but there seems to be none.

My question is, is there such a timing requirement on SCLK that there cannot be a clock pulse stretched? 

Unfortunately that detail information is not in the datasheet, so it would require someone to look at the design HDL code to see if such a constraint exists, or perhaps setup an eval board with a Raspberry Pi to at least confirm the issue exists - I could send some code over to help with that.  Or perhaps this is already known...?

Its possible that something else is wrong in my setup.  I have tried different SPI bus speeds to no avail.  I have tried every combination of clock polarity and phase.  The ADS8698 simply does not respond - exactly as shown in the related topic.  I notice that on power up, the reference voltage (REFSEL is GND) is not present, but I read that the ADC is in power down until a SPI transaction wakes it up.  I have been sending it 0xA000.  There is no echo back of any SPI command that I write.

  • I think the spec for SCLK is in the datasheet, clock high/low time is limited to 0.6 of Tsclk...

  • In reply to Martin Guthrie:

    Hi Martin,

    I apologized for late response. I did not try sending data/CLK per byte on the EVM board before, it is not easy because we have to modify the EVM GUI. However, sending data/CLK without a dead time worked well as I know. The dead time may lead to a longer low time of one SCLK to violate the datasheet as you have seen.

    Thanks.

    Regards,

    Dale

  • In reply to Dale Li:

    Dale,  Thank you for the response.  I was able to fix SCLK.  I am testing at a SPI bus speed of 1MHz.  The device still does not respond to my commands - at all - there is no echo, and the reference REFIO output is low, not the expected 4.096V.

    I am confused related to the device being in powered down mode described in section 8.4.1.1.6.  I think the device is stuck in power down mode, even when it powers up (could be a race condition between the power rail(s) and RSTn).  I am unable to toggle the reset faster than 100ns on the Raspberry Pi 4.  The first paragraph below the table says when the device is in powered down, input is ignored - which matches what I see.  The last paragraph says when RSTn is pulled high, the chip is set to its "default" state and not in power down.  The first paragraph says power down mode is entered when the reset pulse is >400ns.  

    Q1: Does the part come out of power down mode when RSTn pin is logic level high, regardless of how long RSTn was low previously?

    Q2: Is it true that I need to provide a RSTn pulse of <100ns to bring the part into normal mode and out of power down?

    Martin

  • In reply to Martin Guthrie:

    David,

    I found my problem... I have fixed this on the board and now I see the chip echoing back commands and REFIO is now the expected 4.096V... I haven't yet made any conversions, but probably everything will be okay now...

    Its odd that the AVDD affected the digital part of the chip.

  • In reply to Martin Guthrie:

    Hi Martin,

    Thanks for update.

    Best regards,

    Dale