ADS7844: Unexpected DOUT

Alicia,


I don't think it's a problem that there is data on DOUT. It could be a previous conversion being clocked out. You can even see something like this in Figure 6 of the datasheet.

If there wasn't a BUSY indicator, I'd say that it looks like you've already clocked out the data, and the DOUT is just coming out with the zero-filled result afterwards.

At this point, I don't see anything wrong with the way you have the device set up. What was the voltage input when you collected this data? Can you verify the reference connection?

When you take the data next, make sure you have a non-zero input on the input of the device This would be CH4 (if you keep using the 010 channel). Also, make sure COM is connected to ground. I'd check the connections back at the device pins.

Other than that, I'd also check other channels, just in case there's something wrong in the layout or channel connection.


Joseph Wu

Hey Joseph,

I thought Figure 6 was showing a 15 clocks per conversion implementation which I was trying to avoid because it's a little less deterministic (or at least for me it is).  If I'm always sending 24 clocks at a time (with significant amount of time between queries) shouldn't DOUT always be flat-lined while I'm sending the command?

Since my last post I've added a delay between the write and receive and now I'm getting different results (CH0 has an input of 1.5V) however, I still get data when i'm sending my command.

Alicia,


My point about Figure 6 was that you can see that there is some clocking out of data while the Control Byte was being written. It just depends on what was happening on the previous state.

I would note that I did find a previous case where there was some data being clocked out on the Control byte, but it was in an unresolved post:

e2e.ti.com/.../257353

Normally, I would say that it's probably not a big deal if you're getting the correct data, but in your case, your input is 1.5V on a 3.3V reference. You should be getting:

(1.5V/3.3V)*(2^16) = 29789d = 745Dh

However, you're getting 91C8h. This would convert to:

91C8h = 37320d
(37320*3.3V)/(2^16) = 1.879V

I would note that I think you may be measuring the wrong channel. A control byte of 83 reads out a differential result from CH0 - CH1. I thought you had wanted to measure a single-ended measurement from AIN0 to COM. Verify that the input is correctly measuring the 1.5V that you're supplying.

Also, you mentioned that you added some delay between the write and receive, and now you're getting different results. I had thought about mentioning that, but I thought he critical time would be tacq, which is 1.5us, even on lower supply. When I looked at your last post, I thought this was easily met (starting on the falling edge of the 5th DCLK byte to the falling edge of the 8th DCLK, which you showed is about 3us in your first post). Just the same, I'd look through all the timing again.


Joseph Wu