Skip to main content
T
tarmasr
Associate II
November 10, 2023
Solved

LPTIM_TypeDef contains incorrectly sized field uint16_t RESERVED1

  • November 10, 2023
  • 3 replies
  • 4286 views

The LPTIM_TypeDef struct that is used throughout many of the HAL header files contains a few RESERVED fields that cover unused address offsets in the peripheral's memory map.

The first of these, RESERVED1, is declared as uint16_t. I believe that this is incorrect and that it should be a uint32_t field to ensure that the address offsets of the subsequent fields are correct.

LPTIM_TypeDef.png

Could someone please double-check and correct this if necessary?

This topic has been closed for replies.
Best answer by STTwo-32

Hi @tarmasr 

An internal ticket (ID166161) is submitted to escalate this issue internally for check and analysis.

(PS: ID166161 is an internal tracking number and is not accessible or usable by customers)

thank you for your contribution.

Best Regards.

STTwo-32.

3 replies

STTwo-32
STTwo-32
Technical Moderator
November 10, 2023

Hello @tarmasr and welcome to the ST Community :smiling_face_with_smiling_eyes:.

Thank you for reporting this. I will check it internally and get back to you as soon as possible. Can you just add more details (the product you are using, firmware version, ...).

Best Regards.

STTwo-32

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
T
tarmasrAuthor
Associate II
November 10, 2023

Thanks @STTwo-32 

The reason that this wasn't noticed before is probably because the C compiler will insert its own invisible 2-byte padding right after RESERVED1 to ensure that the next uint32_t data member is 4-byte aligned.

    Pavel A.
    Pavel A.
    Super User
    November 10, 2023

    In MPU headers yes, CA7 and CM4. For one here, line 2280

    https://github.com/STMicroelectronics/STM32CubeMP1/blob/master/Drivers/CMSIS/Device/ST/STM32MP1xx/Include/stm32mp151axx_ca7.h

    Line 2246

    https://raw.githubusercontent.com/STMicroelectronics/STM32CubeMP1/master/Drivers/CMSIS/Device/ST/STM32MP1xx/Include/stm32mp151cxx_cm4.h

     

    In MCU headers - at least not everywhere, see for example in STM32H7: uint32.

    https://raw.githubusercontent.com/STMicroelectronics/cmsis_device_h7/master/Include/stm32h723xx.h

    and not here: no reserved field at all:

    https://raw.githubusercontent.com/STMicroelectronics/cmsis_device_wb/master/Include/stm32wb5mxx.h

     

     

    @tarmasr 

    > The reason that this wasn't noticed before is probably because the C compiler will insert its own invisible 2-byte padding right after RESERVED1

    So how have you noticed it? Does it make any problem in your case? Do you use #pragma pack ?

    T
    tarmasrAuthor
    Associate II
    November 10, 2023

    @Pavel A.: I noticed it by inspection while working on an STM32MP157 project. I was trying to understand some third-party code and the uint16_t just jumped out.

    And no, I was using the default compiler settings, no special packing options.

    I mentioned the compiler's padding only because at first I could not understand how a 2-byte size mismatch could not have been spotted before; that's when I realized that the default compiler settings are probably pack(4) or greater, so that the next uint32_t field will be correctly aligned after all.

    However, that is a lucky coincidence really, not something to rely on.

    If other LPTIM_TypeDefs don't have the same issue, then that probably points to the faulty one being a copy & paste error when the STM32MP1xx header was created. As I said, I found it for STM32MP1xx devices; I didn't look at the STM32H or STM32WB families.

      STTwo-32
      STTwo-32Answer
      Technical Moderator
      November 13, 2023

      Hi @tarmasr 

      An internal ticket (ID166161) is submitted to escalate this issue internally for check and analysis.

      (PS: ID166161 is an internal tracking number and is not accessible or usable by customers)

      thank you for your contribution.

      Best Regards.

      STTwo-32.

      To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
      Terms & ConditionsAccessibility statement