Why an STM32L476's RTC counts more than 24h and don't icnreases the day

[albert2]

I've designed a board that has a STM32L476.

This part is supplied using a triple system of dual battery + power ( when it is available)

We've manufactured more than 20k units of them and they are working ok

A few days ago 2 boards came back to our design lab that exhibit the following symptoms :

-> The RTC keeps counting past 23:59:59 until 39:59:59

-> Neither on 23h nor 39h rollover the day gets increased

-> When trying to set the time we get the following data:

If the time is less than 20h, 20h get added to it

Else the hour is correctly set

-> Rollover behavior don't changes

If we force a reset of the CPU, the problem dissapears.

More data:

-> The RTC access is done using HAL libs.

-> The RTC isn't reset when setting the date/time

We still have one untouched board for testing, but any try to use a debugger would trigger a CPU reset, making the probblem dissapear. (This is why we lost ont of the boards )

Does anybody have a hint about what the problem could be ?

[waclawek.jan]

This happens when you use the 12hour mode (AM/PM) and set time beyond 12:59:59.

> The RTC access is done using HAL libs.

That's no excuse.

JW

[albert2]

Dear JW

The code that sets the RTC explictly sets it as 24h format :

  __HAL_RCC_PWR_CLK_ENABLE();
    __HAL_RCC_RTC_ENABLE();
 
    /* Configure RTC */
    hRTC.Instance = RTC;
    /* Set the RTC time base to 1s */
    /* Configure RTC prescaler and RTC data registers as follow:
      - Hour Format = Format 24
      - Asynch Prediv = Value according to source clock
      - Synch Prediv = Value according to source clock
      - OutPut = Output Disable
      - OutPutPolarity = High Polarity
      - OutPutType = Open Drain */
    hRTC.Init.HourFormat = RTC_HOURFORMAT_24;
    hRTC.Init.AsynchPrediv = RTC_ASYNCH_PREDIV;
    hRTC.Init.SynchPrediv = RTC_SYNCH_PREDIV;
    hRTC.Init.OutPut = RTC_OUTPUT_DISABLE;
    hRTC.Init.OutPutPolarity = RTC_OUTPUT_POLARITY_HIGH;
    hRTC.Init.OutPutType =  RTC_OUTPUT_TYPE_OPENDRAIN;
    if(HAL_RTC_Init(&hRTC) != HAL_OK)
    {   /* Initialization Error */
        while(1) show_error(1,(uint8_t *)"9");
    }

There are more than 20.000 units in the field working as expected. Exactly the same firmware. No changes in the 2 yrs from initial release.

Just by resetting the MCU, ( no other changes, a MCU reset forces an initialization of the RTC settings ), the RTC works correctly.

Are you confirming that the bit that fixes the 24h format can be changed without code intervention ?

Albert

[waclawek.jan]

Albert,

> Are you confirming that the bit that fixes the 24h format can be changed without code intervention ?

Where did I say that?

All I said was, that overflowing through 23:59:59/39:59:59 without changing date is the behaviour of RTC when RTC_CR.FMT=1 and time is set beyond 12:59:59.

There may be other circumstances when this happens, but I'd be surprised should there be any else.

That said, the problem should be kind of self-correcting, i.e. when time rolls over 39:59:59 (or more precisely, through 00:59:59), it should after that run in the 12-h pattern correctly, i.e. then it rolls over from 12:59:59 to 01:00:00, toggles am/pm when rolling from 11:59:59 to 12:00:00, and increments date when rolling over midnight - this all, unless it's set externally above 12:59:59 again. So, if you don't observe this "self-correction" it may be something different.

Also, there may be a hardware bug, but again, I'd be surprised. Software bugs are far more common, especially when using a "library", i.e. you don't have full control over your code.

You should look at all Cube/HAL functions you call, where RTC_CR is written to under RTC_ISR.INIT being set. The obvious suspects are routines where time and date are written, but there may be more. The most usual mode of error is an uninitialized locally/dynamically allocated init struct used in the call.

I can't explain the "If the time is less than 20h, 20h get added to it", but that may be result of your particular routine (in conjunction with related Cube/HAL's routines) to set time.

Pity you did not hot-connect a debugger to one of the boards under the faulty condition, to observe the RTC registers - that would give us a definitive answer. But I probably would not think to do that either.

JW

[albert2]

Hello JW

1st : Thank you very much for your interest in this question. Your help is greatly appreciated.

Now, on to the symptoms :

A - The MCU is connected to an FPGA that has a PCIExpress interface. I can access in real time the MCU and ask for a limited set of operations to be done by the MCU. One of them is to read the RTC timestamp. Another is to set the RTC date/time. This is how I can be sure that the RTC isn't working correctly, because I can read and set the time/date registers whenever I want to any correct value I want to test. Perhaps I should have explained this before....

B - The problem isn't self correcting at 39:59:59 neither al 12:59:59. Tried both of them.

C - As I said in the 1st post, in neither case the day increments. Nor in the count from 23:59:59 to 24:00:00.

D - Of course I have the code of the HAL libraries. They aren't compiled. The code seems OK and it correctly unlocks and locks again the access to modifying the RTC upon entry and exit. No binary libs are used at all.

E - The only access to write to the RTC is done when setting time. I've verified with other boards and gdb that the data sent to the RTC is correct in every case.

I really suspect that the HW has in an unstable state, but without access to the RTC config registers nor the HDL used to create it can't be sure of it.

Do you have any hint on how to hot-connect the STLINK-v2.1 to the board ?

Meanwhile I'll try with another board to find the correct hot connecting procedure until I've got it perfectly working. Then I'll use it in the misbehaving one.

Thank you very much and warm regards from Barcelona.

Albert

[waclawek.jan]

Albert,

> The problem isn't self correcting at 39:59:59 neither al 12:59:59. Tried both of them.

So, what was the time one second after 12:59:59?

Doesn't your code (icluding the used Cube, of the exact version at the time when the code was compiled) add 12 to hours, when the am/pm flag in RTC_TR is set?

> As I said in the 1st post, in neither case the day increments. Nor in the count from 23:59:59 to 24:00:00.

Yes, that's exactly the way how it behaves when set to 12-hour mode. It then increments day when rolls over from pm:11:59:59 to am:12:00:00. Try yourself: set the clock deliberately to 12-hours mode, and play with it.

> The only access to write to the RTC is done when setting time. I've verified with other boards and gdb that the data sent to the RTC is correct in every case.

Checking that code runs once correctly proves nothing. Once the FMT flag got set in some inadvertent way - either at initialization it might

As I've said, the prime cause of these problems usually is an uninitialized field in the structs used when calling the Cube/HAL routines. If those structs are a local non-static variable or allocated dynamically, their content is "random" and an uninitialized field may surprisingly influence the whole written register.

I again recommend you to try to set deliberately the clock to the 12-hour mode and try - do the sympoms match those you've encountered with the "problematic" boards?

> Do you have any hint on how to hot-connect the STLINK-v2.1 to the board ?

This is entirely dependent on your toolchain. Sorry, I don't use this regularly - I tried only once, several years ago, with a tool which is not very widespread ( http://epsdebugger.comsytec.com/ ) , so can't give you guidance for this. Don't forget that you need to play also with the am/pm flag in RTC_TR to have the full experience.

JW

[albert2]

Hello JW

Only on the problematic board :

-> after 12:59:59 the RTC becomes 13:00:00, the day don't gets increased

-> after 23:59:59 the RTC becomes 24:00:00, the day don't gets increased

-> after 39:59:59 the RTC becomes 00:00:00, but the day don't gets increased in any case. The problem persists when counting the next 40 hours.

In all other boards, after 23:59:59 becomes 00:00:00 and the date gets increased. The board that got reseted works correctly too.

The code doesen't do any change on the RTC data contents before sending them to the FPGA. The FPGA just forwards them to the PCIe when the controller software reads them.

RTC registers are write protected (as per the datasheet ) , and the only places in the software that unprotects them are init and when setting the date/time. Both procedures reassert the write protection before exit.

The MCU has the watchdog activated and a boot counter. The boot counter is still 1, the default value. It hasn't been rebooted yet.

Thanks for your hints, Will keep searching. Have a nice weekend.

Albert

[waclawek.jan]

Albert,

have you find the cause of the problem?

JW

[albert2]

Hi JW

I got sidetracked with other more important tasks, but yesterday got on it again.

I've been able to reproduce it by setting the date/time a few 1000s of times, and it could be an uninitialized structure member when calling HAL_RTC_SetTime.

The strange thing is that once the RTC is in a wrong state, remains that way until it is reset.

Will post once we find the reason and how to avoid it.

Albert

[OMira.1]

Hi Albert,

I'm facing the same problem with an STM32l476 MCU.

We've managed to break the execution of the software without resetting the board and got the RTC register.

Below, the values. Did you solve this problem or find any workaround?

Regards,

Oliver