RTC shadow register incosistent readings

[jotamudo]

Greetings!
So I've been playing a little with a pyboard-sf2 and eventually noticed some weird "skips" on a seconds counter before the subsseconds had finished counting a roll-over, as an example (I hadn't synchronized the RTC to the pc's clock):

# two rtc.datetime() consecutive calls:
(2015, 1, 1, 4, 1, 8, 38, 999755) -> (2015, 1, 1, 4, 1, 8, 39, 999877)
# the seconds counter goes up a second before the subseconds had finished, the subseconds catches up later:
(2015, 1, 1, 4, 1, 8, 39, 999877)
(2015, 1, 1, 4, 1, 8, 39, 7934)

I had the suspicion that something was weird with these "jumps" and found them by leaving a board thorough a whole night running a continuous comparison between the rtc time-delta and the ticks_us time-delta, and apparently it's the case for every stm32 RTC series launched before 2016: http://www.efton.sk/STM32/gotcha/g82.html

Now I don't know if it's plausible (or desireable) to include a fix-up, but I've succesfully fixed the error locally by modifying a little the code provided here, more specifically by starting the readings by the subsecond counter instead of the date/time register with the shadow register lock mechanism disabled:

// added on PYB_RTC_Init on STM32F7 section, disables the lock mechanism
hrtc->Instance->CR |= (uint32_t) RTC_CR_BYPSHAD;

// ripped from a local version of ports/stm32/rtc.c on pyb_rtc_datetime
volatile uint32_t subsec,  timereg,  datereg;
volatile uint32_t subsec2, timereg2, datereg2;
do
{
    subsec   = RTC->SSR;
    timereg  = RTC->TR;
    datereg  = RTC->DR;

    subsec2  = RTC->SSR;
    timereg2 = RTC->TR;
    datereg2 = RTC->DR;
} while (datereg != datereg2 ||
         timereg != timereg2 ||
         subsec  != subsec2
        );

uint8_t year =    (uint8_t)((datereg & (RTC_DR_YT | RTC_DR_YU)) >> 16);
uint8_t month =   (uint8_t)((datereg & (RTC_DR_MT | RTC_DR_MU)) >> 8);
uint8_t day =    (uint8_t)(datereg & (RTC_DR_DT | RTC_DR_DU));
uint8_t weekday = (uint8_t)((datereg & (RTC_DR_WDU)) >> 13);

uint8_t hours = (uint8_t)((timereg & (RTC_TR_HT | RTC_TR_HU)) >> 16);
uint8_t minutes = (uint8_t)((timereg & (RTC_TR_MNT | RTC_TR_MNU)) >>8);
uint8_t seconds = (uint8_t)(timereg & (RTC_TR_ST | RTC_TR_SU));
uint32_t subsecs = rtc_subsec_to_us(subsec);
mp_obj_t tuple[8] = {
    mp_obj_new_int(2000 + RTC_Bcd2ToByte(year)),
    mp_obj_new_int(RTC_Bcd2ToByte(month)),
    mp_obj_new_int(RTC_Bcd2ToByte(day)),
    mp_obj_new_int(weekday),
    mp_obj_new_int(RTC_Bcd2ToByte(hours)),
    mp_obj_new_int(RTC_Bcd2ToByte(minutes)),
    mp_obj_new_int(RTC_Bcd2ToByte(seconds)),
    mp_obj_new_int(subsecs)
};
return mp_obj_new_tuple(8, tuple);

I've searched a bit and didn't find any issue mentioning this RTC detail ( #12957 may be related?) but found that it'd be nice to have a discussion to whether it's best to include it directly into the c module, do you guys have any position over it?