ADS131M02: ADC always reads 0x8000 no matter what the input analog signal is

Hi Dheeraj,

welcome to our e2e forum and thanks a lot for choosing a TI ADC.

From the scope shots you showed and your explanations, you don't seem to do anything wrong at first sight.
Can you try the following things:

• Set MUX0[1:0] = 01b.
  In this case you should definitely see the conversion data change.
• Send the STANDBY command first before making any register bit changes.
  Change the register bit settings.
  Send the WAKEUP command to start conversions with the new register settings.
• Have you verified your WREG command is working by reading back the register settings using the RREG command?
  As you seem to be able to change the word length, I suppose the WREG command is okay.

Regards,
Joachim Wuerker

Joachim Wuerker

Thanks for helping me with this.

Here's me trying to set the MUX[1:0] to 01b.

Verified my write to make sure it is 0x01. See the response frame on the right.

Here's what I read on the ADC. Again the same result of 0x8000. 

Here's me sending the Standby and Wakeup commands before writing the Ch0 config register. But I did this for every register write as well:

Verified that the channel config register is set correctly:

Even with this the result of the ADC is 0x8000. Same scopeshot as before.

Yes, I have verified the register settings after each write. 

Thanks in advance.

Regards,
Dheeraj

Hi Dheeraj,

thanks a lot for your additional measurements.
Is it possible that you send the RESET command instead of the STANDBY command? Or did I misread this?

In any case, maybe we should start from the very beginning to see where things might go wrong.
Could you reset or power-cycle the device, and then just send a 3x24x4bit = 288bit frame with DIN held low? We should see data on Ch0 and Ch1 then which is different from 0x800000 or 0x000000. Send multiple frames with DIN held low to see if the data keeps changing.

Once that is working, you can send the STANDBY command, then configure the device for 16-bit word length, etc. and then send the WAKEUP command.

Also could you share the schematic of the design to make sure there are no issues?

Regards,
Joachim Wuerker

Joachim Wuerker

Good catch. I'm actually sending the standby command, but seems like for this particular transaction, it was sampled incorrectly. There is a 0.3-0.5% error in the clocking but should be nominal.

Here's me trying a reset and reading the chip ID register to verify the ADC is working fine:

And right after this, I'm reading the ADC data. Did you mean 3x8x4 = 96 bit frame? Please confirm. 

Here again I see the data to be 0x800000 for both channels. 

Regards,
Dheeraj

Joachim Wuerker

Here's the schematic:

And these are the differential signals going into the ADC inputs:

Hope this helps!

Regards,
Dheeraj

Joachim Wuerker

Here's something interesting that I noticed. If I send the 96-bit frames 20 times, I see CH1 giving me some data a few times (20%). CH0 seems to be stuck at 0x800000. 

Regards,
Dheeraj

Hi Dheeraj,

yes, of course 3x8x4bits = 96bits. What were I thinking :-).

Thanks for sharing the schematics. I don't think it is the root cause of this problem, but both the AVDD and DVDD supply are expecting a 1uF cap to GND.

Without changing anything else after reset, can you again change MUX0[1:0] = 01b and MUX1[1:0] = 01b and then just read data?
It should be okay to change the multiplexer setting without going to Standby.

Have you already tried a different board or unit to see if the problem exists on all boards?
What input signals have you applied in your case?

Regards,
Joachim Wuerker

Hello Joachim Wuerker

I ran it on a different board. In this board, I see the values 0x8000 for channel 0 and channel 1, but occasionally I see data changing for channel 1 only. Is the value 0x8000 the default value returned by the ADC or something? 

Currently I'm not making use of DRDY interrupt. I was trying to get this to work without it. Since the response word has the data ready bits set, I was hoping the ADC values are being read correctly. Is this not true? Should the data reads only be done on the falling edge of the DRDY interrupt?

Let me know.

Regards,
Dheeraj

Hi Dheeraj,

thanks a lot for the additional tests. I am a little lost myself right now to be honest.

Have you tried changing the supply decoupling caps for some 1uF values? As I mentioned above, I don't expect this to be the root cause, but it would be good to eliminate this as a potential cause.

If the device would not start converting, then the conversion result would read 0x000000.

You can "blindly" read from the device without monitoring the DRDYn pin or DRDY bit, but there are some things to watch out for. I would recommend to read the “8.5.4 ADC Output Buffer and FIFO Buffer” section in the AMC131M02 datasheet. (We still need to add this important information to the ADS131M02 datasheet).

If you want to make use of the DRDYn pin or the DRDY bit, you should always read out the conversion results of both channels. Otherwise the device thinks you have not read all data and doesn't update the DRDYn pin and DRDY bit appropriately.

Did you also try the MUXx[1:0] = 01b setting on this other board?

One thing I noticed is that your DRDYn pin signal looks a little inconsistent. If you power up the board and don't write to the device at all, how does the DRDYn signal look like in that case?
Especially when you are communicating it looks like the DRDYn signal doesn't toggle anymore as expected.

Regards,
Joachim Wuerker

Hi Dheeraj,

I looked at some of your first scope plots again. There it seems like the DRDYn pin is transitioning low every 1us. That is impossible on this device, as it would indicate the device is running at a 1MSPS data rate. Could you measure the clock frequency on the CLKIN pin to make sure it is <8.4MHz?

And then please check the DRDYn signal right after power-up without writing to the device and report back.

Regards,
Joachim Wuerker

Hello Joachim Wuerker

We were soldering the SPI wires to the ADC. When doing this, I think we damaged some of the ADCs. I took a fresh board without the SPI wires and I'm finally able to read the ADC data.

When MUX[1:0] is set to 1 for both channels, I see really small values which indicates less noise which is good. I also tested the positive and negative test DC signals and I'm able to read 152mV (some error from 160mV), but not too bad.

And yes you were right. The clock frequency was outside the range by a bit. I adjusted the dividers and then the values looked more consistent. Thanks for your help!

Regards,
Dheeraj