Because of the holidays, TI E2E™ design support forum responses will be delayed from Dec. 25 through Jan. 2. Thank you for your patience.

  • State Resolved
  • Locked Locked
  • Replies 19 replies
  • Answers 5 answers
  • Subscribers 46 subscribers
  • Views 3110 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.

ADS1015 I2C-NO ACK

Bert Brundage
Prodigy 100 points
Other Parts Discussed in Thread: ADS1015, PCF8574, ADS1115

I am currently evaluating the ADS1015 but have been unable to receive an ACK on the I2C bus when sending the address byte 90h.

I am communicating with the ADS1015 using the NXP PCA9564 which communicates just fine with other ADC (such as the PCF8591) using I2C

I have tried various speeds (now set at 59khz)

ADDR pin is grounded, 3.3v to VDD, SDA and SCL to I2C bus with all other pins floating.

I have tried various pull-up values on SCL and SDA (now at 10K)

I currently have just one ADS1015 connected to the I2C bus going to the PCA9564

I am seeing from search results that there is a timing issue with the ADS1015 when used with some devices.

Do I need to adjust the pull-up resistors or take some other action (such as a I2C SMBus Accelerator)?

Is the ADS1015 more sensitive to power supply noise than other devices (with regard to I2C)? I have tried additional filtering.

  • 0
    TI__Guru* 94285 points

    Bert,


    Based on your description, you should be ok in the setup. With 10k pullups, and a 3.3V digital supply, everything should be work. You shouldn't need a buffer or accelerator in most applications and the device should be moderately tolerant to supply noise.

    Can you provide a oscilloscope photo for the communications? I would try a readout of registers and see what, if any response the device has. A logic analyzer could help to debug this as well.

    I'm not aware of any timing issues, but I can check on that. Are you referencing a particular post? If you are, paste a link back as a reply.

    Also, can you provide a schematic (even partial schematic) for your circuit? It might help in the debug.


    Joseph Wu

  • 0 in reply to Joseph Wu
    Prodigy 100 points
    Joseph,

    Thank you for your fast response.

    I am using the same connections as shown on page 8 of the ADS1015 data sheet.

    The PCA9564 status register is returning a 20h (SLA+W transmitted-no ack)
    The PCA9564 returns an 18h when communicating with a PCF8591 (this adc works fine)

    The post (about timing) that I saw was on the TI site for ADS1015 reviews:
    www.ti.com/.../ADS1015;tisearch=Search-EN-Everything

    I would have to track down a scope since I generally don't have to troubleshoot this far.

    A data probe shows the correct levels for SDA and SLA as well as data on the SDA line (as well as working just fine with other I2C devices).

    Is the ADS1015 more sensitive to heat than other devices? I have tried (3) ADS1015 now, using great care not to over heat when I solder. I am however bending pins 2,9,4 and 7 up to provide better access.

    Since I am only using 3 inch conductors on the SDA and SCL lines and the ADS1015 is the only slave, it would seem that the problem is much more basic. Do you know if the ADS1015 has been used with the PCA9564 without additional corrective action?

    Bert Brundage
  • 0 in reply to Bert Brundage
    TI__Guru* 94285 points
    Bert,


    I'm not sure what the timing issue is based on the review but I will check to see if there's been any other comments from others designs. I don't think the ADS1015 is any more sensitive to heat than other devices. I've used these and soldered them without having any problems. Also, I don't know of any designs using the PCA9564. I've never used the part, so I can't really comment on what problems there might be.

    I would definitely try to get a scope to look at the communication signals. Post anything you get when you're ready.

    I don't like the idea of bending the pins. I'd solder some extra wires to the pins instead. Physically bending pins up worries me that you could break one off.

    One thing I noticed was that you note that the address is 90h. For the 7-bit I2C address, people will left-justify or right-justify the address. Have you tried using the right-justified address of 48h? I'm not sure how you have your code implemented, but it might be something associated with that.


    Joseph Wu
  • 0 in reply to Joseph Wu
    Prodigy 100 points
    Joseph,

    Does TI have a proto board for the ADS1015 with the ADS1015 already soldered?

    The 90h that I am sending to the ADS1015 is 48h with the LS bit set to write 10010000 is this correct?

    When I send the single byte (90h) to the ADS1015 should not it respond with an ACK? (like the PCF8591 ADC)
    The PCA9564 is returning an 8h indicating that a start condition has been transmitted before I send the address byte to the ADS1015.

    The PCF8591 has the same slave address if all the address pins are grounded. 90h is what I send to address the PCF8591 slave (of course I don't have both the ADS1015 and the PCF8591 connected at the same time) and I get back the correct 18h (not 20h)

    I will try another ADS1015 without bending pins.

    Thanks for all your help!

    Bert Brundage
  • 0 in reply to Bert Brundage
    Prodigy 100 points
    Hello Joseph,

    I have tried 2 more ADS1015 without bending any pins. I soldered to a proto board using lots of water based flux and very little heat (cleaned well and dried). Still no-ack.

    If I send a 48h, the PCA9564 still returns a 20h (no-ack). Sending a 48h would remove the R/W bit so I don't think this would be correct. Keep in mind that I have yet to start on software. I am just setting GPIO lines to check all the hardware and make sure I get an ACK from the I2C device. Since I am able to communicate just fine with the PCF8591 ADC which I have set to the same slave address, it appears to me that I have a hardware issue.

    Does TI offer any paid support, where I could have a TI engineer look into the problem a little deeper?

    Bert Brundage
  • 0 in reply to Bert Brundage
    TI__Guru* 94285 points
    Bert,


    You could get an evaluation module from TI, which would be an evaluation board for about $49. A performance evaluation kit comes for about $149 which includes the motherboard and software to run the device.

    Also, I've seen on Adafruit that they sell a small board for the ADS1015 for about $10. They are not affiliated with TI and I didn't know about them until a recent google search.

    My comment about the 48h address was just to make sure that your code didn't have a problem interpreting the address. However, it looks like you're using the PCF8591 address to test that the PCA9564 is correctly writing the address. That should generate the ACK. Again, I would find an oscilloscope to verify that the correct signals are coming out. While you do have something that responds to the same address, it still helps to see that the signals make it to the device correctly.

    Do you have a schematic that you can send? or are you just using a blank board and air-wiring it to your controller.

    Sorry - TI does not offer any paid support, but if you keep asking questions here, I'll keep responding to them.


    Joseph Wu
  • 0 in reply to Joseph Wu
    Prodigy 100 points
    Joseph,

    Here is the schematic:
    www.ti.com/.../ads1015-q1.pdf (on page 8)

    I am just air wiring from the proto board (with the ADS1015) to the PCA9564. The length is about 3 inches. I am only running 4 lines (SDA, SCL, 3.3V and ground) to the PCF9564. The ADS1015 is the only device connected. Can this cause any problems?

    The proto board has the (2) 10K pull-up resistors (on SDA and SCL) along with a 10uf and a .1uf cap across the power input to the ADS1015.
    The ADDR pin is grounded.

    I made a mistake earlier by calling SCL, SLA... sorry.

    Thanks,

    Bert Brundage
  • 0 in reply to Bert Brundage
    Prodigy 100 points
    Hi Joseph,

    I forgot to ask. Does TI make a device similar to the PCA9564 (parallel bus to I2C controller)?
  • 0 in reply to Bert Brundage
    TI__Guru* 94285 points
    Bert,


    I don't think that 4 inches of wire is going to make much of a difference. As long as you've tapped the correct four wires, and that there are pull-ups on the lines, it should have worked.

    I'm not aware of any devices similar to the PCA9564. We do make a bus extender like the PCF8574 that can make some basic communications, but I've never used it and I'm certainly not an expert in I2C interface devices.


    Joseph Wu
  • 0 in reply to Joseph Wu
    Prodigy 100 points
    Hi Joseph,

    I have a scope on the way but I won't see it until next week. I'll send the results as soon as it gets here.

    In the event that the problem is a timing issue (as reported by the engineer in Lexington MA in his review), what is the recommended fix?

    He is reporting that a delay into SDA solves the problem. Apparently an additional hardware device is needed. Please refer to the review shown below. Is it possible to get in contact with this engineer?

    Thanks,
    Bert Brundage

    Rating:
    3 out of 5
    Experience: > 20 yrs
    Design Phase: Prototype
    Location: Lexington, MA

    Tiny housekeeper does the job...mostly Posted on: May 31, 2013

    Pros: small, many channels
    Cons: sda address might not work for you, uses same addresses as tmp10x family

    " This device is one of the smallest four channel ADC converters I've found. It's perfect for monitoring power supply voltages. I liked it so much I put it everywhere before I found its "skeleton in the closet": The "connect to SDA" address did not work as advertised. It needed a little different timing that my micro couldn't support. The datasheet should be corrected. If you delay the SDA going into the address pin you're ok, but that sort of defeats the point of "small." So 3 stars. Fix SDA and you get back to 5. "
  • 0 in reply to Bert Brundage
    TI__Guru* 94285 points
    Bert,


    I don't have any visibility on comments on product pages so I can't contact him (or her) and don't know what issue he's talking about. I'm not aware of anything about delaying SDA for this part and I would imagine that if there were a necessary delay, it would have come up in the forums already.


    Joseph Wu
  • 0 in reply to Bert Brundage
    TI__Guru* 94285 points
    Bert,


    How do you have the ADDR pin set up? Is it connected to GND? or is it being driven actively?

    If I recall correctly, the ADS1015 samples the pin at startup and then retains the address. It does not continuously monitor the address pin, so it's less likely to work if being driven actively (setting the address after the startup).


    Joseph Wu
  • 0 in reply to Joseph Wu
    TI__Guru* 94285 points

    Bert,

    I was wrong about the last comment. The address byte may have an active reading of ADDR to determine the address. Sorry about that.

    That being said, I did throw together a board just to take a quick look. I used the EVM board (without the MMB3 motherboard) and connected it up to a Total Phase Aardvark just to read it out. This is just a simple USB to I2C translator.

    First I connected up the Aardvark to the EVM board. I have ground, power (through the Aardvark +5V target power), SDA, and SCL connected.


    I was able then to read back the configuration register. First there is a write to address 0x48h with 01h which indicates the pointer for the configuration register. Then there is a read of two bytes with the same address.



    Looking at the scope for each transaction you can see how the bytes are formed. For the write for the pointer first, then for the read for the configuration register.

    One other thing that is important is to check the formation of the start condition for I2C. I'm curious if this is what the commenter was referring to about the delay for SDA (in which case he really meant SCL for the start condition or delay for SDA for a stop condition). Either way, I show a close-up below:

    In all the photos, SDA is on top, while SCL is on bottom.

    Joseph Wu

  • 0 in reply to Joseph Wu
    Prodigy 100 points
    Hi Joseph,

    I have the ADDR pin connected directly to ground.

    I am setting the address of the other I2C slave ADCs ( that I am testing), to this same slave address (1001000+Wbit). So far all have responded with an ACK when I send a 90h byte except for the ADS1015 and the ADS1115. I am able to set all the control registers and read analog inputs just fine with all the other ADCs (such as the PCF8591). Please note that I am testing the ADCs one at a time, not on the same I2C bus.

    Please confirm... should the ADS1015 or the ADS1115 send an ACK when the single address byte of 90h is transmitted on the I2C bus (after start condition) or are additional data bytes needed after the 90h before the ADS1015 or ADS1115 will ACK?
    From what I understand, an ACK is supposed to be sent by the slave after receiving it's single byte slave address.

    Thanks,

    Bert Brundage
  • 0 in reply to Bert Brundage
    TI__Guru* 94285 points
    Bert,


    If you look at the scope shots above, you can see the ADS1015 ACK after the address in each of the two photos. It's a little easier to see in the first photo, where the ADS1015 pulls down on SDA, and then lets go after the SCL line is released.


    Joseph Wu
  • 0 in reply to Joseph Wu
    Prodigy 100 points
    Hi Joseph,

    Since my scope has not yet arrived, I put the ADS1015 and ADS1115 on hold until it gets here.

    I'll send you the scope shots in a few days after the scope gets here.
    I am in the process of evaluating 15 different ADCs, ranging from 8 bit to 16 bit. So far all have returned an ACK after receiving their slave address except for the ADS1015 and ADS1115 so I still don't know what the issue is.

    Hopefully the scope shots will shed some light.

    Thanks,

    Bert Brundage
  • 0 in reply to Bert Brundage
    TI__Guru* 94285 points
    Bert,


    I'll look forward to seeing the scope shots.

    If you do try debugging this earlier, I can think of only a few things that could cause this issue:
    1. Bad power/ground connection for the board.
    2. Swapped SCL/SDA connection or bad connection to either I2C line.
    3. Not enough hold time for the I2C bus start condition - >600ns from SDA going low to SCL going low. There are a few timing problems that are similar to that problem, and I'd check those too.

    When you get the scope, you'll be able to check 3.


    Joseph Wu
  • 0 in reply to Joseph Wu
    Prodigy 100 points
    Hello Joseph,

    After testing (8) other 3.3v ADC I2C devices (all of which returned an ACK correctly), I started testing the 5v ADC devices and decided to re-check the ADS1015 and ADS1115 with 5 volts supplied to VDD.

    Since both the ADS1015 and ADS1115 are suppose to operate at both 3.3v and 5v , I thought I would see if they would return an ACK with 5v... and both have. I have now been able to test these two devices with 5 volts applied to VDD.

    My guess is that for some reason these two devices are more sensitive to noise on the SCL and SDA lines at 3.3 volts, preventing the ACK.

    Thanks again for your assistance.

    Bert Brundage
  • 0 in reply to Bert Brundage
    TI__Guru* 94285 points

    Bert,


    I'm glad you were able to find a solution. If you have any other questions, feel free to post back to the forum
    .

    Joseph Wu