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.

OPT3001: MSB truncated when reading data

Part Number: OPT3001
Other Parts Discussed in Thread: ADS1115,

Hi, I noticed my device always returns read back data with the MSB = 0, whether it's the config, conversion data, or threshold registers. My bus clock is 400kHz.

I first noticed this problem when I was reading from a bright light source and noticed the reported lux dropped off for exponent values > 7. For a simple test, I power the device on, write A5B6h to Low Limit register 02h, and then I do a read and get 25B6h. The device shares the bus with an ADS1115 and that works fine; the read back data from the threshold and config registers always matches the data written and the conversion data is always correct. I am using the same clock rate for all devices on the bus.

Everything described above has been verified with an oscilloscope.

  • Hi Paul,

    When you say "the read back data from the threshold and config registers always matches the data written and the conversion data is always correct" is this true when the MSB for these registers is 1?

    Also what is the config register value you are using in this test?

    Best,

    Alex
  • Hi Alex,

    That sentence refers to my testing of the ADS1115. Yes, I write all 1s to those registers and they read back correctly from the ADS1115.

    For the OPT3001 my config reg value is C210h. Initially I read back 40B0h (C with MSB truncated = 4), indicating my conversion is ready and the device is back to shutdown mode, then I read 4010h when the conversion ready bit is set low.

    Paul
  • Here are a couple scope screenshots showing a write value of FFFFh to register 02h (low limit) and the following read back. This has been confirmed on 3 different boards. Additionally I have read the correct manufacturer ID and device ID, so I know I am talking to the correct device.

  • Hi Paul,

    Thanks for all this info. I have not seen this issue before and it does seem quite strange. I'll take some more time to look at your scope shots and look into this. Have you tried this on multiple devices? When you say "confirmed on 3 different boards" this means you've tested on 3 versions of the same board with 3 different OPT3001?

    Do you happen to have an EVM for OPT3001 that you can test as well? I am trying to narrow down on what is needed to recreate the issue here.

    Best,

    Alex
  • Thanks Alex. Each board has one OPT3001 on it and they are all showing the same problem. I also tried lowering the I2C clock freq to 300kHz and that did nothing. I may have an eval board kicking around that I can play around with in the meantime.

    Thanks!

    Paul

  • Hi, got more data! I've discovered that the 50 or so of these devices I'm using on instruments in the lab all have this issue and have always had this issue.

    Today I wanted to rule out any timing issues by decreasing the clock speed to 100kHz and lowering the I2C pullups to 511 Ohms to ensure rise times well with spec (didn't think rise times were a big deal with I2C but figured I'd rule it out anyway...). So with those changes I still have the same issue. But the added bonus is by probing close to the OPT3001 I can see if it's the master or the OPT3001 pulling the SDA line low. In the scope captures below the lower SDA signal means the OPT3001 is pulling down on it. In the second capture, which is the read back, you can see it looks like the OPT3001 is the one holding the SDA low during the transmission of the MSB during read back. I am all out of ideas at this point and could use some help. Thanks!

  • Hi Paul,

    I have not been able to replicate this problem on our EVM so far. Would you be able to provide the schematic of the board you are seeing this issue on? When you say the issue happens on 50 devices are they all using the same schematic or are these in different designs? Also did you manage to find an EVM for this chip and try with that? Narrowing down further will help me know what exactly to test on my end.

    Best,

    Alex
  • Hi Alex,

    There's not much to the schematic; just 100nF decoupling cap on the 3.3V power and the I2C connections. Please see the image below. Additionally I probed the 3.3V across the decoupling cap with a short ground lead during read back and there's no measurable droop or glitches visible at 50mV per division.

    I did find an eval board and confirmed it works fine and does not show this problem.  I understand if the eval board works fine and all the devices on my boards are misbehaving then it's my problem, but other devices on the same I2C bus work fine and I can't see a single thing that I'm doing wrong. Every other I2C device I've used in a design usually works fine with hardly any issues but this is one of the more puzzling problems I've come across.  

    Thanks,

    Paul

  • Hi Paul,

    Do you know how I can replicate this problem? Did you try the EVM board on the same bus as the other devices or was it separate?

    Some more questions:
    From the schematic I was hoping to get an idea of what is on the bus and the pull up resistors. Are we able to say that the problem only happens on this bus with all the other devices? If so is it possible for you to start disconnecting the other devices until we get to a working state?

    Best,

    Alex
  • Hi Alex,

    The pullup resistors are 1.6k and as I mentioned I reduced them to 511 to rule out any possible issues due to slow rise times. I suppose I could try pulling other devices off but I'm not seeing bad I2C waveforms. The other devices are 2 DAC121C085s and 1 ADS1115. 

    Thanks,

    Paul

  • Hi Paul,

    Can we please move this conversation to email and I will close this thread? Please send me an email: bhandari at ti.com

    I have a plan to test multiple OPT3001 on the bus but will need some time to run this test. Please let me know if there is any result from removing the other devices off the bus to try to isolate if it was a specific one causing the problem. This will help us if multiple OPT3001 test works okay and we need to test with another specific device that you are using to replicate the problem.

    Best,

    Alex