• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 46 subscribers
  • Views 185 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Original question:

ADS8328: Reading CFR and data.

ADS8328: Incorrent data timing on SDO

Montvydas Klumbys
Prodigy 10 points
Part Number: ADS8328

Hello,

I am experiencing the same issue as discussed on TI forum here. I am using Particle Xenon (nRF52840) running Arduino bootloader. I have the code running to write into CFR and read the data back, switching channel and then reading the data out. What the mentioned issue mentinos is that the data that is being read is shifted by 1 to the left e.g. when I try to read the CFR with SPI mode 1 (falling edge), I get response as 1111_1101_1111_1110 (0xFDFE), which is actually left shifted default value of CFR (0111_1110_1111_1111 = 1111_1101_1111_1110 >> 1). So then instead I used SPI mode 0 (rising edge) to read the CFR and it read back the default value 1111_1110_1111_1111 corrently. I then probed the SPI line with a digital signal analyser:

Note that the transfer is done byte-by-byte by keeping the CS low. What I observe is that the data on the MISO (SDO) is coming out WITH the falling edge of the clock (green dotted lines vs the red dotted line, which shows where the data should have changed instead). So if I read the data on the rising edge (SPI mode 0) instead of the falling (SPI mode 1), it reads the data correctly as 1111_1110_1111_1111. Now this all would make sense, except that:

1. The ADS8328 datahseet is claiming that this device is pushing data out on the rising edge and reading on the falling edge (SPI mode 1):

2. If I use SPI mode 0 for writing into CFR register, that fails, since when I read the data back, it comes reads back the default value. If I then use SPI mode 1 instead to write into CFR but read back from CFR in SPI mode 0, this works and I read the correct data e.g. I send 1110_0110_1111_1101 and read back 1110_0110_1111_1101 (while with SPI mode 1 this reads back as 1110_1101_1111_1010, so shifted to the left by 1, plus violating timing requirements, so sometimes data could be corrupted).

Taking all this in consideration it looks like the device pushes data out on the falling edge and reads the data on the falling edge too, which isn't really a standard as I need to write the data from the MCU using SPI mode 1, but read the data back using SPI mode 0. I would do that, but for some reason this doesn't work well when I try to change the channel from which the data is going to be sampled. If I used SPI mode 1 for both selecting the channel and then reading the data back, this works and only one channel is being sampled (although I am loosing a bit since the data is shifted to the left!). If however I use SPI mode 1 to select the channel but then read the data back with SPI mode 0, it continues to alternate the channel even though I am setting in CFR manual switching.

I am quite confused why does the device work the way it does and would like to hear some suggestions/guidance on how could I go around using it. If there is an alternative chip that works I wouldn't mind changing it, although I need 2 channels, single reference, single-ended ADC capable of 16-bit.

  • 0
    TI__Guru**** 174266 points

    Hi Montvydas,

    Welcome to our e2e forum!  Thank you for the LA capture as well!  I can't tell what your SCLK speed is from the screen shot you sent, but I suspect it's relatively slow.  The ADS8328 really wants to see a faster clock.  The SDI/SDO should both be valid on the falling SCLK.  Internally, the ADS8328 is driving the output SDO with some fixed delay so that when running the device with a slower SCLK speed, the data out looks like it should be read on the rising SCLK edge.  Can you speed up your SCLK and verify that the issue clears up with a faster clock? 

  • 0 in reply to Tom Hendrick
    Prodigy 10 points

    Hi Tom,

    The speed on the graph is 4 MHz, however I tried 8 MHz, 16 MHz, 32 MHz and 64 MHz with no luck. In fact, if I understand correctly, clock speed has nothing to do with it, since based on what you said ("ADS8328 is driving the output SDO with some fixed delay"), the data on the SDO changes after a delay of the falling edge of the clock and so one MUST be able to read it quickly enough before the data is changed, otherwise you will miss the MSB, is that correct? I checked when does the nRF52840 start sampling here and got that the minimum delay is 18 ns:

    So if I understand correctly, what happens is that the ADS8328 changes the data quicker than the MCU can read it, since everything happen on the falling edge. Does that mean I cannot use the nRF52840 MCU to read data from this ADC without missing the MSB?

  • 0 in reply to Montvydas Klumbys
    TI__Guru**** 174266 points

    Do you have LA plots using the faster SCLK?  If there are setup and hold time limitations with your processor, I'm not sure that I can help with that.  Does modifying the drive strength of the I/O cells help at all with that?  I'm not familiar with the specifics of the nRF52840.  

  • 0 in reply to Tom Hendrick
    Prodigy 10 points

    With a faster clock the LA plots look identical all the way, until where the sampling speed of the analyser isn't big enough to capture the clock anymore. Anyway, where in the datasheet does it specify that I need to use a faster clock? I checked the datasheet and it specifies the max clock as 33 MHz given my setup. But then I can see that it MUST work even with as low as 1 MHz if I use clock the clock as a conversion clock, meaning that in theory I can use even smaller SCLK than 1 MHz if I don't use external clock as a conversion clock:


    Regarding the setup and hold time limitations, I am sorry, but I wouldn't call these limitations. Normally SPI does not expect to read SDO INSTANTLY as the data is being pushed out with the same clock edge anyway, since otherwise a slight increase in the load capacitance (e.g. due to increased wiring length) would lead to exact same problem, where you would skip the MSB bit when reading the data or even worse, the data would be read inconsistntly. So what normally one does is reads the data on one clock edge, while the data is being pumped in on the other clock edge, which from the datasheet timing diagram would make sense:

    Although then it claims that the data is being pumped out on the falling edge with a delay of td(SCLKF-SDOVALID), which is max 16 ns, meaning the data should be read AFTER 16 ns and not BEFORE, since the before period is considered invalid:

    So does it make sense to assume that this device uses a non-standard SPI mode 1 protocol, where one must read the SDO pin BEFORE falling edge since if one reads AFTER falling edge, the MSB bit will be missed, because one shouldn't read the data during the invalid period, but then there is also a problem since if you read after the invalid period, but during valid period, you will miss the first bit.

    Just to let you know, I DID implement a workaround, where I read MSB bit before I start SPI data transfer and then combine this MSB << 15 (shift left by 15) with the rest of the data >> 1 (shift right by 1):
    data = data >> 1 | MSB << 15;

    However this only works, because my MCU hold time starts 18 ns after CLK falls, which is then already 2 ns into the the VALID period, which starts 16 ns after CLK falls. It thus makes sense that I won't experience any data issues, however that also means that if I change my MCU to one that samples the data earlier than 16 ns, I potentially would/could experience timing issues, probably not for the whole device line but some devices might.