RTC prescaler load register is always to default on RESET?

Posted on June 24, 2011 at 22:59

Any ideas?

Pretty sure it's preserved across the STANDBY condition. I think it's assumed you put the device to sleep, and later wake it up, not that the supply goes away and it comes back with a reset.

The RTC/BKP were very frustrating to deal with, and need different initialization depending on how the part is started.

Posted on June 25, 2011 at 01:32

Pretty sure it's preserved across the STANDBY condition. I think it's assumed you put the device to sleep, and later wake it up, not that the supply goes away and it comes back with a reset.

 

 

Unfortunately, this is the case with the main supply going off. A device has to keep the real time as long as the power supply is interrupted and resume the logging upon switched on. Well, I hope, when the main supply is off, the mentioned register value stays 7FFFh (but how to prove?), so the battery supported clock is quite exact. The main power going on, the register becomes 8000h but for very short time until the RTC is reinitialized by my code. I think, that couple of milliseconds does not play a crucial role while the known commercial 32.768kHz crystals are not pretty precise, but I was really surprised at the behavour of the prescale register that belongs to the back up domain.

Posted on June 25, 2011 at 04:26

The other thing to consider is that I think there are two sets of registers, the ones on the APB side (shadows), and the ones on the BKP side (functional). This is why you have the enables, and the synchronization between the sides. I'd be willing to bet only the APB side ones appear reset. The functional ones (ie being used) are not. You could test this by observing the tick rate after setting a stupidly low value in the prescaler, and then observing if after a reset it ticks in normal time, or the accelerated rate.

17.3.2 Resetting RTC registers

All system registers are asynchronously reset by a System Reset or Power Reset, except for RTC_PRL, RTC_ALR, RTC_CNT, and RTC_DIV.

The RTC_PRL, RTC_ALR, RTC_CNT, and RTC_DIV registers are reset only by a Backup Domain reset. Refer to Section 6.1.3 on page 82.

6.1.3 Backup domain reset

The backup domain has two specific resets that affect only the backup domain (see Figure 4).

A backup domain reset is generated when one of the following events occurs:

1. Software reset, triggered by setting the BDRST bit in the Backup domain control

register (RCC_BDCR).

2. VDD or VBAT power on, if both supplies have previously been powered off.

Posted on June 25, 2011 at 11:52

Hello, clive1.

You could test this by observing the tick rate after setting a stupidly low value in the prescaler, and then observing if after a reset it ticks in normal time, or the accelerated rate.

 

Thanks for the idea. I did it in the following way:

1). programmed a double value of the prescaler,

2). loaded the code and started,

3). by watching a LED, that flashed on every RTC tick, made sure, the RTC is slow,

4). commented the loading of the prescaler out,

5). loaded the new code and started again.

I saw, that the LED was still slow (VBAT was present all the time)!

Conclusions:

First:

6.1.3 Backup domain reset

..

2. VDD or VBAT power on, if both supplies have previously been powered off.

 

 

seems to be true, because I've got VBAT applied all the time.

Second:

Upon restart the debugger shows/the APB1 register has a value (8000h) that does not correspond the actual value of the ''backup'ed'' prescaler despite the fact that I call ''RTC_WaitForLastTask()'' after     ''RCC_APB1PeriphClockCmd(RCC_APB1Periph_BKP | RCC_APB1Periph_PWR, ENABLE)'' and ''PWR_BackupAccessCmd(ENABLE)''.

The device was running this night w/o main power; after start up it showed quite exact time (maybe +/- 2 seconds).

Being battery supplied, prescaler KEEPS its value of 7FFFh!

Posted on June 28, 2011 at 12:53

Hello,

On rev 12 of RM0008 manual, §18.4.3 (page 471), the description of PRLH and PRLL notes that these registers are write only. So I think that the value readed by the debugger is not valid. Even when debugger or program reads 8000h, the prescaler can be at 7FFFh.

Best regards

Eric

Posted on June 28, 2011 at 14:25

On rev 12 of RM0008 manual, §18.4.3 (page 471), the description of PRLH and PRLL notes that these registers are write only.

Hm, indeed. I wonder now, why I see 7FFFh after writing this value to the register on debugging. Debugger is too helpful? (KEIL).