STM32L4: Adjusting RTC Synchronisation When Using MBED_TICKLESS in RTC Mode

[mattbrown015]

Description

As discussed here How to Achieve Long Periods of Deep Sleep on STM32 #7156 and here deepsleep - LPTIM1 Vs RTC on STM32? it seems appropriate to use the RTC when enabling MBED_TICKLESS on STM32L4.

In our application we also want to use the RTC for recording the time at which a sample is taken. To achieve this our communication protocol includes a method of sending the Unix time to the device.

In an attempt to alleviate the obvious short comings of sending the Unix time via a non-deterministic transport we've also implemented a RTC synchronisation command. In other words, our protocol includes a command to adjust the time by +/-127 s although it is done in a series of 0.5 s steps.

To implement the 0.5 s time adjustment we've used the 'RTC Synchronisation' feature. With the error checking removed and various simplifications made, our code looks a bit like:

void rtc_synch() {
    uint32_t ShiftSecond = advance ? LL_RTC_SHIFT_SECOND_ADVANCE : LL_RTC_SHIFT_SECOND_DELAY;

    uint32_t prediv_s = LL_RTC_GetSynchPrescaler( rtc );
    uint32_t Fraction = (prediv_s + 1) / 2;  // i.e. 0.5 second

    LL_RTC_DisableWriteProtection( rtc );

    LL_RTC_TIME_Synchronize( rtc, ShiftSecond, Fraction );
}

The time adjustment was originally implemented without MBED_TICKLESS defined and it works. It still works when MBED_TICKLESS is defined.

The problem comes when I switch the 'lpticker' from the LPTIM to the RTC using "target.lpticker_lptim": 0 in mbed_app.json. In this mode something goes wrong and the application locks up when attempting to delay the RTC (I can advance the RTC).

I've done a bit of debugging and it appears to be stuck in SysTick_Handler. My feeling is that sys tick is continually firing, it never gets cleared, and no normal code is being run. But, I don't understand how the RTC, sys tick, etc. hang together to really understand.

This is pretty complicated stuff but I'd be grateful if anyone has any thoughts.

Issue request type

[X] Question
[ ] Enhancement
[ ] Bug

[0xc0170]

@ARMmbed/team-st-mcd Please review

[jeromecoutant]

Hi
I think you need to implement something like in rtc_write procedure:

mbed-os/targets/TARGET_STM/rtc_api.c

Line 272 in 1ab05c2

/* Need to update LP_continuous_time value before new RTC time */

[mattbrown015]

Hi @jeromecoutant, funny that you should refer to that section of code because I was looking at it last week because it generates an unused variable warning. current_lp_time is assigned but not used.

I think I understand your point at a high level but not enough to implement anything!

Switching to tickless with the RTC isn't my most important problem at the moment, I shall give your point more thought sometime soon!

Thanks, Matt

[jeromecoutant]

2 things:

• the unused variable will be removed with my next PR

• In your rtc_synch() procedure, I didn't test, but after reading reference manual, it seems you need to poll the SHPF flag?
  Maybe you should try something like :

    LL_RTC_TIME_Synchronize( rtc, ShiftSecond, Fraction );
+   while (LL_RTC_IsActiveFlag_SHP(rtc)) {}

[mattbrown015]

it seems you need to poll the SHPF flag

In the real code we do have a loop like you suggest, although I've never seen it iterate more than once.

[jeromecoutant]

Maybe add also some :

• core_util_critical_section_enter();
• core_util_critical_section_exit();
  ?

[jeromecoutant]

Any update ?
Thx

[mattbrown015]

Hi @jeromecoutant,

No, this is still an issue for me although I haven't looked at it since 9 Aug. I did try everything you mentioned.

I was wondering if it has anything to do with Add LPTICKER tests #8129.

This is because the wake up time passed to the rtc is ignored if the previous match is about to occur. This causes the device to get stuck in sleep.

Sounds suspiciously like what is happening here.

[mattbrown015]

I was deliberately leaving this issue open because it is still an issue for me.

The are a number of PRs relating to the RTC stuck in the pipeline I'm hoping they will fix this. If they don't it will need investigating further.

Everyday I think the PRs are about to be merged and everyday they get put back; this is tricky stuff but fingers crossed they are nearly ready! :-)