• State TI Thinks Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 2 answers
  • Subscribers 63 subscribers
  • Views 1474 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.

CCS/UCD3138A: Question about PMBUS

liwei qi
Expert 1120 points
Part Number: UCD3138A
Other Parts Discussed in Thread: UCD3138

Tool/software: Code Composer Studio

Use the function of pmbus_handler() in the main loop. Then use the i2c tool for read the output voltage. if the module with high load, SCL will be set low in 35ms. why the scl set low? i have change some i2c tools for the command and it also have the same appearance.

  • 0
    TI__Genius 13570 points

    Liwei,

    If the firmware is heavily loaded, there is not enough time to response the PMBus command, the clock is stretched for 35ms, and then PMBus is reset.

    Can you put a toggle pin in the pmbus_handler(), and see how long it is executed?

    Thanks,

    Sean

  • 0 in reply to Sean Xu
    Expert 1120 points

    Sean:

            I have put a toggle pin in the pmbus_handler() and the timer is between 50us to 90us.

            The register set as follow:

            PMBusRegs.PMBCTRL2.RX_BYTE_ACK_CNT = 0b11;

            PMBusRegs.PMBCTRL2.SLAVE_MASK = 0b01111111;

           But i find that UCD3138 don't acknowledge the slave address and the command somtime.

           

  • 0 in reply to Sean Xu
    Expert 1120 points
    ？？？？？？
  • 0 in reply to liwei qi
    TI__Genius 17090 points

    There are several other things that can cause the clock low for 35 msec.  Generally it means that the firmware is getting lost and not responding to the PMBus properly.  Since you say this issue happens only at high load, I wonder if there is noise causing the main loop to get lost.  There are cases where noise causes the main loop to get lost without resetting the chip. 

    If this is happening, then the indication that the pmbus_handler is getting called should disappear in this case.  If this is what happens then I would suggest looking at improving grounding and filtering for the power to the UCD, and possible using the watchdog to cause a reset. 

    Noise and faults on the PMBus can also cause the pmbus handler to get confused, but normally this is not caused by high load. 

  • 0 in reply to Ian Bower
    Expert 1120 points

    Thank you for your reply.

    I only use the read command. I find some case as follow:

    1.  when the master sent the read address, UCD don't ack the master. then the SCL will be set low for 35ms.

    2.  UCD have receive the command and it have send data to master,but not sent PEC. Then the SCL will be set low for 35ms. The date and PEC was sent by the register of PMBTXBUF. I don't know what happen at the moment.

  • 0 in reply to liwei qi
    TI__Genius 17090 points
    It could be that the master is not requesting the PEC. With some versions of the EVM code, if you don't request the PEC, the next message will have a clock low after the ACK, because the EVM PMBus code is in the wrong state. Sometimes missing the PEC can be caused by a stop being detected due to slow rise time on the data line. To test this, either go from 400 KHz to 100 KHz, or put a lower pull up resistance on clock and data lines. If you are using the USB interface adapter and the TI GUI, you can change the baud rate and the pull up resistor values using the GUI - SAA adapter settings, which will be under the SMBus/I2C tab, if there is a tab.
  • 0 in reply to Ian Bower
    Expert 1120 points
    The master had requested the PEC from the slave. And i also use the USB interface adapter for the i2c communication. The SCL that set low is incidental in the ligh load. In the high load, the appearance is more than in ligh load.
  • 0 in reply to liwei qi
    TI__Genius 17090 points

    Even if the master requests the PEC, if the slave detects a stop, it won't send it.  I'd suggest that you look at the rise time of the data line when it is being released by the UCD.  Or try 100 KHz or lower pull up resistors to see if that is the issue.  Some people copy the protection diodes we have on the open loop board and some EVMs.  Those don't really even need to be on the EVM and open loop board, and they add lots of capacitance.  Taking them off will also improve rise time. 

  • 0 in reply to Ian Bower
    Expert 1120 points
    I have see the wave of SCL and SDA . The wave is ok. The rise time is amost upright . So I think the root case is not this.
    The UCD as slave mode, when master ask data, need to return the data and PEC. The data give to the UCD register and realize by UCD hardaware. But sometime, the UCD only return data. I have see the wave. The SDA is low and SCL is ok when the UCD need to return PEC. Why?
  • 0 in reply to liwei qi
    TI__Genius 17090 points
    When you say the rise time is almost upright, are you sure you are looking at the rise time where the UCD is releasing it? For the clock, almost always the master is releasing it, except at the end of a clock stretch. With the data, the rise time is most visible when the UCD is returning data, so it is releasing the data line. It also happens at the end of ACKs for the writing portions of the message, but then it often isn't seen, because the master pulls the data down if the next bit is low.

    For your second point about the SDA being low, and the SCL is OK, that should be normal for correctly returning the PEC. Can you send me a scope shot or two so I can see what is going on?