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.

TPS65910: RTC issue

Part Number: TPS65910
Other Parts Discussed in Thread: AM3715, TPS65010

Hello Team,

 

we are experiencing a strange behavior of TPS65910 when updating the RTC. For our PMIC two options are described how to set the RTC. In both cases we found some issues.

 

CPU: AM3715, OS: WEC7

 

Important : for all the following the RTC does NOT freeze!

 

 

  1. Behavior when the RTC is stopped when setting new date/time:

    1. Executing write command to stop RTC

    2. Reading the RUN FLAG and waiting until it shows “0”

    3. In the issue case the RUN FLAG does not go to “0” the system hangs.

    4. If the write command is executed a second time after waiting a while because the RUN FLAG did not go to “0” the RTC stops and the RUN FLAG goes to “0”

    5. Unfortunately this is not possible in the existing Software

       

  2. Behavior setting new date and time without stopping the RTC

    1. System hangs

    2. A test routine is checking if the new Date/time has arrived at the RTC

    3. After setting the new date/time the FLAGs RTC_V_OPT and GET_TIME are set to copy the values into the shadow register and reading them

    4. The deviation shows exactly 1 minute

    5. It was observed that the seconds show the written figures but the minutes are increased by exactly 1minute

 

We do not believe that the there is a correlation to how often the RTC is set. The issues can happen also as single event. If the issue occurs the previous event of setting date/time was about 1 second before.     

The I2C Communication seems to be OK as no other effects have been observed when communication with other clients.

Many thanks

Lutz

  • Lutz,

    We are discussing this and deciding who is the best to respond to this issue. We will reply in the next day or so with more information. Thank you.

  • Lutz Naumann said:
    Behavior setting new date and time without stopping the RTC

    Lutz, for item #2 this is mostly related to the PMIC, so I will try to follow-up here while the Sitara team continues to review item #1.

    Lutz Naumann said:
    A test routine is checking if the new Date/time has arrived at the RTC

    Please provide more details on the test routine. How is the new date/time set? What is the sequence of I2C commands sent to the PMIC?

    Lutz Naumann said:
    After setting the new date/time the FLAGs RTC_V_OPT and GET_TIME are set to copy the values into the shadow register and reading them

    In what order do you set GET_TIME and RTC_V_OPT flags?

    Lutz Naumann said:
    The deviation shows exactly 1 minute. It was observed that the seconds show the written figures but the minutes are increased by exactly 1 minute

    Please provide an example of the date/time that was set in the RTC of the PMIC, and provide the info (decoded date/time and raw data) that was returned from the shadow registers.

    I would recommend using an logic analyzer ("I2C sniffer") to record the data that you can attach as a CSV. That way, we can interpret it on our end in addition to your reading observations.

  • Hi Brian,

    here is the sequence of the access to the registers of the RTC in the PMIC TPS65010:

     

    Registeraddresses

     

     

     

    Debug-Output over the UART-Interface

     

    PID:055F00C6 TID:043F00E2 +OEMSetRealTime()

    PID:055F00C6 TID:043F00E2 OEMSetRealTime() - Entered

     

    PID:055F00C6 TID:043F00E2 OEMSetRealTime(): 72919962 - Time to set to: 0x1d4439de87cb380               Show the actual value of GetTickCount() and FileTime as QuadWord

    PID:055F00C6 TID:043F00E2 ReadRTCTime   - Y:0x18; M:0x9; T:0x3; H:0x15; M:0x50; S:0x59                            Show the converted values of Date and Time to set

     

    PID:055F00C6 TID:043F00E2 TWLWriteRegs()- OAL/twl_access:   Addr: 0x5; Value: 0x18                    Write values to registers of RTC

    PID:055F00C6 TID:043F00E2 TWLWriteRegs()- OAL/twl_access:   Addr: 0x4; Value: 0x9

    PID:055F00C6 TID:043F00E2 TWLWriteRegs()- OAL/twl_access:   Addr: 0x3; Value: 0x3

    PID:055F00C6 TID:043F00E2 TWLWriteRegs()- OAL/twl_access:   Addr: 0x2; Value: 0x15

    PID:055F00C6 TID:043F00E2 TWLWriteRegs()- OAL/twl_access:   Addr: 0x1; Value: 0x50

    PID:055F00C6 TID:043F00E2 TWLWriteRegs()- OAL/twl_access:   Addr: 0x0; Value: 0x59

                                 

    PID:055F00C6 TID:043F00E2 TWLReadRegs()- OAL/twl_access:   Addr: 0x10; Value: 0x1                    Read control register

    PID:055F00C6 TID:043F00E2 TWLWriteRegs()- OAL/twl_access:   Addr: 0x10; Value: 0xc1                  Set RTC_V_OPT und GET_TIME together

    PID:055F00C6 TID:043F00E2 TWLReadRegs()- OAL/twl_access:   Addr: 0x10; Value: 0x81                  Read control register

     

    PID:055F00C6 TID:043F00E2 TWLReadRegs()- OAL/twl_access:   Addr: 0x5; Value: 0x18                    Read values of registers of RTC

    PID:055F00C6 TID:043F00E2 TWLReadRegs()- OAL/twl_access:   Addr: 0x4; Value: 0x9

    PID:055F00C6 TID:043F00E2 TWLReadRegs()- OAL/twl_access:   Addr: 0x3; Value: 0x3

    PID:055F00C6 TID:043F00E2 TWLReadRegs()- OAL/twl_access:   Addr: 0x2; Value: 0x15

    PID:055F00C6 TID:043F00E2 TWLReadRegs()- OAL/twl_access:   Addr: 0x1; Value: 0x51

    PID:055F00C6 TID:043F00E2 TWLReadRegs()- OAL/twl_access:   Addr: 0x0; Value: 0x59

     

    PID:055F00C6 TID:043F00E2 ReadRTCTime   - Y:0x18; M:0x9; T:0x3; H:0x15; M:0x51; S:0x59                            Show the read values of the registers

     

    PID:055F00C6 TID:043F00E2 TWLReadRegs()- OAL/twl_access:   Addr: 0x10; Value: 0x81                  Read control register

    PID:055F00C6 TID:043F00E2 TWLWriteRegs()- OAL/twl_access:   Addr: 0x10; Value: 0x1                    Reset RTC_V_OPT

     

    PID:055F00C6 TID:043F00E2 OEMSetRealTime(): 72920202 - Time is set to: 0x1d4439ec3ff980                        Show the actual value of GetTickCount() and FileTime as QuadWord

    PID:055F00C6 TID:043F00E2 OEMSetRealTime() - Time differs!

    PID:055F00C6 TID:043F00E2 OEMSetRealTime() - Time differs more than a second: 0x023c34600    The time differs one minute – see register 0x01

     

    PID:055F00C6 TID:043F00E2 OEMSetRealTime() - Leaved

    PID:055F00C6 TID:043F00E2 -OEMSetRealTime()

     

    The different of GetTickCount – values is 240 ms (orange marked)

    The minute-register of the RTC is incremented and the second-register is not changed. (red marked)

     

    thanks Lutz

    PMIC communication.DOCX

  • Hi Team any news on this onw. Customer is waiting.

    Thanks

    Lutz

  • What is the value of ROUND_30S bit?

    Is the STOP_RTC bit set during this transaction? Based on the data you provided, it appears this bit is set to 0b, so I will not go into too much details about this bit. If it is set to 1b, the RTC will round up to the next minute.

    The procedure for setting the new time can be done with the STOP_RTC bit set to :

    To modify the current time, software writes the new time into TC registers to fix the time/calendar information. The DBB can write into TC registers without stopping the RTC. In addition, software can stop the RTC by clearing the STOP_RTC bit of the control register and check the RUN bit of the status to be sure that the RTC is frozen. Then update TC values, and then restart the RTC by setting the STOP_RTC bit.

    Based on the data you provided, STOP_RTC = 1b (RTC is running).

    Is it plausible that the RTC rolls over from 59 seconds to 00 seconds and the minute increments by 1 before you write the SECONDS_REG to :59?

    Given that the seconds register is at :59 and the RTC is running, this is a plausible explanation for me.

    To very this, I recommend you run the test again by clearing STOP_RTC = 0b, then overwrite the time, read back the time, then restart the RTC by re-setting STOP_RTC = 1b. This would verify if my theory is correct.

    0xc1   

  • Thanks Brian,

    I will check this with the customer. The test you are suggesting with stopping the RTC is actually the second scenario described which leads to the situation that in some cases the RTC is NOT updated and would require a second write command (which is not implemented in the software) Please refer to the initial questions.

    From my understanding there must be something else causing the problem. Sometimes it works and sometimes we hit the issue in both update cases (with and without stopping the RTC).

    many thanks

    Lutz 

  • Lutz,

    1. For case 1 (minute updates by 1 during RTC re-write), my theory is not refuted if sometimes the issue occurs and sometimes that issue does not occur. Based on the amount of time it takes to Write to MINUTE register and SECOND register, there is a probability this will happen whenever SECONDS is :59
    2. For case 2 (need to Write 2x before RTC is updated): I do not have an explanation for the issue, but this is not a problem from my perspective if sometimes the issue occurs and sometimes the issue does not occur. The failure is completely preventable by checking that the Write took effect.

    In case 2, this is the purpose of Reading back Register values after they are written: to verify if they were written correctly. If they are wrong, it would require a second Write command, but requiring a second Write command is not an issue. This is my recommendation: Stop RTC, Write, Read, Write (again, if necessary), Read (again), Start RTC again.