• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 46 subscribers
  • Views 953 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Original question:

ADS1148-Q1: Issue in obtaining data

ADS1148: Issue in obtaining data

Cliff Shak
Prodigy 30 points
Part Number: ADS1148
Other Parts Discussed in Thread: TPS3836

I had a very similar problem to Amitech in trying to read from the SPI interface for the ADS1148.  All I got back was zeros on DOUT when trying to do a simple ID register read.  I couldn't figure out what was wrong because all the timings looked good.  I read the datasheet over and over and couldn't find anything out of place.  I was beginning to think my DOUT signal was broken.  But using the suggestions from Joseph Wu, I found the problem:  The T rhsc specification on the data sheet is wrong or the internal clock is not running at 4 MHz..  This is the SERIAL INTERFACE COMMUNICATION AFTER RESET parameter.  On my board, instead of 0.6 mS, it appears to take about 210 mS before the SPI interface responds to commands.

I'm using an ADS1148EVM module connected to my own PIC microcontroller. I have a logic analyzer hooked up so could verify my PIC was sending the SPI signals per the datasheet.  I could see the /DRDY signal pulsing at a 5 Hz rate when I held START high starting about 0.5 S after reset.  Thanks to Joseph for pointing out that the ADS1148 defaults to continuous conversion mode after reset.  By delaying a data read until /DRDY went low, I finally saw the DOUT signal move from zero to one.  And adding register read commands after that finally convinced me that the SPI interface worked. 

  • 0
    TI__Guru* 95535 points

    Cliff,


    I'm glad that you were able to get things working. It sounds like you were able to logically debug the circuit.

    However, I'll have to look at the T rhsc spec a bit more. The length of 210ms is a very long time in comparison to the listed spec of 0.6ms. That would be a huge discrepancy. Did you include the time to complete the first conversion. At 5SPS, that would include a nominal time of 200ms. On top of that there would be a ±5% variation in the nominal clock frequency, which would get you to 210ms.

    Regardless, I can probably check to see where that 0.6ms number comes from. Thanks for your comment.


    Joseph Wu

  • 0 in reply to Joseph Wu
    Prodigy 30 points
    Yes, I saw the 200 mS conversion time and was wondering if that was the explanation for the delay I was seeing. But from your postings in other threads, a conversion in progress should not block an RREG command. Should it?

    My test program started 1 mS after I released a hardware reset. I sent continuous commands to read the ID register which has some 1 bits. I did not see any 1 bits on the DOUT line until about 210 mS after releasing reset. START line was held high.
  • 0 in reply to Cliff Shak
    TI__Guru* 95535 points
    Cliff,


    The RREG command shouldn't get blocked by the conversion, but the reset will reset the DOUT register from the last conversion. As soon as the reset is released (/RESET goes high) the transition should trigger a re-loading of the default settings of the device and that would take 16 modclks in the device (16*31.25us) which should be about 0.5us. I think 100us was added for variations in internal oscillator frequency. This is different than a reset that occurs when power is first applied (Power-on Reset) which adds on about 32ms before communication can be made with the device.

    After a normal reset, the device should release all registers, this would include the configuration registers, DOUT, and the digital filter accumulation.

    It may take some time, but I'll see if I can duplicate your test. I don't know if I can duplicate it exactly because it require some control for the /RESET pin, but I should be able to time the RESET command.


    Joseph Wu
  • 0 in reply to Joseph Wu
    TI__Guru* 95535 points
    Cliff,


    Just to let you know, I was able to read from the device almost immediately after a reset of the device. Note that my reset is from the command, and not as a toggle of the RESET pin.

    In my test I write to the device and set the MUX0 register to 03 (instead of keeping it as 01). Then I read back from the register to ensure that the write is has worked and 03 is retained in the register. I also read back all registers just to check that they are correct.

    Then I write 06 and read back from the registers all in one /CS cycle. From the time that the reset is sent to the time the read register is sent, is probably less than 20us. The short of it is that the 03 is reset back to the default of 01h. I believe that the reset returns the registers to default first before trying to re-write any registers based on any factory programmed values (which explains the 0.6ms limitation). Regardless, the register data appears as I expected immediately after the reset completes.

    Regardless, I don't know if I have a controller that could test the pin controlled reset case. For your setup, do you have a logic analyzer or oscilloscope to verify your timing? It might help to have the /RESET, DIN, DOUT, SCLK, and maybe /CS to verify the sequence of the reset and read.


    Joseph Wu
  • 0 in reply to Joseph Wu
    Prodigy 30 points

    I figured it out.  When I went to hook up the connections to replicate your test, I looked at the schematic more closely and noticed the hardware reset signal on J7.6 passes through a TPS3836 NanoPower Supervisory Circuit.  Looking up the datasheet, the IC can be wired for a 200 mS reset delay, which is what it is. Duh!

    So something to warn anyone working with the ADS1148EVM board about:  200 mS delay on the J7 reset line!!.

    Thanks for your time Joseph.

  • 0 in reply to Cliff Shak
    TI__Guru* 95535 points
    Cliff,


    I'm glad that you were able to find the solution. I'd focused too much on the internal operation of the device, and not on the schematic! Regardless, that was a good catch on your part.

    If you have any other questions on the device, please feel free to post back with another question.


    Joseph Wu