Skip to main content
PAHA
Associate
April 5, 2023
Question

Why is RCC_FLAG_CPURST disabled by a #ifdef in the stm32h7xx_hal_rcc.h?

  • April 5, 2023
  • 4 replies
  • 1424 views

In the HAL Library for the STM32H7 familiy (version 1.11.0) downloaded with STMCubeMx there is the following entry in the stm32h7xx_hal_rcc.h file:

#if defined(RCC_RSR_CPURSTF) // <<---- This is the line in question
#define RCC_FLAG_CPURST ((uint8_t)0x91)
#endif /* RCC_RSR_CPURSTF */
 [...]
 
#define RCC_FLAG_C1RST (RCC_FLAG_CPURST)
#define RCC_FLAG_C2RST ((uint8_t)0x92)

In the stm32h755xx.h file the "RCC_RSR_CPURSTF" is not defined. Why is that?

According to the reference manual (RM0399, chapter 9.7.38) there is C1RSTF flag in the RCC_RSR register at bit position 17, which corresponds to the defined value above of 0x91 for RCC_FLAG_C1RST (if it was active) when using the Makro "__HAL_RCC_GET_FLAG(...)" to check wheter a C1RST occurred.

The above mentioned "#if defined(RCC_RSR_CPURSTF)   " was introduced after HAL Library version 1.5.0, where there was no such define.

When we are looking for example in the "stm32h753xx.h" device file, there this define is present:

#define RCC_RSR_CPURSTF_Pos (17U)
#define RCC_RSR_CPURSTF_Msk (0x1UL << RCC_RSR_CPURSTF_Pos) /*!< 0x00020000 */
#define RCC_RSR_CPURSTF RCC_RSR_CPURSTF_Msk

When we are looking in the "stm32h755xx.h" (which we are using) device file, the define appears but it is renamed:

#define RCC_RSR_C1RSTF_Pos (17U)
#define RCC_RSR_C1RSTF_Msk (0x1UL << RCC_RSR_C1RSTF_Pos) /*!< 0x00020000 */
#define RCC_RSR_C1RSTF RCC_RSR_C1RSTF_Msk

However, in the stm32h7xx_hal_rcc.h the #ifdef is still done for "RCC_RSR_CPURSTF" (see above).

Is this renaming of this flag an error in the HAL library for the STM32H755?

With the actual HAL library it is not possible to check if a C1RST occurred or not.

Any help is appreciated.

This topic has been closed for replies.

4 replies

Pavel A.
April 5, 2023

H753 is a single-core H7. The system reset internals in single and dual core H7's may differ.

Tesla DeLorean
Guru
April 5, 2023

This. The two cores have their own reset signals.

​

And be aware there have been multiple die stepping over several years of development, with added or resolved functionality.

​

The errata might be instructive. ​

Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
PAHA
PAHAAuthor
Associate
April 5, 2023

The two respective reset signals are

#define RCC_FLAG_C1RST (RCC_FLAG_CPURST)
#define RCC_FLAG_C2RST ((uint8_t)0x92)

Where RCC_FLAG_C1RST corresponds to RCC_FLAG_CPURST which should correspond to 0x91. However, the latter is not defined (falsly?) for the H755.

PAHA
PAHAAuthor
Associate
April 5, 2023

Yes I know that they may differ.

My point with the H753 was that "RCC_RSR_CPURSTF" is defined but the same information is named "RCC_RSR_C1RSTF" on the H755. However, in the stme32h7xx_hal_rcc.h the #ifdef is only performed on the "RCC_RSR_CPURSTF".

So the information

#define RCC_FLAG_CPURST ((uint8_t)0x91)

is not available for the H755 but it should be. Also the number (0x91) is correct for the H755.

Therefore my question, how do I check if a CR1RST reset cause happend for a H755 with the HAL library, without manually manipulating the library?