• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 46 subscribers
  • Views 728 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.

ADS8363 always measures zero

Sascha Koch
Prodigy 50 points
Other Parts Discussed in Thread: ADS8363

When I trigger a measurement with my ADS8363 I always get 0 as a result. I can see BUSY going HIGH and after 18 CLK cycles going low but with the following read-out cycle there is no reacton on the SDOA line. When I try to read out some registers everything works fine and I get the correct answers, so something must be wrong but I can't figure out what?

Thanks for your help so far.

Sascha!

EDIT:

Short explanation of my setup: I use a Microcontroller with SPI to communicate with the ads8363. To trigger the measurement I set the CONVST pin HIGH for a short time, then the BUSY pin goes HIGH. Afterwards I start the CLK and after 18 CLK cycles the BUSY pin goes LOW again. Then I set the RD pin HIGH let the CLK run for 8 cycles, set the RD to LOW and then let teh CLK run for 16 cycles. I know it doesn't really match the timing diagram but It works fine with register read out operations? 

EDIT2:

I also have to add, I'm not using those 20 CLKs per cycle but 24, cause my SPI always sends 8 bit. But as I mentioned, even with 24 CLKs its no problem to write and read the registers (except the config-register, but I think it's just a matter of time till I manage to read it out correctly, too)

  • 0
    TI__Guru**** 180961 points

    Hi Sascha,

    Is the /CS pin of the ADS8363 low when you apply the RD and SCLK signals?  Can you possibly send along a screen capture from an O-Scope or Logic Analyzer?

  • 0 in reply to Tom Hendrick
    Prodigy 50 points

    Hi Tom,

    yes the CS pin is low. It'll be hard to send a screenshot from the O-Scope but I found additional Info for you: First of all the ADS8363 was soldered very hot (the guy who solders the devices worked with the wrong heat settings). Hot enough to achieve real damage to my board. I checked all wires and connections and evereything was fine so far. I thought the ADS8363 was fine too because I could read and write to the registers. After a while I recognized, that at a random time/after random read-cycles the config-register was shifted 2 bit to left (to the MSB). It stayed there for a random time/read-cycles and shifted back again to its original position. Even if I wrote new data in it the data was shifted 2 bits left. A power reset could solve the problem as well as enough time or read/write cycles. The whole shift thing appears totally random as far as I can say. 

    Do you know a little bit about the internal construction of the ADS8363? The area that was soldered to hot was in the corner where the analog input pins are, maybe the ADC sits there as well as the configregister and they got damaged? Or do you have another explanation? All the other 4 registers don't show this problem, they work fine all the time. Even the 10bit DACs are ok.

  • 0 in reply to Sascha Koch
    TI__Guru**** 180961 points

    Hi Sascha,

    I suppose it's possible that you damaged the ADC, you can try to remove/replace the device on your board.  Bit shifting may be an issue with your SPI interface and where you begin to interpret the MSB of the output data.  You might check the reference voltage as well.  By default, the reference is turned off, if you are configuring the device to use the internal reference, you have to enable them in the REFDAC1 and REFDAC2 registers.

  • 0 in reply to Tom Hendrick
    Prodigy 50 points

    Hi Tom,

    the REFDAC1/2 worked fine, I could set the registers, read them out and I could measure the right voltage at the REFIO pins. Anyway I replaced the ADS8363 with another, new one. This time everything was soldered at the right temperature. Now with the new ADS8363 all the registers work fine, no bit shift occurs. However, I'm still not able to get any measurement results. Short description of the communication:

    CS pin is setted LOW. CLK is idle (LOW), CONVST and RD pin are setted HIGH, immediately BUSY pin goes HIGH, too (CLK is still idle). CONVST pin is setted LOW, CLK is startet for 8 CLK cycles (then idle again). RD pin is setted LOW. CLK is started again for 24 CLK cycles. After 10 CLK cycles BUSY goes LOW (8 CLKs +10 CLKs = 18 CLKs everything as expected). After the 24 CLKs the CS pin is setted HIGH again. BUT: The wohle time the SDOA pin stays at LOW. After the CS pin going HIGH again I can see a slight rise in the SDOA voltage (maybe the transition of SDOA from OUT to TRISTATE?)

    The read and write acces to the registers are done the same way (RD HIGH for 8 CLKs and then the SDOA pin starts talking). Can you give me any advice? I'm kind of at my wits' end...

    Thanks!

    EDIT: 

    Good news, I managed to get some results! I think the RD bit was HIGH too ling with it's 8 CLKs, I figured it out how to let it be HIGH for only 2 CLKs, though it's kinda cheating but the O-scope nearly fits the timing diagram. 

    Do you know how many cycles RD can stay HIGH that it's still working?

  • 0
    TI__Guru**** 180961 points

    Hi Sascha,

    I had a feeling there might be an issue with the way you implemented the RD signal.  Technically, RD should only last for 1 SCLK cycle - see the Timing Characteristics table on page 11, it's the t3 entry.  This can be really difficult to do using a standard SPI process since there are typically no GPIO pins that are synchronous to the serial clock.  You could try toggling a GPIO for CONVST+RD and 'bit-bang' the clock such that you get a falling transition while the combined RD+CONVST are high.  From there, enable the SPI functions and read out the conversion results - I'm not sure how much latency that's going to add to your system though.  A flip-flop might also be used as a means to latch the CONVST pulse and then use the output to drive RD so that it can be 'clocked' through with the SPI transfer.