STM32L052 - RTC with implausible or Zero - Content after RESET due to leaving the standby mode by recognizing of level LOW on RTC-TAMP1 (PC13)

[FEber.1]

The tamper contact RTC.TAMP1 on PC13 is used for entering and leaving the standby modus in tamper - level - detection - mode. The detection of low level on RTC-TAMP1 finishes the standby mode and restarts the controller. That is all OK. but in about 30% of cases the test of RTC - data - plausibility fails. Either the RTC-shadow-registers contain implausible data e.g. seconds > 59 or all registers have the content = 0. VDD, VDD-USB and VDDA are all connected together and buffered by a battery. VDD dont't fall below 2,8V.

From the RTC still the Alarm A and the Autowakeup - function are used. These interrupts are switched off before entering the standby mode. The time stamp function of the tamper contact is not used.

Another phenomenon is the necessity to reinitialize the RTC so that the alarm A and the wakeup interrupt run again although all RTC registers still have the expected contents after reset.

I have no idea which reason could force the damaging of the RTC content and need help or experience respectively for solving the problem.

[MM..1]

When i understand TAMPER , then is for erase secure data in backup regs on tampering event, code is real run.

For waking up is other designed pins and standby mode reboot is defined in pdf .

[waclawek.jan]

Do you follow this procedure?

 

JW

[FEber.1 · Accepted solution]

Hello Jan,

many thanks for our answer. Indeed I forgot to trigger the synchronizing of shadow registers an implemented the missing

instructions now:

void TriggerSynchroShadowRegs (void)

{

   WRITE_REG(RTC->WPR, 0xCA);      // Unlock the write protection

   WRITE_REG(RTC->WPR, 0x53);

   RTC->ISR &= ~(RTC_ISR_RSF);

   while (0==(RTC->ISR & RTC_ISR_RSF))

   {};

   WRITE_REG(RTC->WPR, 0xFF);      //Lock the write protection

}

But I couldn't realy remove the fault. Sometimes I read out false seconds

like "85" etc. It's a miracle.

[waclawek.jan]

Reading out the RTC *before* going to sleep, using the same method, does result in always correct time?

How exactly do you read out and check it? Post code.

JW

[FEber.1]

You are right. In the real world, tamper is not intended to detect voltage changes. However, I like the energy-saving detection with temporarily activated pull-ups and therefore decided to use this feature for voltage ON/ OFF detection. 

[FEber.1]

Hi Jan,

many thanks for the good hint.

Your suspicion was right.

The fault isn't cause during standby.

In case of reading the RTC before entering the standby mode the I found the error too.

I use the following function:

void RTCReadBackTimeAndDate(uniTime *uTime)

{

   u32 u32Help;

   u8 u8Help;

   // Extract digits from the RTC time register

   u32Help = RTC->TR;            //Date register wil be frozen until it is read

   u8Help = ((u32Help & RTC_TR_HT) >> RTC_TR_HT_Pos)<<4;

   u8Help += ((u32Help & RTC_TR_HU) >> RTC_TR_HU_Pos);

   uTime->s.hour = u8Help;

   u8Help = ((u32Help & RTC_TR_MNT) >> RTC_TR_MNT_Pos)<<4;

   u8Help+= ((u32Help & RTC_TR_MNU) >> RTC_TR_MNU_Pos);

   uTime->s.min = u8Help;

   u8Help = ((u32Help & RTC_TR_ST) >> RTC_TR_ST_Pos)<<4;

   u8Help+= ((u32Help & RTC_TR_SU) >> RTC_TR_SU_Pos);

   uTime->s.sec = u8Help;

   u32Help = RTC->DR;

   u8Help = ((u32Help & RTC_DR_YT) >> RTC_DR_YT_Pos)<<4;

   u8Help += ((u32Help & RTC_DR_YU) >> RTC_DR_YU_Pos);

   uTime->s.year = u8Help;

   u8Help = ((u32Help & RTC_DR_MT) >> RTC_DR_MT_Pos)<<4;

   u8Help+= ((u32Help & RTC_DR_MU) >> RTC_DR_MU_Pos);

   uTime->s.month = u8Help;

   u8Help = ((u32Help & RTC_DR_DT) >> RTC_DR_DT_Pos)<<4;

   u8Help+= ((u32Help & RTC_DR_DU) >> RTC_DR_DU_Pos);

   uTime->s.day = u8Help;

   u8Help = ((u32Help & RTC_DR_WDU) >> RTC_DR_WDU_Pos);

   uTime->u8Byte[6] = u8Help;

}

[FEber.1]

Hi Jan,

the real solution of my originally problem was your hint concerning the treatment of RTC_ISR_RSF.

The other problem was a very embarrassing mistake of mine:

I always overlooked that the RTC keeps BCD values and not binary values.

The interpretation of BCD numbers as binary numbers then led to unexpected changes of the numbers.

Sorry for this stupid mistake!

[waclawek.jan]

Thanks for coming back with the solution. We all make mistakes.

JW