Skip to main content
Vladislav Yurov
Vladislav Yurov
Associate III
June 3, 2019
Question

Reserved bits of registers.

  • June 3, 2019
  • 2 replies
  • 1417 views

Hello, I have a question related to the reserved bits (generally to all of them). For example lets disscus specification of STM32F429 MCU from the RM0090:

Register TIMx_SR1 (of TIM2 to TIM5 for example) has specified bits 5, 7, 8, 13, 14, 15 as reserved. These bits should be kept at reset values.  Function from LL drivers:

__STATIC_INLINE void LL_TIM_ClearFlag_UPDATE(TIM_TypeDef *TIMx)
{
 WRITE_REG(TIMx->SR, ~(TIM_SR_UIF));
}

will write to SR register the value 0xFFFFFFFE. So it performs a write of '1' to mentioned above bits. Is it in conflict with RM specification?

Thank you.

This topic has been closed for replies.

2 replies

Ozone
Ozone
Principal
June 3, 2019

Laxity in such issues is a hallmark of Cube Code.

Such code tends to fall flat on it's face when porting to a MCU where some bits are not anymore reserved.

Bob S
Bob S
Super User
June 3, 2019

On the other hand, with this type of register ("write 0 to clear"), it would make more sense (to me, anyway) to write 1's to those unused bits. For any other STM32 variant that implements some of those reserved bits (the STM32L433, for example), I would fully expect them to be implemented as the same type of but (i.e. "write 0 to clear"), in which case masking the value written to that register to make "reserved" bits zero would fail by unexpectedly clearing other status bits on this "other" CPU.

Perhaps this is more a documentation "copy/paste/didn't edit" kind of oversight. For registers where bits enable/disable various features, it makes sense to write 0's to reserved bits. For registers where bits are set to zero to clear a status flag, writing zeros to reserved bits makes less sense.

Not that I'm necessarily defending the quality of the Cube code...

Terms & ConditionsAccessibility statement