• State Resolved
  • Locked Locked
  • Replies 20 replies
  • Answers 6 answers
  • Subscribers 63 subscribers
  • Views 809 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: Run time clock

Delaney Berger
Intellectual 2475 points
Part Number: UCD90320

Hi Team, 

I have a few questions about reading the run_time_clock and how to use it. 

1. In the BLACK_BOX_FAULT_INFO data there is a date field.  This is described as days from 00:00 01/01 2000, but how does the device know what the actual date is? 

2. We can set any information in the RUN_TIME_CLOCK(write) command that we want, correct?

3. To convert between time in UCD Domain and time in Linux: Is there anything wrong with converting the result of the clock into days and milliseconds, writing that value into the RUN_TIME_CLOCK(write) command? 

4. How does the UCD know what to put in the days field of the BLACK_BOX_FAULT_INFO(read) command?

Thanks for the support, 

Delaney

  • 0
    TI__Guru 66120 points

    Hi

    Please see my comments below.

    1. The date file in the fault is based 00:00:01/01 2000 which is the default starting time in the chip. it is different with the base of the RUN_TIME_CLOCK, which is 0001-01-01 AD 00:00:00.000. Device by default automatically calculate the difference between these two base. For customer, when you read the time stamps from the fault log, please add it on top of the 00:00:01/01 2000. 

    2. you have to set the RUN_TIME_CLOCK based on the correct time: for example: 2021 10-29-7:35:00,000. You can refer this https://www.epochconverter.com/seconds-days-since-y0#:~:text=Days%20Since%200001%2D01%2D01,since%20January%201%2C%201%20AD. please be noted that the base time for the RUN_TIME_CLOCK is 0001-01-01 AD 00:00:00. what ever the value sent on this command shall be based on this base

    3. the #2 above shall answer this.

    4. this has explained in the #1. 

    Regards

    Yihe

  • 0 in reply to yihe
    TI__Intellectual 2475 points

    Hi Yihe, 

    Thank you. 

    To follow up, what is the relationship between the time I set the UCD RUN_TIME_CLOCK and the timestamp that the UCD puts in the fault log?

    For example, if the real world time is 16:54:53 GMT 11/1/2010 and I set the UCD RUN_TIME_CLOCK to 18932 days and 60893000 milliseconds (because there are 18932 days and 60893000 milliseconds between the Linux epoch 00:00:00.00 01/01/1970 and 16:54:53 GMT 11/1/2021 and it is convenient for me to set the UCD RUN_TIME_CLOCK relative to the same epoch as the system RTC), what will the fault log report as the timestamp if there is a fault ten seconds later?

    Thank you, 

    Delaney

  • 0 in reply to Delaney Berger
    TI__Guru 66120 points

    Hi

    To make it simple, you use the RUNT_TIME_CLOCK to set the UCD internal clock to you local system RTC. whatever you read from the fault log is the offset time from 2000-01-01-00:00. The time fromthe fault + 2000-01-01-00:00:00; is the RTC when the fault is detected

    Regards

    Yihe

  • 0 in reply to yihe
    TI__Intellectual 2475 points

    Thank you Yihe.

    Couple more questions. 

    According to the PMBus command reference, the milliseconds field in the BLACK_BOX_FAULT_INFO appears in little-endian order, but the milliseconds field in the LOGGED_FAULT_DETAIL appears in big-endian order. Also, the Fault ID + Days field is in big endian order. Is this correct? I ask because it seems like every other multi-byte unsigned integer in the UCD appears in little-endian order.

    If the real world time is 16:54:53 GMT 11/1/2010 and I set the UCD RUN_TIME_CLOCK to 18932 days and 60893000 milliseconds (which I want to do because there are 18932 days and 60893000 milliseconds between the Linux epoch 00:00:00.00 01/01/1970 and 16:54:53 GMT 11/1/2021 and it is convenient for me to set the UCD RUN_TIME_CLOCK relative to the same epoch as the system RTC), what will the fault log report as the timestamp if there is a fault ten seconds later? Could you calculate the value of such a timestamp field (i.e. milliseconds and days)? Or is there a way I can calculate this myself?

    Thanks so much for your help!

    Delaney

  • 0 in reply to Delaney Berger
    TI__Guru 66120 points

    Hi

    The little or big endian really does not matter, Host shall follow the program guide to interpret the information. 

    As said, the RUN_TIME_CLOCK must be set based on the  0001-01-01 AD 00:00:00.000. you can not set based on the Linux epoch tie 1970/01/01. The quick way is to use the GUI, if you go to GUI Configure->Global Configuration->Run Time Clock. you can sync the UCD clock to PC. from there you can see how GUI send the Run_TIME_CLOCK command in the GUI. As explained in the previous post, whatever timestamp read from the fault log was a offset of 2000-01-01. please rememeber this, if you have a fault 10s later, the time 10s->10000ms is added. You can also use GUI to read the fault to see how the time stamps are calculated from the fault log. 

    Regards

    Yihe

  • 0 in reply to yihe
    TI__Intellectual 2475 points

    Hi Yihe, 

    Thank you for helping me understand this device better! 

    Another question: 

    In the worst case, what's the max time for UCD90320 to detect a rail UV/OV fault? 

    Thank you, 
    Delaney 

  • +1 in reply to Delaney Berger
    TI__Guru 66120 points

    Hi 

    The ADC samples all 32 rails per 400us interval regardless how many rails are configured.

    Regards

    Yihe

  • 0 in reply to yihe
    TI__Intellectual 2475 points

    Hi Yihe,

    Just to clarify the worst case "time to respond". In my case, what's the worst case time to shutdown immediately without any configured delays or glitch filters? This would be 400us, correct? 

  • 0 in reply to Delaney Berger
    TI__Guru 66120 points

    Hi

    The 400us is the time to detect the fault and it takes some extra overhead to process and it is also up to how many rails have faults.

    I would say somewhere 600us-ish. 

    Regards

    Yihe

  • 0 in reply to yihe
    TI__Intellectual 2475 points

    Hi Yihe, 

    Customer is trying to set the run time clock to 738124 (0x000b434e) days and 2637(0z00000a4d) msec.

    The command looks like this:

    0xd7   0x08   0x00 0x00 0x0a 0x4d   0x00 0x0b 0x43 0x4e

    but they are reading back:

    0x08   0x04 0x99 0x09 0xd7   0x00 0x0c 0x24 0x33

    which is not expected. 77138391msec and 795699 days.

    Do you have a suggestion what could be going on with the runtime clock command? Is there a configuration mode that the clock is setting itself? 


    Thank you for the feedback, 
    Delaney

  • 0 in reply to Delaney Berger
    TI__Guru 66120 points

    Hi

     Do they read back immediately?

    I would ask them to check the write and read waveform?

    Here is my test:

    Regards

    Yihe

  • 0 in reply to yihe
    TI__Intellectual 2475 points

    Thanks Yihe, 

    I will check with the customer. However, the read back is over 57,000 days after, which seems suspicious.

    Thank you, 
    Delaney

  • 0 in reply to Delaney Berger
    TI__Intellectual 2475 points

    Hi Yihe, 

    Yes, they are reading back essentially immediately; between the write and the read are just the messages that log the data out of the program to a file. I am checking to see if they can get an I2C analyzer on it, but the transactions seem reasonable. 

    I am wondering if there is a setting on the RUN_TIME_CLK that could potentially be adding on extra time, do you know of such setting/configuration?

    Thank you, 
    Delaney

  • 0 in reply to Delaney Berger
    TI__Intellectual 2475 points

    When I load configuration into device, this is what the RunTimeCLK GUI page looks like, is this correct? They are not using the GUI however to load the runtime clock.

    Is there a setting on this page that needs to be set in order for the runtime clock to work properly when being written to?

    Thank you, 
    Delaney

  • 0 in reply to Delaney Berger
    TI__Guru 66120 points

    Hi

    You have a strange behavior and I have never seen it. There is no setting or enable for the RTC update from GUI. 

    Which version of GUI is used? 

    Regards

    Yihe

  • 0 in reply to yihe
    TI__Intellectual 2475 points

    Hi Yihe, 

    Customer is not using the GUI to program the device, but I loaded the file using 7.7.3. 

    Wondering then maybe if somehow in the code, they are double writing to the clock?

    Thank you, 

    Delaney 

  • 0 in reply to Delaney Berger
    TI__Guru 66120 points

    Hi 

    It is hard to believe. but you can easily test. go to tool->clear configuration. the GUI will close afterwards, you can relaunch the gui to see how it works and then download their codes again.

    Regards

    Yihe

  • 0 in reply to yihe
    TI__Intellectual 2475 points

    Hi Yihe, 

    Appreciate the help debugging this odd behavior. Is "refresh all parameters" the same? 

     

    Also would this be good for customer to do? clear the configuration, and then reload their configuration? 

    Thank you, 

    Delaney

  • 0 in reply to Delaney Berger
    TI__Intellectual 2475 points

    I see, the GUI looks correct. 


    Thank you, 
    Delaney