ADS1298R SPI Odd Behavior

Have you tried to issue a SDATAC command before you try and read the register?  You need to issue this at power up (or potentially before reading) to cancel RDATAC mode (default at power-up).  See Figure 77 for the power up flow in the datasheet.

Greg,

We issue an SDATAC and a STOP prior to trying to read the register. We have also tried to do a RESET and then a SDATAC and then a STOP prior to reading the register with no success. We can successfully write registers after the SDATAC and STOP but we get the above behavior when reading.

Thanks,

Craig

What is the status of your START pin?  From the status of DRDY, it looks like the device is still converting (DRDY goes high).  Generally, the START pin is held low (unless you are converting), so it could be that you are still telling the ADC to convert and trying to read data out at the same time.

Greg,

We have tried it with START high and START low and the behavior is the same. We also captured the logic used on the ADS1298ECGFE-PDK and saw that it issued two SDATACs and that doesn't work either.

-Craig

Craig -

Can you capture the process with START low?  The reason is that according to your first capture above, the device is still converting data (DRDY is pulsing still; the capture shows DRDY going HIGH when clocks are provided, ie you are reading back data from the ADC).  Read and Writes should not be occurring during this time since it could get confused with data.

What is the sequence (from beginning) of commands/writes/reads that you are doing to get to this point (screen capture) in you system?

For the device, an initial SDATAC at power-up since the device starts in RDATAC mode.  (see Figure 77 of datasheet for startup and writing/register register sequence).

Greg,

I recaptured with the START signal low and had the same result:

(Note that CS1 and CS2 are swapped relative to the previous screenshot)

I did notice that DRDY went high at the start of the SDATAC and then about 0.3ms later, it went low and stayed low until the start of the RREG. It is hard to illustrate with screenshots but I can provide the logic capture file if you can install Saleae Logic (http://www.saleae.com/downloads) and are willing to look at it.

Thanks,

-Craig

Hi Craig,

Just curious, but what is the second /CS line going to?  Are you sharing the SPI bus with another device?

Craig -

I know you said the CS signals shown are being decoded to the actual CS to the part.  Can you look at the CS to the ADS1298?  Is it possible that in your code for RREG command the CS isn't getting decoded properly, whereas the read data and write data is?

If you want to send the logic capture file, we'll be happy to take a look at it.

Tom,

Yes, the bus is shared between multiple devices and CS1 and CS2 go through an SN74LVC1G139 decoder and one output line from there goes the ADS1298.

I'm attempting to make a capture on the output side of the decoder and I will post it if I can keep my hands still long enough.

Thanks,

-Craig

Greg & Tom,

Here is the same transaction with CS being directly sampled from the output of the decoder. Ignore the NA line that is still attached to one of the decoder inputs.

Thanks,

-Craig

Here is the logic capture for the latest screenshot.

Thanks,

-Craig

4377.Failed RREG - CS direct.zip

Craig -

After you do the write register command and send all register data, there appears to be extra data on the MOSI line, can we assume since the CS is high that you are communicating with another part at this time?

Something to test, can you put an SDATAC before the RREG command?  You should be out of data acquisition mode, but it appears you may still have one data left based on the timing of when the 2 SDATAC commands are issued at the beginning of the sequence.

Craig -

One additional item...make sure that between the 2nd and 3rd group of 8 SCLKs that you have met decode time (ie after 2 8bits wait >2us before actual data readback occurs).

Greg,

You are right in that the extra SPI activity after the write sequence are communications to other chips on the same bus.

I'm going to try adding a delay between bytes 2 and 3 and see if that helps. The issue seems to be timing because in testing today, I was able to get it to work by slowing the entire thing down to a 400kHz clock. The extra time in that spot at the lower speed might be the difference. I'll follow up after I have a chance to adjust the code and test it.

Thanks,

-Craig

Greg,

I've done some further testing and I found that while it works at 400kHz, it breaks when I double the clock to 800kHz. At 800kHz, the timing between bytes is long enough to satisfy the decode timing requirements so there is something else going on here.

I put a scope to the SPI lines on Friday and they looked good to me (the MOSI line settles before the SCLK line falls). Unfortunately, I have jury duty this week and cannot capture a scope screenshot for you right now.

The next step I can think of would be to put buffers before the chip to drive cleaner signals but that would involve another run of boards. That is more time and money than I can afford on a hunch so I would like to exhaust as many other avenues as I can before taking that step. So, can you think of anything else I should check or try right now?

Thanks,

-Craig

Greg,

The jury pool was let out early today so I was able to get in to the office and capture some screenshots for you.

The first capture of seach set is of the first high bit in the SDATAC transaction and the second capture is a view of the entire SDATAC command. Yellow is the SCLK, blue is MOSI (DIN on ADC), and purple is /CS.

400kHz SPI clock, communication works:

800kHz SPI, does not work:

3.3MHz SPI (goal speed), does not work:

It looks to me like this should work since the data pulse is always stable when the clock falls. And, if it were a timing issue with the decode time, then it should still work at 800kHz but does not.

Any thoughts?

Thanks,

-Craig

Craig -

From the looks of your log that you sent, it appears that the SDATAC is probably working.  It is probably just that the converter finishes up the current conversion in the process to explain the last DRDY pulse.

For the RREG command, can you put a delay between the second byte of the RREG command and the data readback?  While it looks like you are meeting the decode time (8th clock to 8th clock), the readback may need time to set the data in the output register.

Greg,

I added a delay before each byte and after the chip selects to make sure that timing was always met and it did not solve the issue. The screenshot below is the spread out RREG statement at 800kHz. This screenshot has START high but I have also tried it low with no success.

Any other ideas?

Thanks,

-Crag

Craig -

So a couple questions:

1.  Are you using an FPGA or micro for the SPI communication?

2. Can you verify that the CS to first clock timing requirement is correct?  I know you said the CS are not representative of the actual CS to the device.

3. At what point are you measuring the signals in your setup?  For example, are you measuring close to the ADC or close to the FPGA/micro?  Based on your oscilloscope captures (not logic analyzer), there is a possibility that the signals are shifting and not registering correctly with the part.  Typical SPI communication has the data stable for the valid edge and transitioning on the other.  In your scope shot it encloses the entire clock signal, which isn't necessarily wrong, it just may lead to data interpreted incorrectly if there is any shift between the clock and data lines (ie where you measure or long connection between micro/FPGA and device).

Greg,

1. I am using a micro -- Parallax Propeller

2. I have verified that the actual CS follows the sampled CS line by a handful of nanoseconds. It is difficult to capture directly but I have validated that the decoder works and has a propagation time much smaller than the time values we are dealing with here (5ns).

3. I am sampling at testpoints about midway down the traces. The bus is serially connected to four devices and the ADS1298 is the second device in the chain. We don't have issues communicating with the last device in the chain but it could have different latch timing than the ADS1298. I have scoped the SPI lines at that far chip and the SPI waveforms look good from there.

I see where you are coming from here and it is something I have considered but I have avoided making DIN toggle with a falling SCLK because of the necessary assembly code changes. I will work on this and hopefully have something to test soon.

Thanks,

-Craig 

Greg,

Rather than restructuring the SPI interface to line up the transitions, I realized there was an easier experiment to do. Instead, I increased the processor clock speed and added delays at each SPI clock transition. This effectively reduced the transition skew in the SPI by a factor of 8. See the image below. Yellow is SCLK, Blue is DIN, and Pink is DOUT.

I then tried making the DIN transition follow the SCLK transition:

In both cases, it worked with SCLK at 400kHz but didn't work at 800kHz.

So, I am fairly sure that making DIN transition with SCLK will not solve this problem.

-Craig

Craig -

We are still trying to determine what might be your issue.  Question...have you tried either disconnecting other SPI devices or disabling communication to the other SPI devices?  Just trying to eliminate possibility of any extra communication that you aren't expecting.

Craig -

I'm glad we could get things resolved.  If you have any further questions, please let us know - we are here to help however we can!