Data converters

Data converters forum

State
Locked Locked
Replies 38 replies
Subscribers 46 subscribers
Views 932 views
Users 0 members are here

Support feedback

Options

Options

Similar topics

ADS131M04: - Not able to use simultaneous sampling

Sarthak Malik

Prodigy 40 points

Part Number: ADS131M04

Hello,

I am using ADS131M04 IC in one of our projects. So I am facing some issues in the IC. The simultaneous sampling is not working properly. When I enable all channels and read the data of all the channels then I am facing some data shifts in the output data only the first channel data is correct and the other channel's data is not correct as you can see in the attached image.

When I am enabling the single channel it is working fine I can read the correct data of all the channels by enabling a single-single channel. May I know what is the reason behind this?

Any help would be appreciable.

Thanks and Regards

Sarthak Malik

over 1 year ago

0 Dale Li over 1 year ago

TI__Mastermind 35550 points

Hi Sarthak,

Your attached image was missed. I'm not sure what your image will show, however can you provide your timing plot of SPI interface captured with oscilloscope? and also let me know your ADC configuration.

Best regards,

Dale

0 Sarthak Malik over 1 year ago in reply to Dale Li

Prodigy 40 points

Sorry, I forgot to attach the Image. Actually, I facing some data shift in the simultaneous sampling. as you can see in the attached image. And these are the ADC register configuration as you can see below.

Register 0 0x2405
Register 1 0x500
Register 2 0x500
Register 3 0xc
Register 4 0x6666
Register 5 0x0
Register 6 0x600
Register 7 0x0
Register 8 0x0
Register 9 0x800
Register 10 0x0
Register 11 0x0
Register 12 0x8000
Register 13 0x0
Register 14 0x800
Register 15 0x0
Register 16 0x0
Register 17 0x8000
Register 18 0x0
Register 19 0x800
Register 20 0x0
Register 21 0x0
Register 22 0x8000
Register 23 0x0
Register 24 0x800
Register 25 0x0
Register 26 0x0
Register 27 0x8000
Register 28 0x0

Waiting for your response! Why am I facing this issue with simultaneous sampling?

Thanks

Sarthak Malik

0 Dale Li over 1 year ago in reply to Sarthak Malik

TI__Mastermind 35550 points

Hi Sarthak,

Thanks for providing your register configuration. Can you provide timing plots captured with an oscilloscope including /CS, SCLK, DIN and DOUT? that will be very helpful to address the issue. Also, can you clarify the data for which channel in your image? it will be great if you can share your raw data.

Best regards,

Dale

0 Sarthak Malik over 1 year ago in reply to Dale Li

Prodigy 40 points

Hello Dale,

Thanks for the update Currently I am unable to provide the timing plots if you can't do anything without timing plots then I can arrange the timing plots. And In the Image, it is the second channel. Only the first channel is working fine other 3 channels are behaving the same as you can see in the shared image. But it's happening in the simultaneous sampling only. when I am enabling the one-by-one channel and reading the data then all channels are working fine. I am also sharing the Raw data of channel 2 on enabling the simultaneous sampling.

Channel_2_raw_data.txt

Thanks

sarthak

0 Dale Li over 1 year ago in reply to Sarthak Malik

TI__Mastermind 35550 points

Hi Sarthak,

Thank you for your clarification and also sharing the data. I noticed that your configuration in address 0x03 register is 0xC, this configuration indicates that all four channels of ADC are disabled, can you please verify? 0x0F0C will enable all input channels of M04 ADC.

Best regards,

Dale

0 Sarthak Malik over 1 year ago in reply to Dale Li

Prodigy 40 points

Hello Dale,

Sorry for the late reply Actually initially we turned off all the channels and at the time of streaming we enabled all the channels by writing 0x0F0C in the configuration register 3. We have also tried to enable all the channels at the start but captured the same result.

Regards

Sarthak

0 Dale Li over 1 year ago in reply to Sarthak Malik

TI__Mastermind 35550 points

Hi Sarthak,

Thank you for your confirmation. Can you please provide timing plots an oscilloscope? at least two frames will be good to check.

Thanks& regards,

Dale

0 Sarthak Malik over 1 year ago in reply to Dale Li

Prodigy 40 points

Hello Dale Li,

I am sharing the timing plots of an oscilloscope where Yellow is CS, Green is SCK, Blue is MISO, and RED is MOSI.

Thanks

Sarthak Malik

0 Dale Li over 1 year ago in reply to Sarthak Malik

TI__Mastermind 35550 points

Hi Sarthak,

A whole frame data should be similar as the following timing, the first word is status or register data, then the data for CH0, CH1, CH2, CH3, the last word could be CRC, each word size is either 16 bits, 24 bits or 32 bits based on your configuration. one or two whole frame data will be helpful and also a zoom-in timing is very helpful as well. Thanks.

Best regards,

Dale

0 Sarthak Malik over 1 year ago in reply to Dale Li

Prodigy 40 points

Hello Dale,

Sorry for the late reply, I am sharing the updated image please check.

Thanks

Sarthak

0 Dale Li over 1 year ago in reply to Sarthak Malik

TI__Mastermind 35550 points

Hi Sarthak,

No worries, thank you for providing the timing image. Your timing shows that the data of CH0/CH2/CH2 are zero and the data of CH3 is 0xFFFFFF, are all channel inputs floating or short? what's the data of the first word which should be the status register?

PS: What you did (disabled timeout, set gain to 64 and phase delay for each channel) by writing the registers should not impact data output.

Best regards,

Dale

0 Sarthak Malik over 1 year ago in reply to Dale Li

Prodigy 40 points

Hello Dale Li,

Yes, all the channels are floating. Why do we need a phase delay for each channel? because there is simultaneous sampling available in the IC, why do we need phase delay? and I have tried with gain 64 and phase delay for each channel but no improvements in the data.

Thanks

Sarthak

0 Dale Li over 1 year ago in reply to Sarthak Malik

TI__Mastermind 35550 points

Hi Sarthak,

From the timing you shared, these data (zero and the data of CH3 is 0xFFFFFF) on the DOUT are correct data for floating input, so you are getting correct data for each channel. You can double check by using a DC input on some of channels, it will be clear for you to see if the data is output correctly for the corresponding channel.

When you collect data, were you monitoring /DRDY signal? basically we keep monitoring /DRDY signal, we usually start selecting the ADC and collecting data when a falling edge of /DRDY is detected, a low /DRDY indicates that the data is ready for the microcontroller to read.

As I said, your programming internal registers to set gain and phase delay should not impact data output, so I did not think you can get any improvement.

Best regards,

Dale

0 Sarthak Malik over 1 year ago in reply to Dale Li

Prodigy 40 points

Hello Dale,

If my channel data is correct, why am I getting the spikes in the output data plots?

Regards

Sarthak

0 Dale Li over 1 year ago in reply to Sarthak Malik

TI__Mastermind 35550 points

Hi Sarthak,

The data in the SPI timing you shared with me are correct. It will be better if you could share the SPI timing when observing the spikes.

Also, were you monitoring /DRDY signal to read the data?

Regards,

Dale

0 Sarthak Malik over 1 year ago in reply to Dale Li

Prodigy 40 points

Hi Dale,

Can you please suggest how to capture the SPI timing when observing the spikes.As its so fast to capture.

Also, were you monitoring /DRDY signal to read the data?

Reply-->Yes,we are monitoring signal to read the data.

Regards

Sarthak

0 Dale Li over 1 year ago in reply to Sarthak Malik

TI__Mastermind 35550 points

Hi Sarthak,

I would suggest to try using the trigger of oscilloscope. I checked on our EVM board and captured a lot of data, but did not see any spikes. Please see the following timing. I'm trying to understand where it came from on your circuit board. Timing is one way I can check. Did you check other device/boards whether they showed similar behavior or not?

Thanks&regards,

Dale

0 Sarthak Malik over 1 year ago in reply to Dale Li

Prodigy 40 points

Hi Dale

What should we set the trigger at, since the occurrence and extent of spikes is very unpredictable?

Regards

Sarthak

0 Dale Li over 1 year ago in reply to Sarthak Malik

TI__Mastermind 35550 points

Hi Sarthak,

You can see how high is your spike, and set a proper voltage to trigger it on oscilloscope.

Did you check other device/boards whether they showed similar behavior or not?

Regards,

Dale

0 Sarthak Malik over 1 year ago in reply to Dale Li

Prodigy 40 points

Hi Dale

That is the whole problem. There are no spikes on the input (analog) side. We checked that already, it's all clean.

Regards,

Sarthak

0 Sarthak Malik over 1 year ago in reply to Sarthak Malik

Prodigy 40 points

Hi Dale

Please suggest further as its been so long this issue is running.Our work has been stuck because of that.If you need any information from our end please let me know but please try to close this issue on Priority basis.

Regards

Sarthak

0 Cole Macias over 1 year ago in reply to Sarthak Malik

TI__Mastermind 18900 points

Hi Sarthak,

I'm sorry to hear that your work is stuck, looks like this one has been going on for awhile. Let me see if I can help.

With all of the work done, I unfortunately don't think the issue is obvious, I see some obvious issues that haven't been discussed, but I think we can drill down to the bottom of it

Let's establish givens:

The settings provided make sense and are currently setting f_dataRate = 1kSPS in Very-low-power mode which means the f_CLK< 2.08MHz, is this correct?

What the issue could be:

The Register dump makes some sense so I'm going to assume that the exact formatting isn't part of the issue (not clocking data on the falling edge is a typical issue with these devices). With that being said, the oscilloscope waveform above seems to take ~350us to get one channel of data (the 8 bit SCLK chunks, which should be 24bit SCLK chunks, are really far apart from each other, which wastes time). The data rate above means that f_DRDY should be toggling every 1ms. Can you verify the f_DRDY is toggling at that rate?

This is a pretty large percentage of the time. I'm not sure if you clear the FIFO after writing the registers, but if not, the FIFO within the device is definitely filled up by the time you take data and we can't trust the channel data as a result. As soon as the device power up, it starts converting, so between that and the first NULL command to grab data, this would be considered a "pause" before you collected data for the first time. Here's some text from the datasheet:

If you already do this, then we can move on to some of the other issues that don't look correct about the device.

Other Issues:

Bus contention:

What is your intended DVDD?

Assuming the MISO POCI or SIMO PICO is connected to the same voltage rail, we are current in an unacceptable voltage rail range for the device. The measurement "Top" for each waveform does not fall within 1.65V through 2V < V_DVDD < 2.7V - 3.6V. If I take MISO for example, I can see what looks like 2.2V and a distinct 2.4V waveform "high" in the same transaction. This is usually the result from bus contention and if you have anything else tied to MISO, it might be pulling that rail down. Because we power the digital logic core (including modulators) with this rail, it would surprise me if some unexpected behavior were to occur.

This needs to be fixed in addition to the problem we're seeing. I would take a look at your schematic and see if anything else could be the issue (in the past I've seen an external memory IC near the MCU cause this problem).

Best,

-Cole

edit: changed language

0 Sarthak Malik over 1 year ago in reply to Cole Macias

Prodigy 40 points

Hello Cole

Thank you so much for response.

Please find the details:

1.f_CLK< 2.08MHz, is this correct? --> We are using Clock 2.0 Mhz.

2.Can you verify the f_DRDY is toggling at that rate? --> f_DRDY is toggling at 1kSPS .

3.MISO and MOSI are running at same voltage level,

4.What is your intended DVDD? --> 3.3 V

If you need any other information please let me know.

Regards

Sarthak

0 Cole Macias over 1 year ago in reply to Sarthak Malik

TI__Mastermind 18900 points

Hi Sarthak,

I might be interpreting the oscilloscope screenshots but the V_OH are out of specification then:

3.3*0.8 = 2.64V and the high on the waveforms are 2.37V and less than 2.64V. Why is this?

Can you send a picture of your schematic?

Thanks,

-Cole

0 Sarthak Malik over 1 year ago in reply to Cole Macias

Prodigy 40 points

Hi Cole

Sorry for the delay response.

We are using Schematic as required in the data sheet.

Thanks and Regards

Sarthak

0 Cole Macias over 1 year ago in reply to Sarthak Malik

TI__Mastermind 18900 points

Hi Sarthak,

Thanks for the response, it makes the review easier then.

What about the schematic on the MCU side? I won't be able to review it with much confidence but DVDD is an input that is sourced somewhere and I would start looking there.

Best,

-Cole

0 Sarthak Malik over 1 year ago in reply to Cole Macias

Prodigy 40 points

Hi Cole

Really sorry ! It's proprietary and we don't have the clearance to share that with anyone.

Can we debug the issue with some other way.

Best

Sarthak

0 Cole Macias over 1 year ago in reply to Sarthak Malik

TI__Mastermind 18900 points

Hi Sarthak,

I understand, thanks for letting me know.

Unfortunately, I don't have a way to help you fix the DVDD issue besides what I recommended before. Grab an oscilloscope, find the source of the DVDD voltage rail, and probe directly at the pins of the source while sending the same SPI transaction. I would then compare that with the voltage at the pins of the ADS131M04. Finally, I would look at any other devices on the MCU that uses the same DVDD source and look at the voltage there.

The most common cause of bus contention is another device with programable SPI MISO PICO pins (or a MUX or voltage translator). Ensure the output pins are HIZ when they are not used. If there is any passive pullups or pulldowns within the device that fight with the DOUT pin, then you'll see this kind of behavior.

Best,

-Cole

0 Sarthak Malik over 1 year ago in reply to Cole Macias

Prodigy 40 points

Hi Cole

In previous message you ask "

I might be interpreting the oscilloscope screenshots but the V_OH are out of specification then:

3.3*0.8 = 2.64V and the high on the waveforms are 2.37V and less than 2.64V. Why is this?"

Now,we have check V_OH=3.3V.But still we are seeing spikes on the input (analog) side.

Please find the attached waveform.

0 Cole Macias over 1 year ago in reply to Sarthak Malik

TI__Mastermind 18900 points

Hi Sarthak,

It does look a bit better but it looks like you might be violating the -0.3V pin absolute maximum (3.7Vpp-3.39Vtop = 0.31V). Its also very clear that the DGND is not 0V, or at least the Low state is below 0V on the waveform. In addition the High is higher than the 3.6V which is also out of spec. There is a risk that the device might have been damaged.

Do you happen to have DGND and AGND split in your schematic that is connected at a single point? I see this sometimes when DGND and AGND are not connected together to a general GND plane with a via that is directly next to the pins.

Best,

-Cole

0 Sarthak Malik over 1 year ago in reply to Cole Macias

Prodigy 40 points

Hi Cole

DGND is 0 V and DGND - AGND is connected to each other.The -0.3V is due to Problem of Oscilloscope calibration.Please find the updated attached waveform.

Best

Sarthak

0 Cole Macias over 1 year ago in reply to Sarthak Malik

TI__Mastermind 18900 points

Hi Sarthak,

What's going on with 2 distinct levels for digital voltage? Do we know what might be causing that? See the white box below:

At this point, the waveform looks a lot better. Can we take a look at all 4 SPI waveforms on the same capture now? CS, SCLK, DIN and DOUT, just like you did before. They should also be within spec still.

After that, I'd like to look at the response to a NULL and look explicitly at the STATUS word.

Thanks,

-Cole

0 Sarthak Malik over 1 year ago in reply to Cole Macias

Prodigy 40 points

Hi Cole

Please find the attached waveform:

Yellow is CS, Green is SCK, Blue is MISO, and RED is MOS

Thanks and Regards

Sarthak

0 Cole Macias over 1 year ago in reply to Sarthak Malik

TI__Mastermind 18900 points

Hi Sarthak,

Everything looks better now. That being said, 95% of time, fixing the levels will fix any stage behavior seen with data collection. Everything looks okay and I assume you're still getting the spikes on the input.

I haven't see confirmation that you toggle RESET before collecting data (to clear the FIFO), but I'm going to assume you are doing that.

As a result, I've sent you an email. Please keep an eye out for it.

Best,

-Cole

0 Sarthak Malik over 1 year ago in reply to Cole Macias

Prodigy 40 points

Hi Cole,

Yes everything looks better now but I am still geting spikes in the data. Yes I am toggle RESET before collecting the data.

Thanks

Sarthak

0 Sarthak Malik over 1 year ago in reply to Sarthak Malik

Prodigy 40 points

Hi Cole,

I am still getting spikes in the data.Is there anything else we are missing?

Thanks

Sarthak

0 Sarthak Malik over 1 year ago in reply to Sarthak Malik

Prodigy 40 points

Hi Cole

Any update ?

Thanks

Sarthak

0 Cole Macias over 1 year ago in reply to Sarthak Malik

TI__Mastermind 18900 points

Hi Sarthak,

We're in communication on email. Still trying to get you a new EVM. No updates.

Best,

-Cole