The RTC driver topic

[barthess]

Ok. Tomorrow after your changes I will test driver with LSI and HSE/128 as clock sources. Good night.

[colin]

I'm trying to understand the capabilities of the STM32 RTCv1 and RTCv2, especially in terms of ChibiOS/RT 2.4 support. I'm new to ChibiOS and haven't used the RTC driver yet.

I understand the STM32F1 has an RTC that can use a prescaler less than 32 768 to get better than one second precision, but the STM32F2/F4's RTC is different and has one-second precision for normal timekeeping with some special mechanism to set a wake up alarm with sub-second precision.

Q: Will release 2.4 will support the RTC support waking the STM32 up from a low-power SUSPEND mode with sub-second precision?

Q: Is it possible to read the RTC time to millisecond precision? This would be critical for real-time data loggers running at medium to high sample rates, especially when consolidating data from multiple devices.

On the topic of low-power sleep (which is strongly related to RTC because the RTC is one of the primary means to resume the program from sleep mode), is there any resource or example to show how ChibiOS might support an application that needs to sleep in a low-power mode between handling events?

Thanks and best regards,
Colin

[mabl]

I understand the STM32F1 has an RTC that can use a prescaler less than 32 768 to get better than one second precision, but the STM32F2/F4's RTC is different and has one-second precision for normal timekeeping with some special mechanism to set a wake up alarm with sub-second precision.

Hi colin,
I can only speak for the STM32F1, but there are actually two ways to get sub-second resolution there. You can use a smaller prescaler, but since the external LSO clock is a 32768 kHz oscillator, I'd not change this value. Sub-second resolution can than be achieved by reading the prescaler counter register. (Setting the time is only possible for full seconds, but you can get around that by waiting until the second wraps)

Of cause you cannot wake up with sub-second resolution then. But wouldn't it be ok to stay awake for the whole second?

Also be aware that you will have to correct your oscillator drift. With a standard crystal your time will be off by some ms within hours.

[Giovanni]

ChibiOS/RT does enter a low power mode in between interrupts when CORTEX_ENABLE_WFI_IDLE is enabled. The RTC wakeup should only be used for long sleep periods because the restart is slow.

Giovanni

[Giovanni]

Barthess, I added I-Class variants to all functions in the HLL.

Giovanni

[barthess]

@Giovanni
1) hal_lld_backup_domain_init() changed. Now it is possible to change clock source for RTC.
2) in ISR added rtc_lld_apb1_sync() call because we can miss interrupt event:

Software accesses the RTC prescaler, counter and alarm values through the APB1 interface
but the associated readable registers are internally updated at each rising edge of the RTC
clock resynchronized by the RTC APB1 clock. This is also true for the RTC flags.
This means that the first read to the RTC APB1 registers may be corrupted (generally read
as 0) if the APB1 interface has previously been disabled and the read occurs immediately
after the APB1 interface is enabled but before the first internal update of the registers.

I know that waiting in ISR is bad idea, but that wait may (or may not) occurs only once after powering AHB1 on.

@colin
RTCv2 is draft driver for MCUs with hardware calendar.

Q: Will release 2.4 will support the RTC support waking the STM32 up from a low-power SUSPEND mode with sub-second precision?

Waking up with subsecond precision possible only on STM32F4x. But I can not imagine situations when that required. Can you provide example (just a curious)?

Q: Is it possible to read the RTC time to millisecond precision?

Not all MCUs support it. For example STM32F1x and STM32F4x support it, but STM32F2x and STM32L1x not. Consult with reference manual on your MCU.

is there any resource or example to show how ChibiOS might support an application that needs to sleep in a low-power mode between handling events?

I do not know about resources but examples you can find in:
testhal\STM32F1xx\EXT_WAKEUP
testhal\STM32F1xx\RTC

[colin]

@colin
RTCv2 is draft driver for MCUs with hardware calendar.

Q: Will release 2.4 will support the RTC support waking the STM32 up from a low-power SUSPEND mode with sub-second precision?

Waking up with subsecond precision possible only on STM32F4x. But I can not imagine situations when that required. Can you provide example (just a curious)?

Sure.

• All battery-powered wireless devices in a wireless network will need to spend the great majority of the time sleeping, but synchronize wakeup times with their neighbors so they can perform radio communications during the brief wake-time.
• A battery-powered data logger device where the user has configured, say, a 10 Hz sample rate -- an accurate clock is desired, as well as low power consumption.
• Other event-driven applications will spend most of the time sleeping, but can be awakened by a wide range of application-level events; I could come up with many other specific examples where events should be delivered with finer-than-one-second precision.

For some time I have been working (under protest... die, 8051, die already!!) with the TI CC2430/CC2530, which are SOC devices consisting of an 8051 microcontroller with an integrated 2.4 GHz 802.15.4 radio. The 32.768 kHz timer, which functions as an binary RTC (no calendar functions, that's fine, I prefer my time binary), allows wakeup from sleep with high precision. It is critical to making energy-efficient applications -- nodes that run on a small battery for months or years. The Atmel ATmega microcontrollers with the “asynchronous timer/counter 2” support a 32.768 kHz RTC function (again, a binary RTC without Y-M-D H:M:S calendar stuff, but a linear, binary time is ideal for event-driven applications which use the timer heavily for event delivery, rather than just a long-term time-keeping device). The ATmega48/88/168/328 series has this TIMER2 support for a 32.768 kHz crystal, and the ATmega48 is the lowest-cost of all the AVRs supporting a 32.768 kHz timer, at least last time I checked. To get subsecond timekeeping and wakeup, I thought about making a peripheral RTC using an ATmega48 for my main Cortex-M3 MCU, but that really adds significant cost to the product since the ATmega48 likely costs more than a small 32-bit Cortex-M3 device...

Q: Is it possible to read the RTC time to millisecond precision?

Not all MCUs support it. For example STM32F1x and STM32F4x support it, but STM32F2x and STM32L1x not. Consult with reference manual on your MCU.

is there any resource or example to show how ChibiOS might support an application that needs to sleep in a low-power mode between handling events?

I do not know about resources but examples you can find in:
testhal\STM32F1xx\EXT_WAKEUP
testhal\STM32F1xx\RTC

Interesting, I thought F4, F2, and L1 used one RTC type and F1 used the other. I'll have to look at it in more detail.

[Giovanni]

Note that RTC support for L1, F2 and F4 (RTCv2 driver) is still work in progress and will not be included in 2.4.0. It will probably be introduced in 2.4.1.

Giovanni

[colin]

ChibiOS/RT does enter a low power mode in between interrupts when CORTEX_ENABLE_WFI_IDLE is enabled. The RTC wakeup should only be used for long sleep periods because the restart is slow.

“Slow” is relative. The wakeup from stop mode should take only 6 µs (see ST AN2629, Table 8). That wakeup time is of little consequence if the system is only waking up only once every 100 ms. Of course, you don't want to have an extra 6 µs delay in all context switching or something, so you are right that it requires some thought and care to manage what kind of idle policy is used.

[colin]

I can only speak for the STM32F1, but there are actually two ways to get sub-second resolution there. You can use a smaller prescaler, but since the external LSO clock is a 32768 kHz oscillator, I'd not change this value. Sub-second resolution can than be achieved by reading the prescaler counter register. (Setting the time is only possible for full seconds, but you can get around that by waiting until the second wraps)

Of cause you cannot wake up with sub-second resolution then. But wouldn't it be ok to stay awake for the whole second?

Unfortunately not. For low-power applications, one second is often an eternity. Many battery-powered devices need duty cycles of less than 1% in order to meet battery life requirements, and may need to wake up on schedule every few seconds to perform some action, possible synchronized to some event (such as to communicate with a neighboring radio node which is also sleeping 99% of the time).

Also be aware that you will have to correct your oscillator drift. With a standard crystal your time will be off by some ms within hours.

Sure, it is hard to get a very accurate clock for a long period of time. If nodes must synchronize, the algorithms will need to account for clock error. But the key is to get better than one second precision, even if you aren't accurate to one millisecond over the whole period. Also, if you really wanted good long-term accuracy, software based temperature compensation could be used to improve long-term accuracy of the clock.