• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 2 answers
  • Subscribers 64 subscribers
  • Views 521 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.

LM5066I: the SMBA pin alert function.

jkw
Prodigy 100 points
Part Number: LM5066I

Hi  TI expert, 

   I have issue when using LM5066I as power monitor and management in project.

The SMBA pin output low randomly after board is powered up, and I tried to read the STATUS_BYTE register(0X78h) which has default value 01h, but it was 4Bh. According to the datasheet, then it indicates there are multiple fault happened.

Except the bit 6(it  could be set by chip automatically if there is any warning or fault), there are another 2 faults which are VIN undervoltage(bit3) and communication fault(bit1).

We captured the VIN by scope when the SMBA pulls low, but the VIN seems quite stable, so it should not be a real VIN undervoltage; and the communication fault, I've no idea why it happens, even after the SMBA pulls low ,  I could read the chip by i2c normally which means the communication works.

Can you help analyze it  and  a relevant capture of schematic as shown below:

Thanks,

JKW

  • 0
    TI__Mastermind 30915 points

    TI recommends sending the CLEAR_FAULTS command after every successful power-up of the device to clear the warning and fault bits set in the status registers during initialization, if any. This also ensures the SMBA# is de-asserted.

    Please click on "This resolved my issue" if this post answers your query.

  • 0
    Prodigy 100 points

    Hi Avishek,

        Thanks for the advice. I will try it.

        But my question is I get SMBA# asserted after an undermined period of time after a successful power up, this period could be several seconds, several minutes or even longer; before that everything looks good, we monitored the SMBA# pin with scope.

  • 0 in reply to jkw
    TI__Mastermind 30915 points

    In that case some warning, or faults bits are getting set in the status registers. Please read all the status registers at the instant SMBA# gets asserted. 

  • 0 in reply to Avishek Pal
    Prodigy 100 points

    Hi Avishek,

    When SMBA# asserts, the values read from these registers are:

    address: data

    0x78h : 0x49

    0x79h:  0xa849

    0x7Ah:  0x20

    0x7Ch: 0x10

    0x7Dh: 0x00

    0x7Eh: 0x00

    0x7Fh: 0x00

    0x80h: 0x00

    according to values and datasheet, there is input undervoltage fault happens, but as I said in the first post, I monitored the input by scope, no input dip or drop was happening when the SMBA# asserted.

    Second, sometimes the CML bit in STATUS_BYTE (78h) gets set, could you explain what condition may result in communication fault? i2c timing?

    But how come I still could read registers via I2C interface?

  • 0 in reply to jkw
    TI__Mastermind 30915 points

    This is expected to see. While VIN rises from zero to 48 V (suppose), it passes through the UVLO threshold. Hence, it is getting set. 

    During powerup, CML error can come up. This is also expected. You are reading the registers after the successful powerup. That time PMBus communication is successfully established.

    As I told earlier, TI recommends sending the CLEAR_FAULTS command after every successful power-up of the device to clear the warning and fault bits set in the status registers during initialization, if any. This also ensures the SMBA# is de-asserted. 

  • 0 in reply to Avishek Pal
    Prodigy 100 points

    Hi Avishek,

     I tried your suggestion of  sending CLEAR_FAULTS command after every successful power-up. But it doesn't help, the SMBA# still get asserted after an undermined period of time. 

  • 0 in reply to jkw
    TI__Mastermind 30915 points

    Please follow these steps and share the results.

    1. Power up the device,
    2. Send CLEAR_FAULTS (03h) command,
    3. Read all the status registers,
    4. Continuously monitor the SMBA# signal using an oscilloscope,
    5. Read all the status registers at the instant SMBA# gets asserted.
  • 0 in reply to Avishek Pal
    Prodigy 100 points

    Hi Avishek,

    I tried your method, and found that the CML error bit(STATUS_BYTE reg) was set randomly and SMBA# asserted.

    Furthermore,  I stopped the regular i2c reading hosted by MCU and repeated the test , and the SMBA# didn't get asserted any more at least in hours during the test.

    So I'm rewriting the i2c code in MCU and repeat the test again.

    I will report test result later.