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

[sdtbb]

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.

[Imen.D]

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.

[sdtbb]

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