LPTIM_TypeDef contains incorrectly sized field uint16_t RESERVED1

[tarmasr]

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.

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

[STTwo-32]

Hello @tarmasr and welcome to the ST Community 😊.

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

[tarmasr]

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.

[tarmasr]

@STTwo-32 :  It happens in all the STM32CubeMX-related header files that define the LPTIM_TypeDef, for all STM32MP1xx MPUs and MCU that contain an LPTIM peripheral.

There are too many different header files to enumerate individually; I suggest that you just create a basic STM32CubeMX project for, say, the STM32MP157AAD3, let it generate the code (no need to add any of your own), and then do a search for LPTIM_TypeDef in the following folder:

Drivers/STM32MP1xx_HAL_Drivers/Inc

Look through the *.h header files in that directory for the LPTIM_TypeDef struct definition; you will find that they all use the same layout, as shown in my earlier screenshot.

Hope this helps.

[Pavel A.]

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 ?

[tarmasr]

@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 · Accepted solution]

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.