STM32L476 Update rtc_api.c

[star297]

Added RTC ISR check code for Mbed rtc_isenabled function.
Removed rtc_inited parts.

Tested on Nucleo-L476 and Disco-L476 boards with and without vBat pin powered.
Also fully tested on prototype hardware.
Targets no longer resets RTC time registers on POR or nRST including sleep modes.

[0xc0170]

I thought we eliminated the static variable to keep the state of RTC. Thanks @star297 for bringing this up, and sending this patch

@bcostm @adustm Please review

[adustm]

In the case of a nRST
If application does
rtc_init(); -> RTC will start
If application does
if (!rtc_isenabled()) rtc_init(); ->The RTC will not start

The RTC will not start, because RTC power domain will not be switched on and LSE/LSI clock will not be linked to RTC clock.
Refer to issue #1480 that we fixed earlier.

As this rtc_isenabled function is a public function, we cannot assume any way of using it from users.

The SW variable shall be kept and PR #1523 should not be used.

[0xc0170]

@star297 Please provide a code example how you tested the code. To answer the comment above

As this rtc_isenabled function is a public function, we cannot assume any way of using it from users.

Not certain what does this mean?

The RTC will not start, because RTC power domain will not be switched on and LSE/LSI clock will not be linked to RTC clock.

Is this related to if (!rtc_isenabled()) rtc_init(); ? This patch is using RTC peripheral to check if it was enabled. Does this mean, that if RTC is not, fetching RTC->ISR register might lead to a fault? You could overcome this by setting RTC clock in rtc_isenabled, to be able to read RTC registers , to get a status if RTC is configured.

[star297]

The int rtc_isenabled(void) function is common across all Mbed platforms to test if the RTC has been initialised and subsequently running.

This function MUST be utilised on Mbed by ALL platform vendors to enable user code compatibility across each of the platforms.

Mbed's rtc_time.c function checks #if DEVICE_RTC, if true the RTC can be initialised, first by testing the int rtc_isenabled(void) function in the platform's unique RTC api.
When a RTC function call is made, in the case of STM targets, the ISR register is checked to determine the state of the RTC. Because each platform's RTC is different the rtc_isenabled test must be done in the platform's RTC api.

Reading the ISR register at any time has never resulted in an error. If no RTC function call has been made the register always reads decimal 7, its initial power on state. Either the RTC power domain is enabled at start up or it can be read independent of this.

If the RTC has not been initialised rtc_init() is called from the Mbed rtc_time.c that will configure the RTC power domain and clocks at the same time resetting the Backup Domain and setting set_time(0);.

If the ISR register indicates the RTC is running, rtc_init() is not called as the RTC is already set up and running and will not reset Backup Domain and set_time(0); this will leave the RTC registers in tact and will remain running.

The rtc_inited parts are not required here as the rtc_isenabled function takes control. It only causes the RTC to reset on nRST or POR which is not what we want.

As this rtc_isenabled function is a public function, we cannot assume any way of using it from users.

I do not understand what you are saying, this function forms part of the Mbed system set up that is pretty much automated so users would not be concerned with it. A user can manually call rtc_init() if required. If that happens the rtc_isenabled function will still be valid.

Whilst I have been faultlessly using a form of this working example below for some time, I may still be missing some important considerations.

Simple test code here:
https://developer.mbed.org/users/star297/code/RTC-test/

Working MBED-DEV here:
https://developer.mbed.org/users/star297/code/mbed-dev/

[dbestm]

The RTC init flag is used in the rtc_init() function before the init of the RTC but after the init of the clock which is needed to read the time and the date. So the RTC is not reset after a nRST.
If you want to remove the rtc_inited parts, you have to move the setting of the clock inside the rtc_isenabled() function.
Let us know what you prefer?
either use rtc_inited as it is done
or set the clock + use RTC init flag in rtc_enabled()
I remind you if the clocks are not set, the RTC can run but the time and date registers will not be updated.

[star297]

Further research results in the following quote from page 204 of the RM0351 manual:

The LSE clock is in the Backup domain, whereas the HSE and LSI clocks are not.
Consequently:
• If LSE is selected as RTC clock:
– The RTC continues to work even if the VDD supply is switched off, provided the
VBAT supply is maintained.

Therefore once rtc_init() has run the LSE clock setting remains working which explains why it does work under reset conditions, However;

• If LSI is selected as the RTC clock:
– The RTC state is not guaranteed if the VDD supply is powered off.
• If the HSE clock divided by a prescaler is used as the RTC clock:
– The RTC state is not guaranteed if the VDD supply is powered off or if the internal
voltage regulator is powered off (removing power from the VCORE domain)

This explains why my suggested method does work in LSE mode both in run and deep sleep modes.
The test code above does prove this.

I think we need to make a decision here so as not to overcomplicate this.
Both Nucleo and Disco L476 boards have the LSE 32KHz crystal fitted as standard from the factory.
We can't cater for every eventuality, I would suggest that we assume the RTC will be clocked with LSE by default and go with this. It also fits in with standard Mbed set up's across most other platforms that operate in a similar manor.

Other RTC clocking scenarios will be sub standard and detract from true RTC functionality.
This will also lead to start up delays that are particularly undesirable when waking from sleep modes.
As the second quote indicates the RTC state cannot be guaranteed under these circumstances which renders the RTC unusable from a practical point of view.
Certainly it is possible to test in the rtc_isenabled() part for these different eventualities, but is it worth it? what we do not want to do is run the clock set up code if it is already running.

Your platform, your decision.

[0xc0170]

@star297 The commit f485a47 should probably not be here.

[star297]

No it shouldn't, not sure why that happened.

[star297]

See PR #1548, I have applied those changes to this L476 target and has fixed the problem.
If the same changes are made for the L476, you can close this issue.

[0xc0170]

#1551 should fix this. Please have a look