ADS131E08EVM-PDK: The DIN data of ADS131E08 is inconsistent with the DIN data of J1 port

Hello Zhen,

Answering your question here:

I'm not sure what you mean. It looks like Channel 2 and channel 5 are exactly the same according to your picture. The distance from J1 to the pins are a couple of inches away with nothing to configure so there's no obvious explanation why the DIN pin and J1 would be different. If you do want to check for yourself, I'd recommend using a handheld Digital Multimeter (DMM) and do an impedance test been the pins of J1 to the DIN pin. Assuming everything you should see <1 ohm impedance between the two spots. If it is OPEN or in the megaohms, this would indicate there might be an open circuit between the point which is physical damage.

For your other post:

Relating back, your other post(s): https://e2e.ti.com/support/data-converters-group/data-converters/f/data-converters-forum/1119192/ads131e08-ads131e08-error-reading-id-through-spi and https://e2e.ti.com/support/data-converters-group/data-converters/f/data-converters-forum/1114346/ads131e08-error-reading-id-through-spi threads are locked after numerous days of inactivity, which is what looks like what happened. Sometimes, its helpful to ensure there is a question in the response to confirm that your issue was not resolved.

If you're still debugging trying to read the ID register, I have two suggestions:

• Get an oscilloscope capture of the RREG command. I essentially want to see this below but with an oscilloscope, not a logic analyzer.

• Let's try a different command. I think the easiest ones are START and STOP.

As shown in the sheet. Tie the START pin low and monitor nDRDY, in addition to the SPI bus. If the START command can start triggering and nDRDY to toggle and a STOP will make nDRDY stop toggling, we can rule out the possibility of incorrect SPI timing specifications. Looks like Ryan helped you a lot to start but I don't think confirmed a successful SPI command yet, feel free to correct me if I'm wrong. As a result, I need to see that we can correctly get a response from the device.

Best,

-Cole

Hello Cole

I'm sorry. I misread the waveform. Since THE DIN pin of ADS131E08 can read 0x20 0x00 0x00, it still does not return the ID number.

Yes, Ryan has helped me a lot. Thank you very much.

Since I didn't get a reply to my first post, it was locked, and then I sent a second post, but I didn't get any reply, so I sent this post.

As for oscilloscopes, they have not been delivered yet, so they can only be observed with logic analyzers.

When I just pull START low, I can see that DRDY has waveform, but after I pull it high, the waveform disappears.

However, when I send the "START""STOP" command, DRDY does not respond, the problem seems to be that ADS131E08 does not respond to the command I issued.

Hi Cole

This is what I measured SCLK and MOSI with oscilloscope.

Hello Zhen,

Thanks for the clarification.

Your formatting for the START and STOP commands look correct but you didn't wait long enough for nDRDY to attempt and toggle. In your previous picture, you showed

Zhen He said:

When I just pull START low, I can see that DRDY has waveform, but after I pull it high, the waveform disappear

It takes almost ~143us before nDRDY toggles. This is explained in the datasheet:

Sending a START command is effectively the same action as using the START pin. You need to wait for the settling time to see if nDRDY actually toggles before sending a STOP command. I'd recommend adding some margin (t_settle + t_DR after completing the START command via SPI).

Oscilloscope shots

I still need to evaluate the timing but its very very clear from the oscilloscope that the GND'ing between the ADS131E08EVM and the TMDSEVM6678LE is suboptimal. 500mV overshoot on a 1.8V logic high digital signal is unacceptable for most standards. In addition, the GND has large frequency, no periodic oscillations. This could be a signal integrity issue; i.e. these noisy signals are not correctly interpreted by the ADC. 

As a reminder, GND should be a constant 0V. You'll need to use shorter and thicker wires interfacing between the two boards. I'd also recommend adding some more GND connections between the two boards if you can.

Best,

-Cole

Hello Cole

I added delay in the program according to your suggestion, and it can be found that when I send 0x08 and delay, DRDY generates pulse. (tSETTLE was 145.48μs, tDR was 31.26μs, and 4tCLK was 1.96μs), indicating that ADS131E08 was able to respond to these two commands.

As for the grounding problem, the I/O output interface of TMDSEVM6678LE is 1.27mm, while the I/O input interface of ADS131E08EVM is 2.54mm. So I need to use a Dupont wire from 1.27mm to 2.54mm, and then access ADS131E08. I don't know if that's gonna be a problem.

Hey Zhen,

Zhen He said:

ADS131E08 was able to respond to these two commands

That's great! So, the timings probably aren't the problem. 

Zhen He said:

I need to use a Dupont wire from 1.27mm to 2.54mm,

That's too bad, you might want to look into adding more GND wires between the two boards as it might help.

If I was willing to sacrifice the wires, I would cut them in the middle, strip the wire, and then solder the two halves together to effectively make a 1.27mm to 2.54mm converter wire. Its pretty time consuming, I'd probably recommend going after some lower effort debug steps beforehand. But it will definitely make the wires shorter and help the GNDing issue.

Zhen He said:

This is what I measured SCLK and MOSI with oscilloscope.

Going back to this, I realized you don't have MISO and CS on the oscilloscope screenshot. Do you have the ability to probe all 4 channels at the same time or can you only do 2? If you can only do two, I'd ask to capture the same command with MICO and CS, with the same voltage and time division, so I can put them all on one screen and do an analysis of the timing.

Best,

-Cole

Hello Cole

I can capture 4 channels, but MOSI has no output, so I only measured the data of SCLK, CS and MOSI.

But nothing seems to be wrong.

On the issue of GND, I would like to ask what kind of results can exclude the influence of GND on transmission. (The line is now 15cm long).

In addition, I think it is related to the SCLK rate, because the "START" and "STOP" transmission do not require the SCLK rate. In multi-byte transmission, the rate will be required. According to the content in 9.5.2.2 and DR[2:0] in CONFIG 1, I set SCLK to 8MHz.

Hello Zhen,

GND can result in anything from ignored SPI commands to completely incorrect setting programmed into the device. Because the read command is being ignored, its a likely conclusion.

SCLK of 8MHz is within the valid range, the fastest it can be 20MHz (1/50ns of SCLK period spec). Aa you notice, there's no minimum spec. You can actually run SCLK as slow as you want and it will work (assuming you don't have a SPI timeout).

Zhen He said:

"START" and "STOP" transmission do not require the SCLK rate

Not sure what you mean by this one. Maybe using the START pin doesn't. But the START and STOP (SPI commands) require SCLK to hold the data from MOSI line and SCLK is defined by the spec above.

Zhen He said:

But nothing seems to be wrong.

Unfortunately, the SCLK looks even worse than the previous oscilloscope screenshot. Now it has 1V overshoot. Also note, I'm getting concerned with the undershoot on SCLK as well. 

SCLK is considered a digital input and you are going 0.5V below DGND. With repeated exposure, this could result in damage to the device. You'll need to connect more GND wires, make the wires thicker, make them shorter, or some other combination before we proceed. 

Best,

-Cole

Hello Cole

This is the result after I connected the four SPI signal cables with 130 ohms resistance in series, and it looks like I successfully returned the ID number.

However, I have a question, are the maximum and minimum values of CS signal here normal? It's only tens of millivolts.

Hi Zhen,

That looks like an improvement nice job. Looks like series resistors were recommended by the datasheet too:

Unfortunately, now we have some other strange things I can see with the waveform. But, let me answer your question first:

Zhen He said:

are the maximum and minimum values of CS signal here normal? It's only tens of millivolts.

Unfortunately, no,  CS is not correct here, but it will work. During a SPI transaction, CS will be pulled to GND or 0V for the entirety of the frame. The spec says the value needs to be 0.2*DVDD (1.8*0.2 = 360mV) to be valid. 

So, ~20mV GND might work, but its clear the GND noise isn't random white noise, its clearly tied or coupling with MISO and SCLK and would not be accepted in a real world design. This is a prototype and there might be a desire to ignore it but it is solvable. 

Bus Contention:

From your screenshot, you can clearly see there are two separate logic levels that are fighting for control. You have mentioned DVDD = 1.8V, which is the intended value of high's and low's for the SPI line. However, I see ~1.8V-2.0V and ~3.3V. This is called Bus Contention, I encourage you to search externally to learn some more. 

Anyways, this sometimes happens if you're supplying 1.8V to DVDD on the ADC but the MCU is trying to output another. You will need to look into the MCU's settings and see what the logic value high output voltage is for the MCU pin you are using. Something tells me, once you fix that, your SPI interface will be done.

Best,

-Cole

Hello Cole 

1、“there might be a desire to ignore it but it is solvable”

      The SCLK, MOSI and CS signals are all sent by TMS320C6678. The amplitude of these three signals should be similar, but I don't know why the CS signal is the only problem, is it the GND problem? Need a shorter, thicker line to connect?

2、This is what I see from the TMS320C6678 datasheet, but I can't see what's wrong with it.

3、In addition, it can be seen from the figure that the output of MOSI should be ~1V and ~1.8V. This is the signal output of ADS131E08, it should be the problem of ADS.

Hey Zhen,

Zhen He said:

The amplitude of these three signals should be similar, but I don't know why the CS signal is the only problem

Yeah, that is the million dollar question at the moment. I like your line of thinking. Thicker and shorter GND wires could help here, give it a shot. 

Zhen He said:

This is what I see from the TMS320C6678 datasheet,

I assume that you're using LVCMOS and DVDD18 is a pin? Can you probe the pin with an oscilloscope, in addition to the MISO pin on the same plot? If we see some instability on DVDD18 then we might have a reason why it isn't working. I would look for the voltage supply that determines what the MISO should be.

Zhen He said:

it can be seen from the figure that the output of MOSI should be ~1V and ~1.8V

Not sure what figure you are talking about. None of the waveforms for MOSI have been ~1V. The waveforms look like ~1.8V or ~2V max which shows the device is working as expected.

Below shows that the minimum should be 0.9*DVDD. We've assumed that DVDD = 1.8V so 0.9*1.8 = 1.62V. If the output was 1V, this would indicate that DVDD is low or that the device might be broken in some way as it would outside of the specification.

But you are correct, if there was a problem of the output of the ADS digital output (MOSI) then it was be the fault of the ADS. Maybe we can probe DVDD directly and see if it is stable and around 1.8V?

Best,

-Cole

Hello Cole

The problem with the previous CS measurement value is that the oscilloscope probe is faulty.

Now, I use the same probe to measure SCLK, CS, MOSI, and MISO. As can be seen from the picture, except MISO, the other three signals should be normal. I wonder if the previous input voltage exceeds the limit value of ADS131E08, leading to its damage, and thus causing the abnormal output of MISO?

Finally, I measured the value of DVDD and found that it was basically stable at 1.811V.

Hey Zhen,

Good find with the scope probe, that sounds like a tough one to figure out.

Agreed, the 1.8V rail on the ADC looks stable, how about the one used by the MCU?

Zhen He said:

I wonder if the previous input voltage exceeds the limit value of ADS131E08, leading to its damage, and thus causing the abnormal output of MISO?

Its a good question, 1.2V is definitely below the 1.6V threshold that's allowed by the spec so it is not operating as expected. Usually damage manifests in the form that the output can no longer toggle. In other words, damage usually means the output cannot switch and its stuck at GND or DVDD. When I see intermittent voltage levels like MISO it either means the source voltage (DVDD) is unstable, or it could be a loading issue--which would have caused the DVDD voltage to sag as the SPI transactions occurred. We don't see that here though.

If you do have another device or EVM laying around you could check, but I understand if you only have 1.

If we look at the overall situation, you are able to correctly get the ID now right? Have you tried moving forward with what you have and writing to a register, reading back the correct value, and checking if the device correctly changed its behavior?

Some other thoughts:

I just want to confirm that you are measuring the MISO line at or near the DOUT pin of the ADC, and the ground lead connected near GND pins of the ADC. I wouldn't necessarily say J1 is particularly close. Because of inductance in the GND plane, we might not be able to assume the voltage seen at J1 is the same seen at the pins of the device.

So, to confirm our assumptions, I suggest measuring the same signal close the the pins of the device. After that, I suggest you measure the same signal close to the MCU and see if there's a difference.  Again, this is what some would call a "sanity check" and it is usually a test that seems mundane but its purpose is to make sure we are not working on invalid assumptions.

Let me know how that goes and I might be able to do one last thing to help.

Best,

-Cole

Hello Cole

1、This is the result I measured from TP21 of TMDSEVM6678LE, which is also basically stable at 1.8V.

2、

These are the SCLK, CS, MOSI and MOSI of J1 port and chip port of the two boards that I measured respectively. There are 16 pictures in total, which I packed in the folder.

The waveforms of the two boards are basically the same, and the waveforms of the J1 port and the chip port are also basically the same. However, MISO has changed (I haven't changed the program code)。

.Two EVM comparison pictures.zip

3、This is my MCU, due to its package form, I cannot measure the SPI signal from the chip pin, only from the I/O 80pin.

4、

If I use the logic analyzer to measure the DOUT of the ADS131E08, I can read all the register values, and I can change the register values. It may be that the logic analyzer has a high level threshold of 0.9V, so it is able to identify the previously problematic waveform.

However, for the MCU, the ID "0xD2" returns to the MCU as "0x36". So, due to the MISO output problem, the ID is still not actually obtained correctly.

Hey Zhen,

Zhen He said:

1、This is the result I measured from TP21 of TMDSEVM6678LE, which is also basically stable at 1.8V.

Agreed, looks stable. Thanks for taking the data.

Zhen He said:

J1 port and the chip port are also basically the same. However, MISO has changed (I haven't changed the program code)

Very interesting. I don't have an explanation for this. MISO definitely look different from before and pretty clean, can't comment if it was correct though. If you had to disconnect and reconnect wires there might have been a connection issue. However, it feels unlikely. Do you still have the 130ohms in series? Can you reduce it to around 49ohms and see if the charging rising edge comes up a little faster?

Zhen He said:

3、This is my MCU, due to its package form, I cannot measure the SPI signal from the chip pin, only from the I/O 80pin.

Understood, looks like you have a bunch of QFN device packages on the board which makes it very difficult to measure at the pins. If you ever make a complex design, I'd always recommend some exposed copper on the board to act as a testpoint so you can do debugging like this.

I digress, I think measuring from the 80 pin connector and to the ADC and comparing the two, just MISO and SCLK, could be a helpful sanity check.

Zhen He said:

4、

If I use the logic analyzer

I'm a little confused by this. So, only when the logic analyzer is plugged in the MCU can correctly read and write to registers. This would include the device ID. But if you remove it then the MCU get the incorrect one?

Or the logic analyzer give the correct value no matter what and the MCU always gets the incorrect value?

When took one of your old screenshots, I counted where the register data should be and it seems to match with 0xD4 (0b11010010) (I drew the lines as best I could). 0x36 seems to line up with the first waveform when you're actually issuing the RREG command and DOUT is technically a "don't care" waveform. Try adjusting the code so it waits for the 3rd set of SCLKs to read the data there. 

Best,

-Cole

edit: Looks like I uploaded the picture where I drew the lines of the rising edge, its matches up much better on the falling edge, I just don't have the picture right now

Hello Cole

1、

I tried to connect 56 ohm resistors in series before, but the SPI voltage output by MCU would exceed the input threshold of ADS, and I think MISO is still the problem of ADS, but the input SPI voltage meets the requirements and the DVDD is stable. I really don't understand where else might be the problem.

2.

I have tested the signals at 80pin, J1 and ADS pins respectively before, and all three are consistent. Therefore, I still think the input SPI signal is OK now.

3.

What I mean is that I use a logic analyzer instead of an oscilloscope to measure the SPI signal at J1, and then decode the signal. I find that I can identify the ID number, and when I modify CONFIG1, I can then read out the modified register value. It is possible that the logic analyzer's high level threshold is 0.9V, so the previous magnitude of ~1V is recognizable to the logic analyzer.

4.I think 0b11010010 is 0xD2. Also, 0x36 is the DATA returned at the last 0x00 in "0x20 0x00 0x00", so it is the DATA at "REG DATA".

Hey Zhen,

Zhen He said:

1、

I tried to connect 56 ohm resistors in series before, but the SPI voltage output by MCU would exceed the input threshold of ADS, and I think MISO is still the problem of ADS, but the input SPI voltage meets the requirements and the DVDD is stable. I really don't understand where else might be the problem.

Okay, I'm a little confused. Changing the resistor in series shouldn't significantly change the output voltage of the MCU. When you put the resistor in series, we're essentially changing the time it takes for the line voltage to achieve the target voltage (i.e. RC time constant). In other words, we have an RC circuit on the line from MCU to ADS, the wires create a constant C and R is changed by the designer. When R is very large it takes a long time to reach the voltage. 

And when you say "input threshold" the MCU's goal is to exceed the minimum logical input level for High... 

...but not exceed the Digital input voltage absolute maximum.

Again, the output value is ultimately determined by the MCU. So, if the input voltage on something like MOSI or SCLK exceeding the absolute maximum voltage threshold then it is absolutely the MCU's fault. 

Zhen He said:

2.

I have tested the signals at 80pin, J1 and ADS pins respectively before, and all three are consistent. Therefore, I still think the input SPI signal is OK now.

Okay, good to know. Thanks for checking.

Zhen He said:

3.

Understood now. Thanks.

Zhen He said:

I think 0b11010010 is 0xD2

Nice catch. Yes, 0b1101 0010 is 0xD2, which is the intended ID for this device.

Zhen He said:

0x36 is the DATA returned at the last 0x00 in "0x20 0x00 0x00", so it is the DATA at "REG DATA".

Which source determined the 0x36? The MCU, the logic analyzer, or the oscilloscope?

At this point, the only signal I know I can trust is the oscilloscope. I'm not sure if you resolved the threshold issue on the logic analyzer or what it says now. In addition, the MCU hasn't really given a correct value that we can trust (unless you have proof of that by reading the default of some of the other registers and comparing them to the oscilloscope screenshot).

The oscilloscope screenshot you posted very clearly does not match 0b0011 0110 (0x36 if I copied and pasted correctly this time) on the oscilloscope. There is only one section with a 0b11, the other section looks like 0b01001. Depending if the MCU or Logical analyzer is giving you 0x36, you'll have different steps in debug. My guess is that 0x36 is from the MCU which means you'll need to do some debug on your code until is can accurately give us what the oscilloscope shows.  

Best,

-Cole

Hello Cole

1. The maximum output is 2.333V and the minimum is 600mV before the series resistance. For MCU, the output high level range is [1.35, ~], and the output low level range is [~, 0.45], so the output voltage is in line with the requirements for MCU. However, it is out of the ADS input voltage range.

2.After series resistance, the MCU output voltage range already meets the ADS input voltage requirements. So, the problem is that with the correct input voltage, the ADS output voltage cannot reach 0.9DVDD.

3.For MCU, falling edge sampling, so according to the photo below, if the ADS output voltage reaches 0.9DVDD, then "0xD2" can be correctly identified.

But MISO output three types of high levels, DVDD is stable at about 1.8V, high level should be the second case. Why do the other two wrong high level voltages occur?

Hi Zhen,

I think we're in agreement now. Thanks for clarifying.

Zhen He said:

Why do the other two wrong high level voltages occur?

I agree, this will probably solve the last problem. Let me consult with the team for a couple of days and see if I can come up with something to try.

Thanks,

-Cole

Hi Zhen,

Can we do a test by disconnecting the MISO wire from the MCU and checking it on the EVM only? The MCU can still ask to see the data through SPI but not connect the line to the MCU and probe it with an oscilloscope to verify the behavior.

If we measure the EVM and don't see the behavior anymore, then we can agree the MCU is causing the issue. The team seems to agree that it is bus contention. Sometimes, there's weak pull-downs that can be enabled or disabled on the MCU GPIO side and its clear the MCU can pull down to GND very easily but can't quite reach the 1.8V logic level which would indicate its pulled down. Some users have to change libraries or modify them to get rid of waveforms like this.

If we see the same behavior on the EVM, we'll debug from there but there isn't a good explanation from the team that the ADS could be causing the issue.

Best,

-Cole

Hi Cole,

Thank you very much for the testing protocol.

1.According to your suggestion, I have tested the MISO of both. When I test the MISO of MCU, I can see that there is a waveform display, but when I test the DOUT of ADS, there is no waveform. So, this should be what you call bus competition. But how do I solve it?

2.As far as I know, 6678EVM is the same as 6657EVM in SPI design. So I removed R202 in accordance with the Iding's advice. So now CS1 is only connected to ADS. Will such a master and slave have the problem of bus competition?

Best,

-Zhen

Hi Zhen,

Interesting result!

I think this is a little out of the realm of my expertise. I know that setting up GPIOs and SPI pins will be associated with settings that can be adjusted in software. E.g. you can manually change the same SPI SCLK pin from 1.8V to 3.3V or 2.4V by changing some settings. Sometimes, these are buried within libraries or initialization routines where the pin is defined with both 1.8V and 3.3V depending on what's happening. Sometimes, like shown in your follow up, there's some translator or buffer in HW on the board that helps bump up the voltage to a certain level, so following the trace from connector to pin could give you some clues since SPI is usually shared. All of this could contribute to bus contention.

Unfortunately, I don't know anything about the 6657EVM or the buffer circuit you showed. I think the best way to do this is to ask a related question based on this thread with the orange button above and let them know there's a SPI contention issue. Show the MISO before and after screenshots and ask if anything in HW or SW that could be causing this, because the debug has clearly shown that the ADS131M0x is not at fault.

Wish I could help more, I'll try to find the new thread you post and follow it so I can help explain anything that's needed by the 6657 team.

Best,

-Cole

Hi Cole

Thank you for your help over the last few days. Thank you very much.

I have submitted the relevant questions, the rest depends on whether there is an engineer who can reply.

Best,

-Zhen

Hi Cole

In addition, I have a question.

When SCLK, CS and MOSI are used to connect MCU and ADS, and the DOUT of ADS is measured after disconnecting MISO, why is its output kept low from the oscilloscope waveform?

Since the MISO of the two is not connected, the MCU should have no effect on the ADS on the MISO pin? For ADS, when the correct command is received, its DOUT should have an output.

No problem Zhen.

Zhen He said:

When SCLK, CS and MOSI are used to connect MCU and ADS, and the DOUT of ADS is measured after disconnecting MISO, why is its output kept low from the oscilloscope waveform?

Hmm, I think I missed this in the previous post, sorry about that.

The DOUT/MISO should be correct for whatever command you put in. So, if we're still trying to read the ID then you should get 0xD2 on the ADS side. What command is sent for this waveform? Can you provide MISO, MOSI, and SCLK on the same screenshot again? Definitely double check the probe on a known voltage as a sanity check.

The MCU side still pulling to GND when SCLK is toggling is still a problem that needs to be solved. Keep me updated with what might be happening there.

However, I wonder if there is some sort of loop that's happening when DOUT is connected to the MCU, but its a bit to early to speculate. I'll wait for the data.

Best,

-Cole

Hi Cole

When I looked through the manuals for the 6678DSP, I found the problem. SPIDIN is dropdown by default when CS1 is used. Even though I removed the R202 earlier, selecting CS1 will still make it drop down.

And then I see that CS0 is connected to Flash, and I can see that the MISO at Flash is pulled up, right? So I plan to remove this Flash and communicate with ADS through the SPI interface of Flash. I think that should be all right.

Best,

-Zhen