[B-L072Z-LRWAN1] - RTC alarm failure when timeout <= 2 #1002

jelledevleeschouwer · 2020-12-08T15:25:13Z

jelledevleeschouwer
Dec 8, 2020

Dear,

We found ourselves in a situation where an RTC alarm fails randomly if and only if, the alarm is scheduled less or equal than 2 RTC subseconds in the future. To schedule this alarm we directly use RtcStartAlarm from rtc-board.c:

LoRaMac-node/src/boards/B-L072Z-LRWAN1/rtc-board.c

Line 324 in 184039f

void RtcStartAlarm( uint32_t timeout )

Despite the fact we haven't found the root cause for this problem yet, it appears you had a somewhat similar experience. Indeed, on the following lines

LoRaMac-node/src/system/timer.c

Line 335 in b0a91e0

minValue = RtcGetMinimumTimeout( );

and

LoRaMac-node/src/system/timer.c

Line 367 in b0a91e0

int32_t minTicks= RtcGetMinimumTimeout( );

of timer.c, the code invokes a function called RtcGetMinimumTimeout. Where RtcGetMinimumTimeout defined in rtc-board.c

LoRaMac-node/src/boards/B-L072Z-LRWAN1/rtc-board.c

Lines 235 to 238 in 184039f

    
           uint32_t RtcGetMinimumTimeout( void ) 
        
           { 
        
               return( MIN_ALARM_DELAY ); 
        
           }

returns the magic value of 3:

LoRaMac-node/src/boards/B-L072Z-LRWAN1/rtc-board.c

Line 39 in 184039f

#define MIN_ALARM_DELAY 3 // in ticks

The return value of the function call is used to prevent any RTC alarm to be configured with an RTC subsecond value any less than 3 in timer.c. The introduction of this RtcGetMinimumTimeout we traced back to commit 9091bb2 dating from July 2, 2018 augmented by a comment Originally posted by @mluis1 in #473 (comment).

The only plausible explanation that we have for this issue until now, is that ST mentions in the reference manual in
section 26.4.7 RTC initialization and configuration, in the paragraph about 'Programming the alarm' on page 616 [RM0376, DocID025941 Rev 5], the following:

  > Each change of the RTC_CR register is taken into account after
  > around 2 RTCCLK clock cycles due to clock synchronization.

But, according to the block diagram on page 610 (26.4.1) of that same document, RTCCLK clearly points to the LSE input which is 32.768 kHz. So we would expect a synchronization delay of 2 / 32768 s , which would clearly not have an impact on a RTC alarm scheduled 2 subseconds (2 / (32768 / (1 << ( 15 - N_PREDIV_S ))) = 2 / 1024 s) in the future. However, if ST has made a mistake here, and RTCCLK should actually refer to the asynchronously prescaled clock 'ck_apre'. That could perfectly explain why an RTC alarm of 2 RTC subseconds in the future would very randomly fail.

Do any of you guys know why exactly that RtcGetMinimumTimeout was introduced? Because this smells like we have experienced exactly the same issue here.