• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 32 subscribers
  • Views 1150 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.

TMP006 not responding to I2C bus requests at speed

Will Wasson
Prodigy 60 points
Other Parts Discussed in Thread: TMP006

Hello,

I have an application that uses 4 TMP006 sensors connected to an MSP430 Micro-controller.

The application works when I do slow "blind reads" of the temperature data.  By that I mean if I have a slow loop in my micro-controller code and manually force reads of temp data everything works correctly.  However, when I try to set the TMP006 to different conversion rates and then code the micro to read the data as fast as possible the TMP006 never changes values. 

Specifically, the micro code is entering a "while loop"  reading the DRDY bit in the configuration register waiting for it to change state signalling that a conversion is complete.  The DRDY bit never goes low and the loop continues forever.  The hardware pin for DRDY is left floating, and all 4 TMP006 devices have their DRDY pins shorted together, but this signal is not used at this time.

In developing this application I have seen similar behavior before, where continuous activity on the I2C bus seems to lock up the device.   Is this a known issue?

Again, if I run my application slowly and not try to maximize through put the system works correctly.

Thanks

  • 0
    TI__Genius 15760 points

    Hi Will,

    Thank you for using TI E2E forums. We have received your question, please allow me some time to contact the right people to assist you with TMP006 questions and we will get back to you.

    Mayrim

  • 0 in reply to Mayrim Verdejo
    TI__Expert 3370 points

    Hi Will,

    Can you describe the bus speeds and sample rates at which your systems works and the bus speeds and sample rates where it does not work.

    You also stated that you have sen this issue before - does that mean you have seen it with I2C devices other than the TMP006 or only the TMP006?

    Regards,

    Werner

  • 0 in reply to Werner Metz
    Prodigy 60 points
    Hello Werner,

    I'm using a MPS430 micro-controller from TI to talk to the TMP006.  It is using the standard rate of 400KHz that the MPS430 USCI operates at.  This should match the speed, set-up and hold times of the TMP006.

    Most of the interaction between the micro and the sensor are transaction based.  I have a user GUI that allows the user to request single measurements from each of the 4 sensor in the application.  This mode works correctly, that is the sensors respond with updating values at every request.

    Another mode of the GUI is to continuously read the sensors and update the GUI as quickly as possible.  I originally had a bunch of delays programmed into the micro code and was not attempting to synchronize with sensors.  This also worked somewhat as the sensors were updating the GUI values.  However, on examination of a datalog file I found that the values weren't updating at the rate that the sensors were supposedly set to.  It appeared that themicro was requesting data at a higher rate than the sensors were updating.

    At this point I hadn't tried to synchronize the micro and the sensors which appeared to be the issue with the datalog.  So I added a "while" loop before every sensor read operation that checks the DRDY bit in the configuration register.  This while loop is running at the micro full speed of 25MHz, I don't know what this translates to in I2C requests per second but I suspect it would be quite high.  The DRDY bit never gets set in this mode.  The micro is stuck in the while loop.  At first glance it appears that the sensor is so busy servicing I2C requests that it cannot perform an ADC conversion.  I don't know whats inside that TMP006 to make a better guess.

    In my first attempts to have the micro read the sensor, I only had a single sensor attached to the bread board.  When attempting to capture temperature data I saw the device get stuck and stop responding.  This was with the micro again running at speed requesting data from the TMP006.  I was having so many problems with getting the USB/Com port and the I2C, interfaces all working at the time that I just added some delays to get by.  That is what I meant when I said I had seen this problems before.

    I looks to me like the TMP006 cannot handle high I2C traffic and still do conversions.

    TI has a customer evaluation module and GUI that shows the TMP006 working correctly, that is the TMP006 is continuously updating that GUI at the correct conversion speed.  I don't know if the TI code is actually testing the DRDY bit in the configuration register or if they have just hard coded a delay in the code to allow the TMP006 time to do a conversion.  I do know that the DRDY device pin is not being used because it only goes to a LED on the eval board.  So either the TI code is much smarter than mine, or they have a delay built into their code.  I'm hoping that they are smarter than me :-)  But I could live with a hard delay also.

    Will

     
  • 0 in reply to Will Wasson
    TI__Expert 3370 points

    Hi Will,

    Is the serial bus always running at the 400KHz speed? Note that the TMP0006 max serial bus speed is 400KHz for fast and 3.4MHz for slow. Another possibility is that if you are running a fast loop, you may be issuing the next serial bus command before the first is finished. In that case the DRDY bit may not be getting set, so it never asserts.

    Below is a link to the SW used in the TMP006 MSP430 booster pack.

     

    http://software-dl.ti.com/msp430/msp430_public_sw/mcu/msp430/boosterpack/TMP006/latest/index_FDS.html

     

    It contains C Code  you can access  to operate the device and use as a starting point - or you can hard code the delay as you say.

    Regards,

    Werner

  • 0 in reply to Werner Metz
    Prodigy 60 points

    Hi Werner,

    I've looked at the "C" code and it appears that it is setting a timer/counter hardware delay to wake up the micro and then read the DRDY bit from the register.  So it looks to me like TI is hard coding a delay just like I am.


    Does this mean that the TMP006 isn't really capable of responding to fast continuous I2C data communication?
    I don't know.

    I have a working application with the delay, and TI has a working App with delays, so I don't expect anyone at TI
     to be running into the lab to verify if the part has a problem.

    Thanks!

  • 0 in reply to Will Wasson
    TI__Expert 3370 points

    Hi Will,

    The DRDY function definitely does work. We think it is a SW issue. Here are some suggestions to try

    Make sure the DRDY bit is enabled first (not the case in default), and then it goes high when the conversion is done so waiting for it to transition back to low requires a read of the local temp or the voltage reg, or a write to the config reg; only reading the config in a loop won't move that bit even if enabled.  You need to look for a "1", then read the results and wait for another one in the loop before reading again.

    Also seems to be waiting for DRDY to be ‘SET’ in the while loop. In reality it’s an active low, open drain pin so he needs to be checking for ‘RESET’ condition in the while loop.

    If you decide you want to use the DRDY function,

    1. If you  send us a scope shot of I2C transactions. This will give is the timing information.

    Regards,

    Werner