STM32L053R8 Reset identification register can't be cleared

[danq]

Posted on September 25, 2014 at 22:36

Hi all,

After reading the RCC_CSR register to determine the reset source, I want to clear the register so as to be able to resolve future non-por resets.  When I follow the instructions in the datasheet, the bits do not clear. Here is the code sequence that I use:

RCC

->

CSR

|=

(1U <<

24

)

;

// RMVF : Clear reset flags

RCC

->

CSR

&=

~(1U <<

24

)

;

The data sheet is not clear on exactly how to use this bit. It says to set the bit, but does not specify if the bit will reset automatically or if it needs to be explicitly cleared afterward.I have tried both cases and still, the flags do not reset.Also, I am able to determine POR and SOFWARE reset, but when I drive the external reset pin, the PIN reset flag is not set.Has anyone else had this problem?I have looked at the errata for this device and the only thing related is a need for a work-around delay when enable the RCC clock.I suspect I am missing something and that somehow these bits a write-protected.Any hints, solutions, etc. would greatly by appreciated. #poor-quality-of-documentation #reset-id-flags-clear

[waclawek.jan]

Posted on September 26, 2014 at 08:47

Quick experimentation (albeit on a STM32F4) revealed, that:

- the reset-source bits can't be written - the RMVF bit is auto-cleared, i.e. it's enough to write 1, and this cleared the reset bits for me Thus, I'd try RCC->CSR = 1 << 24; (or, more precisely, I'd do RCC->CSR = RCC_CSR_RMVF), but I honestly fail to see why wouldn't your sequence do the same. I did not experiment with the reset input. The documentation is hopeless. JW

[John F.]

Posted on September 26, 2014 at 12:33

The Reference Manual RM0367 DocID025274 Rev 2 p189/897 says,

Bit 24 RMVF: Remove reset flag This bit is set by software to clear the reset flags. 0: No effect 1: Clear the reset flags That looks clear to me - where ''set by software'' means you do it, the hardware doesn't.

[danq]

Posted on September 26, 2014 at 15:57 I found the problem and it is with the datasheet.  The bit positions defined in the datasheet do not match those defined in the device header file.  When I use RCC->CSR = RCC_CSR_RMVF, it works. This too, is not entirely correct.  I have to do RCC->CSR |= RCC_CSR_RMVF to ensure the reserved bits are not modified.  Also the RTC bits did not get modified by the first method because they are write protected and need to be unlocked. A direct write will work, but lead to some really hard to find bugs if ever the RTC registers need to be unlocked and accessed. Dam you documentation!!!!!!! Thanks to all who replied.

[Tesla DeLorean]

Posted on September 26, 2014 at 16:21

The header files often have ''encoded'' bits, indexes and masks, so one shouldn't assume a one-to-one relationship between encodings the peripheral library utilizes with the bits in the registers as described by the Reference Manual.

Doing a RMW &= ~X isn't going to set desired bits to ONE

[waclawek.jan]

Posted on September 29, 2014 at 10:14

> I found the problem and it is with the datasheet. 

> The bit positions defined in the datasheet do not match those defined in the device header file.  >When I use RCC->CSR = RCC_CSR_RMVF, it works. A bug in the RM indeed. Not the first one... :( JW

[Amel NASRI]

Posted on October 02, 2014 at 12:51

A bug in the RM indeed. Not the first one... :(

In stm32l053xx.h file, RCC_CSR_RMVF value is ''0x00800000''. It corresponds to bit 24 of the reference manual.Am I wrong with RM bug you are reporting?-Mayla-

[waclawek.jan]

Posted on October 02, 2014 at 16:01

In my calculator, when I type in 1<<24 , it results in 0x01000000... 😉

Jan

[danq]

Posted on October 08, 2014 at 03:09

The value in my header file is the correct one.  It is the datasheet that shows the wrong bit position.

Cheers! Dan