2020-08-20 02:52 PM
I'm asking because I'm reading the page 533 of the manual of my Nucleo L152-RE
"""
After system reset, the RTC registers are protected against parasitic write access with the DBP bit of the PWR power control register (PWR_CR). The DBP bit must be set to enable RTC registers write access.
After power-on reset, all the RTC registers are write-protected. Writing to the RTC registers is enabled by writing a key into the Write Protection register, RTC_WPR.
The following steps are required to unlock the write protection on all the RTC registers except for RTC_ISR[13:8], RTC_TAFCR, and RTC_BKPxR.
1. Write ‘0xCA’ into the RTC_WPR register.
2. Write ‘0x53’ into the RTC_WPR register. Writing a wrong key reactivates the write protection.
The protection mechanism is not affected by system reset
If I want to be able to write to some of the RTC registers to program an RTC wakeup event, what do I need to do here? Both things? Set the DBP bit of the PWR_CR to 1 and then write those 0xCA and 0x53 to the RTC_WPR register?
2020-08-20 06:39 PM
It generates a low signal on NRST, which is a bidirectional signal (ie the STM32 can pull it low related to BOR or watchdog, etc)
The MCU will basically get a non-maskable interrupt to Reset_Handler, and most CPU and peripheral registers will be reset. SRAM will typically retain content, where as a power cycle will give you non-specific data. Some startup code can clear memory as part of its process.
My recollection is that you will need to unlock access to the RTC, but you'll not want to reset it.
Have the MCU output diagnostic/telemetry data to a serial port that you can inspect independently of the debugger. This will allow you to confirm and test your understanding of different behaviours and operating modes.
2020-08-20 06:40 PM
Refer also to the L1 RTC/WAKEUP code examples in the HAL/Cube libraries, and perhaps the older SPL, as these augment the descriptions in the Reference Manual with more practical application.
2020-08-20 06:41 PM
Toggling NRST is a "system reset" and not necessarily a "power-on reset".
Yes, both are required. See the example here (RTC_Config function):
2020-08-24 03:58 PM
I tried to set the DBP bit of the PWR_CR register to 1 but this failed (PWR_CR is not modified). Consequently writing to the RTC registers such as RTC_WPR also fails.
I searched about this issue in the manual and stumbled on this on page 100:
"""
RTC registers access
After reset, the RTC Registers (RTC registers and RTC backup registers) are protected against possible stray write accesses. To enable access to the RTC Registers, proceed as follows:
1. Enable the power interface clock by setting the PWREN bits in the RCC_APB1ENR register.
2. Set the DBP bit in the PWR_CR register (see Section 5.4.1).
3. Select the RTC clock source through RTCSEL[1:0] bits in RCC_CSR register.
4. Enable the RTC clock by programming the RTCEN bit in the RCC_CSR register.
Do you think I need to enable the power interface clock to be able to modify the PWR_CR register? What is the power interface clock?
And I have to select a clock source?
I'll have to wait until tomorrow before I can make further tests.
2020-08-24 04:07 PM
>>Do you think I need to enable the power interface clock to be able to modify the PWR_CR register? What is the power interface clock?
Yes, synchronous logic tends to want a clock, this is the bus side of the peripheral, and you want to talk to it.
>>And I have to select a clock source?
I think that's the LSI vs LSE choice. The reference manuals tend to have block diagrams, showing things like clock trees, showing what sources connect to what. The peripheral sections of the manual go deeper into detail.
/* Enable Power Control clock */
__HAL_RCC_PWR_CLK_ENABLE();
2020-08-25 09:22 AM
Thanks, I'm going to read about synchronous logic and about the bus. I wonder what are those things and why they need a clock. It seems I'm about to learn something fundamental about microcontrollers. Thanks again.