ADS131M06: DRDY format and frequency

Hello Robert,

I'd be curious to see the logic analyzer shots that include DOUT. What does the result of a NULL command give back? When reading for the first time, are you clearing the FIFO by reading twice before the next data transition occurs?

Let me break down what I am seeing. The first screenshot shows that there's not enough SCLK periods to read out the whole frame before the CS pin goes high again. I assume you're doing a register write. The datasheet shows that the device expects to read all channels to complete the frame. 

Reading all data on a command ensures "predictable DRDY pin behavior" as shown below from the datasheet:

The rest of the screenshots only show me that, as you said, signal integrity isn't an issue as I don't see DOUT and any rest of the SPI frame. I agree that if you're able to write and read that value back, then you probably have the format of the command and the timing correct. However, because you are choosing to not read the whole frame you'll need to follow the "collecting data for the first time" where you'll need to clear the FIFO by reading data twice in row before the next data transition comes in.

In short, I suggest deciding to clear the FIFO and then look at DRDY behavior, or show some screenshots that you're doing that and we debug by taking a look at logic analyzer screenshots and the result of a NULL command.

Best,

-Cole

There should be enough sclk periods for the data. The screenshot simply doesn't have the resolution to show them. There's a total of 24 8 bit bytes. I have verified that they occur.

I can get data in, I know about the data buffering but at that frequency from *DRDY, it's simply not possible to keep up.I do perform a synch after setting the clock and mode registers so there shouldn't be any retained data. Indeed I should have 4 mS before the first *DRDY

I included the higher resolution writes to show I was performing. the write correctly.

The questions remain

1. why am I not getting a fixed width low pulse as the data sheet says I should?
2. why am I getting a 4kHz *DRDY instead of a 250Hz one? (I could understand getting two close to zero followed by a 4mS gap  if the buffer was filling. That's not what I'm seeing though).

The first question, in particular, bothers me since the data sheet indicates the pulse width should only be 4 clkin wide and that's just 1/2uS which is far from what I'm seeing.

Hey Robert,

Okay, sounds like you get the whole data frame and, to your point, a logic analyzer is better for displaying those sorts of things. I'm still unsure why CS releases between each byte. I'd still like to see them if you have them handy

For question 2, we'll need to figure this out first and the rest should be easier to debug. I don't have a good answer why the data-rate didn't slow down and follow the OSR setting. 4kSPS is the default so there's some relationship there we need to better understand. Let me talk with the team and see what they think.

For question 1, is it possible to switch back to logic low instead of negative pulse for DRDY_FMT as a short term debug step to see if DRDY is acting the same? Furthermore, we most likely have to wait until question 2 is fixed if we will run into the FIFO filling up and causing "unpredictable DRDY behavior".

Also, small note on the FIFO, if you miss two samples in a row, all data is cleared out. Its not really a true FIFO in that respect.

As always, here's some reference code if you have not seen it before: http://www.ti.com/lit/zip/sbac254 

Best,

-Cole

The CS isn't releasing between bytes, you are just seeing aliasing in that first picture because the time frame is compressed. I'll get several shots to show it but it gets rather repetitive after the first 6 bytes.

The default format for *DRDY behaves in the same fashion. I switched format since the *DRDY behaviour would be low while data was ready as I understand the datasheet and I wanted to switch to something that would be guaranteed to follow (at least somewhat) the conversion rate.

I'll also get a shot of the behaviour immediately after the sync. I do have three converters running, so I'll also concentrate on a single one.

Hey Robert,

No need to grab them if it'll be a pain and the data looks like it isn't copied and pasted (i.e. real channel data).

At this point, I think we need to reverify your main steps. I do think:

• Write and read configure registers
• SYNC to clear FIFO
• Send NULL or some command to read data

Is a good set of steps for your application. That being said, we need to verify each of these steps because the waveforms and the procedure seem to contradict each other.

Let's start with read and write, can you please read ID (reg: 0x0) and see what the response is on the oscilloscope (or logic analyzer)? This will test the read.

For the write, can you please read the STATUS register and ensure the RESET (bit[10]) is 0b1, write 0b0 to the RESET bit (bit[10]) of MODE, and finally read STATUS again to make sure the RESET bit flipped to 0b0?

For SYNC, I'd like to see CLK, SYNC, DRDY, and DOUT on an oscilloscope capture to ensure the timing falls within the SYNC but not the RESET criteria.

And for reading data, I'd like to see the CH0_CFG MUX changed to short the inputs together and then read the output. With the gain and VREF noted, we should be able to check out the offset and see if it falls within spec of the device. 

I know its kind of tedious but we're at the point where the behavior doesn't make sense but we need to verify our assumptions.

Best,

-Cole

Cole, sorry for the delay. I did get some measurements. Starting with the pulse width of the sync pulse, I then aimed to see what the timing was immediately after and it revealed something interesting. I specifically reduced to a single A/D to reduce the variables involved as well.

First the sync pulse

As you can see, it's a little over 1uS. On expanding the view I found the following

The first *DRDY pulse arrives 4 mS after the sync as expected and then every 4mS for 18 conversions before falling low for an extended period. After which it resumes at 4kHz.

It would appear that the IC is resetting. Any suggestions on source? I am going to check both the other ICs on this board and another board to see if the behaviour varies or is consistent.

Robert

Hey Robert,

That's an interesting find. The SYNC looks correct but it appears the behavior starts as soon as the SPI lines start to release. I'm interested if you could probe at the DVDD pin, and AVDD pin for that matter, just to ensure the supply rails are stable. The fact that the behavior lines up with the first SPI line transition is suspicious.

The only real way to get RESET on the ADC is through the pin, which doesn't seem to be the case; through a RESET command; or Power On Reset (POR). Out of the 3, the POR seems to most likely. There is also a SPI timeout and reset, which is for communication and not the device itself, but you'd need to wait 4ms for that so I find that unlikely as well.

Best,

-Cole

Edit: clarified SPI