• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 46 subscribers
  • Views 935 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

ADS1158 - Intermittent Correct data - DRDY pin stays Low!

Larry West
Prodigy 60 points
Other Parts Discussed in Thread: ADS1158, ADS7950

Of 1000 analog reads from the ADS1158, only ~200 are correct. If I check the New bit of the Status byte, the correct readings always occur for a New reading, and error readings are when the New bit is not set. (Note I read every time the DRDY line goes low, but it stays low so I read too often which could explain things here. See next problem.)

I also have a problem in that the DRDY line always stays low. After a read, I can see on a scope that it goes from ~0.2 to ~0.5V after a read at the point expected from the data sheet for it to go high. But it never actually goes to a logic high - ever. I looked for shorts many times in many ways, and built a new board. But I still see the same behavior.

Finally, I set the Start pin through GPIO7. I find GPIO7 is set only about 30% of the time I write the command! Again, I checked for shorts and outputs many times. Each of my GPIO are connected to ground through a 10K pull down resistor.

Other information:

  • Digital supply is 3.3V; Analog supply is 5.0V, Vref = 2.5V
  • I use a data clock source from a FPGA around 12.5 MHz
  • I read a single ended analog channel 0 by setting MUXSGO to 0x01, and the other MUXSG1 set to 0.
  • I read using Direct Channel Read (register format) (I send 0x30 command, including MUX bit)

Anyone have clues? Could this be a communication prbblem on the reading and GPIO set? Then why does DRDY stay low, aways indicating data is available?

Thanks

 

  • 0
    TI__Mastermind 43915 points

    Larry,

    It sounds like a communication issue.

    Can you send us a schematic and some scope shots of what you are seeing. I would like to see the SCLK, DRDY, Din and Dout signals in order to see what you are actually writing to the device and your clocking relationship. Also, If you could include the GPIO7/START signal on the plot so I can see if the GPIO is rising when you are writing.  

    Is there a reason you are using GPIO7 to control the START pin instead of simply using the Pulse Convert Command?

    Regards,

    Tony Calabria

  • 0 in reply to Tony Calabria
    Prodigy 60 points

    Thanks for helping. I'll need to solder some wires onto the new board to get new scope traces. That may take until tomorrow at this point. Where do I send the files?

     I don't see a "START" command on this chip, just "Pulse Convert" which had to be done every conversion and doubles the interface load for no reason, since I want to be constantly scanning anyway. We monitor the DRDY with our FPGA embedded processor, and call a (32-bit) SPI read command when DRDY goes low.

    I set the GPIO7/START signal only once at the beginning of our embeded processor program, as part of the chip initialization. We could have hard wired the START pin high but figured the extra flexibilty using the GPIO7 might be useful some day. 

     I set the delays and integration (DRATE=00b, DLY=110b) in the CONFIG1 register so I get a reading approximately every 0.4 ms during a scan. Oddly, the readings with a New bit set seems to be getting a much faster rate, since 20% of the readings are coming back as new, at a full speed (no pauses since DRDY is always low) data rate of approximately 12.5 MHz clock / 32 bit data.

    According to the data sheets, the DRDY pin should reset back high on the first clock, and for a MegaOhm scope input impedance, I see a definite DRDY transition to a higher level only at that point, but only a few tenths of a volt, not a logic high.

    Furthermore, if I put my FPGA program into a loop to wait for the DRDY to go high after a read, it stalls forever. The DRDY just never goes to full logic high. What possible conditions on the chip can cause DRDY to stay low while still converting?

    Thanks

  • 0 in reply to Larry West
    TI__Mastermind 43915 points

    Larry,

    I apologize, I meant use the Pulse Convert Command. I was under the impression you were using the GPIO7 pin to control the START pin to control individual conversions.

    I need to see the scope pictures to fully understand what is going on. Email me the pictures along with the schematic. My email is dataconvapps'at'list.ti.com

     

    Regards,

    Tony

     

  • 0 in reply to Tony Calabria
    Prodigy 60 points

    Tony,

       Friday afternoon, I sent you some scope traces.  Perhaps you can see something I don't in timing or see another issue.

       My time spent working this chip is becoming larger than all ten of my other chip interfaces, combined. By comparison, making an SPI interface of the ADS7950 chip only took me 2 hours in total (from opening the data sheet, to reprogramming the FPGA and SPI configuration, and finally writing the header files and drivers). In contrast, I've been working on this ADS1158 off and on for almost two months now, with different clocking, rebuild of boards, scope checks, trying different grounding schemes,...

      The problem may be something simple, but I just can't seem to find it.  I'm tempted to rebuild the board with completely different chip if we can't figure this out soon.

      One big clue to the real issue: Why would the /DRDY signal stay low all the time? What problems could cause that?

    Thanks,

    Larry

  • 0 in reply to Larry West
    TI__Mastermind 43915 points

    This specific issue was solved over the phone. To sum up - 

    The configuration of the micro-controller had the /DRDY pin held low at all times. 

    We discovered this by looking at the initial state of the /DRDY pin after power up. The ADS1158 pulls the /DRDY pin high after start up.

    -Tony 

  • 0 in reply to Tony Calabria
    Prodigy 60 points

    Yes, that /DRDY issue was solved and traced to a fault on our side. Thanks Tony!

    Sorry I didn't respond yet. I seem to still have a problem with intermittent data errors before I can claim full success. After some investigation, I think it's because on my SPI interface, my CS goes low for 1 clock cycle before the data clock starts. The ADS1158 data sheet says it needs 2.5 clock cycles. I need to hard code a different timing than the standard Xilinx SPI IP core to verify. I'll post back once that's done.