ADS131M04EVM: DOUT not working and DRDY line consistently outputting never going down to 0V

Hello Tricia,

Thanks for posting on the forum! I agree with your set up for the SPI bus and power supplies.

You are partially correct though, nDRDY is supposed to start toggling as soon as Power On Reset (POR) is satisfied (i.e. the AVDD and DVDD rails are up). It won't remain high but it will mostly stay low and then toggle high when new data is ready. Before we start using SPI commands, we need to make sure the device started up correctly.

I have two theories about this. First, what is SYNC/RESET? From the PIC side it will be should be configured as an output and held high; if its held low the device will continually stay in reset and try to wakeup after many CLKIN cycles. The second theory might be related to your statement: 

Tricia Gottlob said:

I thought DRDY is to be high. On the PIC I make sure it is latched high

I'm confused what you mean by latched high. The pin on the PIC should be configured as an input so I'm not sure what "latched high" means. A nonzero voltage on nDRDY would imply that there might be bus contention. If nDRDY is an output on ADC side that's trying to drive low for the most part and the PIC is trying to hold it high then the voltage might be somewhere in-between.

Those are some of the basic possibilities. After that, we need to start probing AVDD and DVDD at the ADC pins to make sure they've powered up correctly.

Best,

-Cole

Cole,

So nDRDY pulsing is a good thing. So it looks like POR is satisfied. At the PIC this is an input. I have it as such. I removed setting the pin high on powerup.

The SYNC/RESET is an output of the PIC and is placed high on power up and remains high.

I have probed the ADC AVDD and DVDD pins on both sides of each resistor, R36 and R37, on the EVM and read 3.3V.

As for DOUT (output of ADC/Input to PIC), this is set at a level of around 500mV. I probed this on the scope with the SCLK and notice spikes at every rising edge of the clock. They are barely 20ns width spikes. Is this a ground issue? 

Hello Tricia,

In general, yes, nDRDY pulsing just after power up should be a good thing. To clarify, nDRDY will be mostly low but pulse high at the rate of the default data rate (I think 4kHz is the default if you have ~8MHz clock for CLKIN). If the pulsing matches that behavior then you should be good.

Hmm, 20ns pulse widths would as wide as a 25MHz SCLK which is the max frequency accepted by the device. I assume you're running much slower. There might be something there but its not obvious. The level of overshoot might be helpful too if you can measure that. Sometimes very high overshoot can link to a GNDing problem. Sometimes, its just the inductance of jumping wires between boards.

500mV barely meets the VIL and VOL specs but its clearly much too high for a typical system. But you've probed a "low" state for some for nDRDY, it is also 500mV for a low? Or is it just DOUT? If its just DOUT, there might be a settings issue you need to consider in the processor. You might have it as an input but there might be some other contention on the line. Kind of what I explained before. If it is both then "low" states are sitting at 500mV then, yes, it might be a grounding issue and I don't have a good recommendation besides shortening wires or jumping more wires between the EVM and the PIC board.

If you have scope screenshots feel free to send them my way. If we don't get anywhere with this avenue, I might need you to grab a logical analyzer and double check what you're sending is what you intend.

Best,

-Cole

Good day,

I now see a good DOUT pulse width. I am struggling on reading back all four channels readings. I send the NULL command but it seems the SCLK is only shown when I write a byte but not when reading a byte. Maybe it is the routine in the PIC that does not provide a clock signal. I am using a Microchip 8 bit PIC for the main processor.

I found a routine that will send multiple bytes (0's) reading after each byte sent to the ADC and notice DOUT to be outputting. But each byte value is one bit logic shift from the previous byte received. So for example, I am seeing 0x040810 , 0x204080, 0x020408. I am keeping the default width of 24 bit. I do not have any potential (v) on any of the ADC input channels.

I read about the SYNC line to pull it down to resynchronize the ADC conversions and reset FIFOs. By doing that the values are more expected and less sporadic.

As for the EVM, when using an external input voltage value in a single-ended input, I placed the jumper on pins5 & 6 for all. I tried to apply a 1.5V value on pin 1 of J1 (terminal block) and the results did not change. I would expect the counts to be higher than what I was previous seeing.

Hi Tricia,

Yes, I was going to recommend clearing the FIFO for consistent data. Reading twice, throwing the results out, and reading a third time is a bit easier if you don't want to deal with SYNC timing. I'd also encourage you to read the contents of the STATUS register as part of the NULL command. You only gave me 3 channels of data in the last post and I was expecting to see all 4 channels which would have resulted in an error and inconsistent data if they were not all clocked out.

Not having voltage on the inputs is the equivalent of floating and usually results in codes associated with GND'ing the inputs to show the offset voltage. Floating is inherently unpredictable and I recommend GND'ing the inputs and translating code to voltage and comparing that number to the offset voltage spec. If it falls within the range, then you probably have the correct value.

You applied 1.5V to pin1 of J1 which would be AIN0P and AIN0N is GND or 0V. And I assume you connected the negative part of the 1.5V supply to GND. Usually this would change the input pretty obviously. I would encourage you to translate the code to the voltage and see what the ADC is actually reading. Then, I'd recommend ensuring the FIFO is not full when you're collecting this data. 

Best,

-Cole

I have jumpers on the JPs for each channel on pins 5 & 6 which would ground the negative side (looking at the schematic of the EVM). I also placed jumpers on pins 1 & 2 also to ground the positive side, in order to see how consistent the return values (counts) were. (I gather all bytes 15 total, first three status, remaining ch1 to ch4). Sorry I do not have the status response to report.

Ch1 range 940 to 1017

Ch2 range 875 to 930

Ch3 range 1386 to 1447

Ch4 range 648 to 743

When reading a single register, I do not have to read multiple byte sets (24 bit default width), only 3 bytes correct? 

From what I read the only way to clear the FIFO is with pulling the SYNC signal down for a short time. Am I wrong? 

The NULL command will return STATUS for its response in the first byte set. But will still need to read all channels data to make sure the ADC is not out of sync. Is this a correct statement?

Hello Tricia,

Yes, that's how I would set up the input offset test as well. Ch3 looks a bit high but something tells me this would fall down within spec with some averaging to get rid of the noise. So, the device looks like it is operating correctly.

I was expecting you to do the last step of calculating the code to voltage and look at the spec. If you don't know how to do that, here's a blog: https://e2e.ti.com/blogs_/archives/b/precisionhub/posts/it-s-in-the-math-how-to-convert-adc-code-to-a-voltage-part-1 

Tricia Gottlob said:

When reading a single register, I do not have to read multiple byte sets (24 bit default width), only 3 bytes correct? 

You got it, those first 16 bits in the response will be the data, there will be no more actual data. That being said, 24 bits is still a constant word size determined by WLENGTH. You'll still need to clock out a 24 bit long word even though most of those last bits will be zero. Hope that answers it.

Tricia Gottlob said:

From what I read the only way to clear the FIFO is with pulling the SYNC signal down for a short time. Am I wrong? 

You're correct. Reading two packets of data is equivalent as well. There's some more text about how to do that in the datasheet.

Tricia Gottlob said:

The NULL command will return STATUS for its response in the first byte set. But will still need to read all channels data to make sure the ADC is not out of sync. Is this a correct statement?

That's correct. The only exception is if you want to skip CRC. There's a short SPI frame section in the datasheet with more info.

Other comments:

It's clear that you're a newer engineer. If you have not already, I highly recommend reviewing the compiled FAQ: https://e2e.ti.com/support/data-converters-group/data-converters/f/data-converters-forum/1060610/faq-have-a-question-about-adcs-click-here-for-faqs-resources-and-more 

And if you have not seen our training series on ADCs, I highly suggest you check out our video series: [Video Series] TI Precision Labs – ADCs

I do want to reassure you that your questions have mostly been very specific questions about the device, which is perfect. If you have not checked out some of these resources, it will accelerate your learning.

Best,

-Cole

Cole,

Thank you for confirming. One additional question about the EVM, I have currently jumpers to ground both pos and neg inputs for each channel. I would like to provide a voltage and have tried to apply a constant voltage on one channel but I do not see the counts jump. Is there a special configuration for the channel on the EVM. When I applied the voltage I removed the jumper to the positive side.

Otherwise I have been getting consistent responses from the ADC EVM to my PIC.