2023-11-10 05:01 AM
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?
Solved! Go to Solution.
2023-11-13 06:19 AM
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.
2023-11-10 05:09 AM - edited 2023-11-10 05:15 AM
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.
2023-11-10 05:16 AM
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.
2023-11-10 05:25 AM
@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.
2023-11-10 06:00 AM - edited 2023-11-10 07:07 AM
In MPU headers yes, CA7 and CM4. For one here, line 2280
Line 2246
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
> 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 ?
2023-11-10 08:39 AM
@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.
2023-11-13 06:19 AM
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.