• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 31 subscribers
  • Views 2391 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.

Power cycling an I2C slave MLX90614

Raj51
Prodigy 10 points
Other Parts Discussed in Thread: TM4C123GH6PM

Dear TI-er,

i´m using a TM4c123GH6PM Microcontroller as Master and two MLX90614 temperature sensors on the I2C bus (SMbus),

To give each sensor its own unique adress, I have to power each sensor one by one on and off again. (to give a new adress there can only be one sensor on the bus).

This is because they have a standard adress at first and there would be two i2c devices with the same adress on the bus.

So this is how i tried to solve this issue:

1. Initialise two GPIO Pins as outputs to power the MLX90614s (VDD)

2. Turn off one of the two MLX90614 

3. Give the other one which is powered up a new adress.

4. Same procedure turned around.

5. Power on all MLX90614 with their new adresses for example 0x5B and 0x5C

My problem is that communication fails as soon as one of the slaves is powered off on the bus because commands like  (while !SomethingI2C); are I believe endlessly looping. 

I need information on how to disconnect and connect I2C slaves on a bus without causing to much problems.

I have looked through the datasheet of the MLX90614 and found the following statement: (p.39)

"The MLX90614 has diode clamps SDA / SCL to Vdd so it is necessary to provide MLX90614 with power in order not to load the SMBus lines."

 

Giving a new adress was succesful with only one sensor before, so i don´t think my code is the problem.

Thanks in advance.

Best Regards,

Raj

 

  • 0
    TI__Genius 16510 points
    Hello Raj,

    I am moving this to the micro controller forum since this question relates to your TM4C MCU.
  • 0
    TI__Guru**** 244400 points
    Hello Raj,

    The Slave device data sheet for some reason is not accessible from the vendor's web site. Can you please attach the same?

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Guru 117855 points

    Hi Amit,

    Your wish - my command!   (I too had difficulty retrieving the formal data - but persistence (and client calls) have yielded:

    Note: MD is Master Device (MCU)...SD is Slave Device (MLX90614)   I certify the following is a true copy, Pg 13, data sheet 03/Oct/2007, Rev 3:

    (highlights are mine)

    "Generally, the MD initiates the start of data transfer by selecting a SD through the Slave Address (SA). The MD has read access to the RAM and EEPROM and write access to 9 EEPROM cells (at addresses 0x20h, 0x21h, 0x22h, 0x23h, 0x24h, 0x25h*, 0x2Eh, 0x2Fh, 0x39h).

    If the access to the MLX90614 is a read operation it will respond with 16 data bits and 8 bit PEC only if its own slave address, programmed in internal EEPROM, is equal to the SA, sent by the master. The SA feature allows connecting up to 127 devices with only 2 wires, unless the system has some of the specific features described in paragraph 5.2 of reference [1]. In order to provide access to any device or to assign an address to a SD before it is connected to the bus system, the communication must start with zero SA followed by low RWB bit.

    When this command is sent from the MD, the MLX90614 will always respond and will ignore the internal chip code information. Special care must be taken not to put two MLX90614 devices with the same SD addresses on the same bus as MLX90614 does not support ARP[1]."

    So the issue poster reports seems "normal" and must be overcome in one of two ways:

    a) Program the slave address while the MLX is "Off Bus" (i.e. at a separate, single chip, programming station)

    b) interrupt the SCL signal - so that it arrives and/or is "felt" by only one Slave device at a time.   (data distributor IC may handle - and poster Robert will YELL if we don't (pull-up or down) the (now) open line to "divorced" Slave's SCL pin) 

    Either method should realize the end goal of (multiple device) bus, "co-habitation."   

    Poster's method of  "depowering" one device (to program just one device) will fail exactly as he notes - due to bus loading.   Off the bus setting of Slave Address - or interrupting the SCL signal (so that it's "felt" at only one slave) - appear to this reporter as reasonable, "Work Arounds.  

    Forum please note: "Dog ate my (forum) homework."   (my cut/paste from sensor's data sheet has made the forum editing, Nutz!)

    [edit]  post looked so bad I was reduced to "fixing" (removing chew marks).

  • 0 in reply to cb1_mobile
    TI__Guru**** 244400 points
    Hello cb1,

    Thank you for the detailed note. Looking at the form factor of the device, I would suggest option (a) to make the TM4C as the programming station and assigning each device slave address. Option (b) may not be viable on the poster's end system in the final ready to production w/o affecting something unknown on the forum.

    Again: Thank You... My login still does not allow downloading the data sheet.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Guru 117855 points

    Hi Amit,

    Happy/pleased to assist - (somewhat) lighten your burden.

    By my read - device is (normally) TO-39 can - so a TM4C (or other) MCU can be programmed to place a non-volatile "SA" (Slave Address) w/in Slave's EEProm - if and only if - no other identical MXL device shares that serial bus.   (thus precluding multiple device (i.e. "gang programming") unless either bus data or clock (or both) are confined to, "One MXL" at a time!)    While this sounds/seems bad - the programming time (and its repetition among all "ganged devices") remains minimal - it is the "handling time/effort" (to insert & remove device(s)) which the "gang programming" greatly reduces - thus enhances.

    The (few) pins on this slave device (I noted 4) significantly complicate the (usual) easy setting via 3, physical, Slave Address Pins.   (these (usually) appear upon a more "standard" bus device.)   Absent those - poster/user must perform one of the two "monkey motions" as noted.

    Device was an IR temperature sensor - potentially enabling 100 (USD) savings (or more) over a commercial unit.   (and a neat cb1 OLED could not hurt - makes the temperature image impacting & memorable while confirming that the device is aimed properly...)

    I should note that we have used the "trick" (interrupt (break) the clock signals to multiple slaves - yet assure that the, "interrupted (broken) signal line" does not float) to "save" finished pcbs - which for (whatever) reason could not tolerate "common clocking."    Such proves a "powerful diagnostic tool" - aids (& speeds) slave troubleshooting via, "Divide & Conquer."   

    (homework eater (baby/rescued pit-bull) - signals it's "walk time" - dare not interrupt that clock...potential exists (then) for an unwanted (real) float...)