ChibiOS Free Embedded RTOS

I've been using standby mode for several years with some sub uA data loggers. The basic life cycle is

0. Wake from standby
1. Initialize the system
2. Determine wake up cause
3. Log some data
4. Go to standby

The data loggers have two wake up sources, an external sensor and an internal alarm. Recently I noticed some gaps in the data -- a few blocks out of thousands over many months. Fortunately, there's enough redundant information that no harm was done. Of course the first thing that comes to mind is a race condition -- the external sensor and the alarm are asynchronous to each other. In digging a bit, I have a clue as to what is going on. I had assumed that it was necessary to enable the alarm interrupts to wake from standby. The problem with this is that there is a window between waking from standby and initializing all the necessary interrupt configuration during which an alarm can be missed. It turns out that (as usual) standby is special :

Here are a couple of key bits of information from the stm32l432 reference manual (5.3.11)

"To wakeup from Standby mode, there is no need to configure the EXTI 18"
"To wakeup from Standby mode, there is no need to configure the EXTI Line 20."

So rather than doing what the hal RTC drivers do, which is initialize the alarm and the alarm interrupt

rtcp->rtc->CR |= RTC_CR_ALRAE;
rtcp->rtc->CR |= RTC_CR_ALRAIE;


the right course of action is just to initialize the alarm and not the interrupt:

rtcp->rtc->CR |= RTC_CR_ALRAE;

In my application, I poll the RTC isr register and it's relatively easy to clear only the bits that you "know" have been set. In this way no alarms will be missed.

It'd be nice if the hal didn't automatically enable interrupts when setting RTC alarms (and wakeup timer), but I can work around that by pulling the key bits directly into my application.

Standby mode is tricky and the documentation is literally scattered throughout the various STM reference documents.

This turned out to not be 100% correct. In the end I had to enable the interrupt at the RTC

rtcp->rtc->CR |= RTC_CR_ALRAIE;

and enable events (but not interrupts) for EXTI18 and EXTI20 (alarms and wakeup flag depending upon use). This required modifications to hal_rtc_lld.c for my application.

Hi,

I have not a clear idea of how it should be.

Giovanni

I'm not really suggesting a change. It's just that standby mode changes how events and interrupts should be handled -- in fact interrupts shouldn't be used at all for any wake up event. For example, in the case of using RTC events (alarms, timer) it's important not to initialize the interrupt handlers. By default rtc_lld_init() does initialize the handlers. To prevent this I needed to make my own version of hal_rtc_lld.c. I suppose one way to handle this is a compile time define:

#ifndef NO_RTC_INTERRUPTS
STM32_RTC_IRQ_ENABLE();
#endif

or some such thing.

However, my goal in posting was to alert the few of us using standby mode of a potential pitfall.