Skip to main content
Associate III
December 4, 2025
Question

Possible bug in IS_OB_USER_TYPE() for STM32L496/4A6 ? (Cube 1.19, stm32l4_hal_flash.h)

  • December 4, 2025
  • 2 replies
  • 382 views

In stm32l4_hal_flash.h:

#if defined (STM32L4P5xx) || defined (STM32L4Q5xx) || defined (STM32L4R5xx) || defined (STM32L4R7xx) || defined (STM32L4R9xx) || defined (STM32L4S5xx) || defined (STM32L4S7xx) || defined (STM32L4S9xx)
#define IS_OB_USER_TYPE(TYPE) (((TYPE) <= (uint32_t)0xFFFFU) && ((TYPE) != 0U))
#elif defined(STM32L471xx) || defined(STM32L475xx) || defined(STM32L476xx) || defined(STM32L485xx) || defined(STM32L486xx) || defined(STM32L496xx) || defined(STM32L4A6xx)
#define IS_OB_USER_TYPE(TYPE) (((TYPE) <= (uint32_t)0x1FFFU) && ((TYPE) != 0U))
#else
#define IS_OB_USER_TYPE(TYPE) (((TYPE) <= (uint32_t)0x7E7FU) && ((TYPE) != 0U) && (((TYPE)&0x0180U) == 0U))
#endif

The problem is that the L496/4A6 both have nSWBOOT0 and nBOOT0 option bits:

#if defined (STM32L412xx) || defined (STM32L422xx) || defined (STM32L431xx) || defined (STM32L432xx) || defined (STM32L433xx) || \
 defined (STM32L442xx) || defined (STM32L443xx) || defined (STM32L451xx) || defined (STM32L452xx) || defined (STM32L462xx) || \
 defined (STM32L496xx) || defined (STM32L4A6xx) || defined (STM32L4P5xx) || defined (STM32L4Q5xx) || defined (STM32L4R5xx) || \
 defined (STM32L4R7xx) || defined (STM32L4R9xx) || defined (STM32L4S5xx) || defined (STM32L4S7xx) || defined (STM32L4S9xx)
#define OB_USER_nSWBOOT0 ((uint32_t)0x2000) /*!< Software BOOT0 */
#define OB_USER_nBOOT0 ((uint32_t)0x4000) /*!< nBOOT0 option bit */
#endif

These two bits are outside the defined range for the L496/4A6 (0x1FFF) so  assert_param(IS_OB_USER_TYPE(UserType)); is incorrectly triggered.

I think a new definition of IS_OB_USER_TYPE is required, specifically for the 496/4A6:

#elif defined(STM32L496xx) || defined(STM32L4A6xx)
#define IS_OB_USER_TYPE(TYPE) (((TYPE) <= (uint32_t)0x7FFFU) && ((TYPE) != 0U))
#else

Can anyone sanity check this - if this is a real bug I'll copy this description to the CubeL4 repo. Thanks.

2 replies

Technical Moderator
December 5, 2025

Hello @sdtbb 

Thank you for having reported this issue.

Looks like you're right. If the IS_OB_USER_TYPE macro for STM32L496xx/STM32L4A6xx is limited to 0x1FFF, it would exclude nSWBOOT0 (0x2000) and nBOOT0 (0x4000), which are valid for these devices.

The macro should be updated to include these bits. For that, I've escalated this issue internally through Internal ticket number: 223341 (Ticket number is only for reference, not available outside of ST)

Thank you for your contribution.

 

"When your question is answered, please close this topic by clicking ""Accept as Solution"".ThanksImen"
sdtbbAuthor
Associate III
December 5, 2025

Thanks @Imen.D ,

Please note that my original post was flagged as inappropriate for unknown reasons and temporarily deleted from this message board, and I was not certain it would be restored so I reported the bug via github:

https://github.com/STMicroelectronics/stm32l4xx-hal-driver/issues/25

I figured I should let you know to prevent duplication of effort at ST.

Thanks

Sean

Technical Moderator
December 7, 2025

Hi @sdtbb ,

Thanks for reporting this issue and for letting me know about the duplication report.

"When your question is answered, please close this topic by clicking ""Accept as Solution"".ThanksImen"