This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

ADS1248 Returns only zero valued samples

Other Parts Discussed in Thread: ADS1248, ADS1258

I have an ADS1248 configured as shown in the attached schematic.  I have three boards with this circuit and all them operate cleanly, as in: I can read and write to the ADS1248 registers and I see the Data Ready signal pinging like clockwork, but when I read the samples all I get back are zeros (DOUT is flat as seen on the scope).  I have tried every method of sampling (Autocycling and Pulsed convert) and reading (RDATA, RDATAC, 24 SCLK pulses) and everything I try returns zeros on all channels, even when I apply offset and/or bias to them.  The circuit designer has chosen to use as references the ground level and the positive voltage supply (2.8 volts), with digital zero corresponding to 1.4 volts.  In this case with zero volts on the inputs, I should get a sample value of a large negative number.. even when I put 1 or 2 volts on the inputs I still see zero samples.  Since this is consistent across all three boards I am left with two probably answers: either the software I wrote is not right (not likely since I've gone over with a fine tooth comb about 50 times and verified all inputs and outputs are working correctly with a scope).. OR there is something inherently wrong with the design...  I am particularly curious about our designers choice for VREFOUT and REFP1 .. it looks fishy.. Does anybody see anything wrong with this circuit?

  • Eric,


    I don't see anything in the schematic that could be a problem. I'll discuss a couple of things it could be and some other things that you can check.

    I can think of only a few things that might do what you are seeing. First, If START or /RESET are pulled low, you may not get any data out. However, since you're still getting the /DRDY pulses, I'd say that isn't the likely problem. Another problem could be that you're missing the /CS pull low during the read. One last possibility would be that your reference is at 0V. The output may be vary, but it's likely stuck at either full scale. I'd also like to know if you're in RDATAC mode (default) or if you've issued an SDATAC command.

    There are a few things you could try to help debug this problem. I would first read back all the registers and report them back. I just want to make sure that you're in the proper configuration that you expect. I would definitely include the Full-Scale Calibration Register just in case. I want to make sure that the it's set to a reasonable value. When you have that, post back to the forum.

    When you read back the device, I also want to see the scope shot of the data transaction (for both a read and a write). You'll need a four channel oscilloscope, capturing /CS, SCLK, DIN, and DOUT and it would be nice to see the first several bytes of the transaction to make sure the waveforms are moderately clean. If you're in RDATAC mode, you should be able to see some of the bytes of the data transaction as well.

    Once you've got that scope photo, try issuing a RDATA command to get the data. Even if you are in SDATAC mode, the DOUT register should refresh once it gets the command and you'll be able to read the data.

    If you're still not getting the response from the device. Try a slightly different configuration. I'm not sure what you're using, but try a different data rate, try a different PGA gain, and try using the on-board temperature sensor to read back.

    I'll wait for you to post back with some scope shots and responses to questions.


    Joseph Wu

  • Eric,


    One more clarification. For your output data, do you get all 0s for your data? Or do you get values near 0V? Some of my response addresses possible causes of the first case.


    Joseph Wu
  • Joseph,

    You nailed it.  In your first note you suggested read back of the Full Scale Calibration registers.  That got me to thinking...  some weeks ago when setting up the ADC configuration logic I had most of the registers figured out, but when I got to the "Calibration" section in the Data Sheet, I stupidly thought, "I'll just get the first 4 registers working and come back for the rest later..and anyway it's just 'calibration stuff' so I can calibrate it after I see some data."  One thing led to another and it turned out we had some schematic errors that needed to get resolved before I could even load the registers.  In the mean time I had set the Offset Calibration and Full Scale Calibration to ZERO!  thinking that was the most logical default.  (If only I had read the data sheet..)

    So to make a long story short... my Full Scale Calibration being set to zero is what caused my samples to all be EXACTLY zero. 

    When I set the register correctly according to the data sheet I started seeing non-zero samples.  Next step is to see some real signals coming in..  Finally the fun part is here! (I hope).  

    Thanks so much for the help.  You guys at TI are greatest... your documentation is top notch and every time I use this forum I have never failed to get a right answer within about 24 hours or less.  I appreciate it even more after having some not so great experience with another supplier.

    Great stuff.

    Thanks,

    eric

  • Eric,


    Thanks for the nice comments!


    With the data coming out all zeros, there are only a few different things that it could be. I figured that it was either a communications error or something wrong with the full-scale calibration register. I'm glad that you were able to solve the problem.


    If you have any other questions, don't hesitate to post back.

    Joseph Wu

  • It works great now when powered via USB 3.3V FTDI cable, but when I switch to battery power (single lithium coin cell, 3.3V) it fails again with a similar symptom... the software outputs all zeros again... this could be that we are not reading samples at all (and the software buffer is initialized to zeros...) or we are reading samples but the ADC is outputing zeros again.  I'm guessing it is the former.  I'll put the scope on it and check the logic levels.  I suspect there may be an issue with the logic levels between the master and slave on the SPI interface when running on battery power.  Even on paper we are running close to the margin on the ADS1258 logic high voltage threshold, and maybe on battery power the master is not driving the signals high enough to be recognized by the ADC.  We have a voltage booster on the SCLK and DIN lines, but not the others, so I guess there could be a problem with maybe the RESET or the START signals.

    After I see what's going on with the scope I'll let you know if I have any more questions.

    Thanks again,

    Eric

  • Eric,


    Along with the comments I made yesterday, I'd also check that there's a common ground through everything from the master to the device, including the voltage booster on SCLK and DIN. There have been plenty of times when I missed the ground from master to slave and I got either bad or no data.


    Joseph Wu
  • I found the problem and it was a rather interesting find...

    The voltage regulator was set for 2.2V for powering the master.  With this voltage, the GPIO logic high output level is 1.8 volts according to the master's datasheet. This is too low to drive the ADS1248 which in our circuit is powered at 2.8V and therefore wants a minimum of 1.96 volts for a logic high signal.

    When the master was connected to the laptop through the FTDI USB 3.3V programming cable, it somehow gave a boost to the GPIO logic level so instead of 1.8 volts for a high level the scope showed 2.0 volts.   Just high enough to operate the ADC. Without this voltage boost the ADS1248 it would never see the high signal on the RESET pin, it would never complete the device reset and begin operating.  The symptom was zeros in the software sample buffer in the master.

    The root cause was an incorrect schematic (our design was flawed)... but the impact was compounded by the undocumented 'feature' of the master which boosted the GPIO output voltage when connected to the programming cable.  Fortunately for us, our circuit designer was on vacation last week and he missed his deadline to send the layout for production.  Also fortunate that I switched to testing under battery power when I did.  Now he can correct the voltage coming from the regulator (2.4V instead of 2.2V) to solve the problem and this change will be in the layout that goes to production this week.