• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Answers 5 answers
  • Subscribers 63 subscribers
  • Views 540 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.

UCD90320: UCD90320 PMBus SCL clock low lasting for long period. UCD seems working abnormally afterward.

Gerard Lo
Prodigy 20 points
Part Number: UCD90320


The following is the snapshot as the issue happening. The waveform shows long clock low driven by the master with 59ms; which impact the time period of ACK to repeated-start and then ACK to ACK time period. 

As the cursor showing, the 35 ms after the ACK complete, The UCD seems working abnormally. (as some enable output driven by UCD seems not working as expect)

To zoom in the waveform, the master write command of 0x8E, and then UCD ACK it. Further the clock was driven low with 59 ms.

in the previous command of 0x8E, the master writer 0x00 and 0x0C onto the UCD. The waveform shows very long clock stretching time of 77us. Comparing with overall the other transactions, the other transactions with UCD has only 10~20us of clock stretching time. 

We are not sure whether there was something wrong already inside UCD during this transaction?

As the following waveform, the master is going to write the 0x00 and 0x0C with longer clock stretching period (~77us).

As this issue, seems few checking items with you; though the master seems driving too long on the ACK to repeated-start period.

1. Does the DPM have problem on the longer clock stretching time (~77us)?

2. What would possibly happen as the UCD getting a very long ACK to repeated-start period (~59 ms)?

3. As the SMBus time out (suspecting the 35 ms is the time out condition), should UCD still work well on its FW defined logic? It is not wished the SMBus transaction can impact the other function out of the SMBus function.

4. If the suspect of 35 ms is correct, can UCD not assert the time-out behavior in 35 ms? i.e. We wish the UCD do nothing different as the SMBus running over 35 ms clock low.

The master is MCP2221 in this case.

Thanks for your attention and kindly suggest if there is any. 

  • 0
    TI__Guru 66920 points

    Hi

    Why did host hold the SCL more than 35ms(pmbus timeout) ? Your current UCD90320 firmware can not handle PMBus timeout and please ensure that master does not hold SCl for such long peirod. UCD90320 will reset if there is a timeout event. we have fixed this in the new firmware which is going to be released.

    Regards

    Yihe

  • 0 in reply to yihe
    Prodigy 20 points

    Thank you Yihe,

    We are checking with the vendor of MCP2221 and waiting for their response on this. Wish we can get something from them also.

    Back to the UCD behavior, what you mentioned is the UCD would be reseted on its user defined FW behavior? 

    If there is already solution from your FW, could you please let me know about its schedule and whether you can give me the draft FW for our checking whether we real hit this known issue now? Because it is pretty hard to set up environment and also to reproduce it.

    Further, is the solution FW updated also through SMBus or JTAG interface of UCD?

    TI FW information:

  • 0 in reply to Gerard Lo
    TI__Guru 66920 points

    Hi

    Yes, it is good to fix from hos side since holding 54ms is too long.

    UCD90320 would reset itself and all IO will back to default.

    we have the new firmware. Please contact your local TI support and it is updated from I2C interface.

    Regards

    Yihe

  • 0 in reply to yihe
    Prodigy 20 points

    Thank you these. I am checking with Mark Chen about this update process and file.

    so here listed what we got the FW content inside 3 different DUT. Could you please tutor me no how to say what is the FW version inside and which of them were expected to hit the issue?

    SN: 00077 (no issue)

    SN: 00016 (issue hit)

    SN: 00212 (no issue)

  • 0 in reply to yihe
    Intellectual 290 points

    Hi Yihe

    1.  Will App. of Fusion Digital Power Designer be updated to newer version base on this fix?
    2.  All IO will back to default. Is this including LGPO?

  • 0 in reply to HSU HANWEN
    TI__Guru 66920 points

    Hi

    I had provided the file to Mark.

    this is firmware issue and it has nothing to do with GUI.

    yes. LGPO does.

    Regards

    Yihe

  • 0 in reply to yihe
    Intellectual 290 points

    Hi Yihe:

    The reason I want to check if App. will implement this fix or not is due to lots of UCD90320 have been mounted on boards.

    So I want to check if we could implement this fix by updating .csv file or not?

  • 0 in reply to HSU HANWEN
    TI__Guru 66920 points

    Hi

    Please contact Mark for all.

    It is good to have it fixed from Master instead of from UCD90320.

    Regards

    Yihe

  • 0 in reply to yihe
    Prodigy 20 points

    hi Yihe,

    1. Could you please check whether we programmed it correctly?

    original FW version snapshot, it shows v3.0.0.3320

    after programming the given bin file, it shows v3.0.0.3330

    2. Is the v3.0.0.3330 the formal released FW? Can we apply this FW to all the PCBAs we have and our customer has on hand?

    3. Is there any other fix item of issue between 3320 and 3330? We'd like to know whether there is any additional issue we should fix by the 3330.

    4. How can we understand the shipped UCD90320 with which of FW? And what of the batch of UCD90320 will start to be applied with 3330 if this is a formal released version?

    5. Since we need our software guy to program the UCD FW, could you please share us the document of guidance on updating the bin file with specific command or address format of I2C?

  • 0 in reply to Gerard Lo
    TI__Guru 66920 points

    HI

    1.Yes, they are right

    2. yes, it is official released, 

    3.No. timeout is the only to address

    4.All date code with 2309(March-2023) or 33(March-2023)shall have this new firmware. that's the way one to tell.

    5. Please check Mark for the document. Again, it is more easily to change the behave of Master to not hold bus for such long time than upgrading firmware.

    Regards

    YIhe

  • +1 in reply to yihe
    Prodigy 20 points

    hi Yihe,

    I have no more question on this issue. We will try to plan based on your feedback.

    BTW, based on the application of MCP2221, there are 2 commands combined as a SMB transaction. This is why it cannot easily control the time interval between ACK and re-start TOKEN. We are investigating into the scrip details and see whether we can do any about it.

    Thanks