HAL_SRAM_Write_16b is 32b

[julpage]

The function _HAL_SRAM_Write16b in _stm32f4xx_halsram.c

HAL_StatusTypeDef HAL_SRAM_Read_16b(SRAM_HandleTypeDef *hsram, uint32_t *pAddress, uint16_t *pDstBuffer,
                                    uint32_t BufferSize)
{
  uint32_t size;
  __IO uint32_t *psramaddress = pAddress;
  uint16_t *pdestbuff = pDstBuffer;
  uint8_t limit;

psramaddress was declare as ___IO uint32t instead of _uint16t.

It cause problem when use this function to drive lcd screen.

[RJMSTM]

Hello @Jasoji,

Thank you for this report. We will get back to you as soon as we analyze it further. This may take some time. Thank you for your comprehension.

With regards,

[julpage]

BTW, this function works correct at FW_F4 V1.24.0

[TOUNSTM]

Hello @Jasoji,

Thank you for your contribution. Would it be possible to share the project you have used to reproduce the issue in order to allow a better analysis of the problem.

With regards,

[julpage]

Hello @TOUNSTM,

project is here https://github.com/Jasoji/asdfzxcv

lcd screen controller is ili9486, 320*480.

you can see everytime I call _HAL_SRAM_Write16b, param BufferSize is 1. It trigger several times 32bit transfer action on bus.

but for screen control, I only need once 16bit data transfer.

[TOUNSTM]

Hello @jasoji,

This fix has been implemented in the context of MISRAC 2012 (Rule-10.3) as there is an implicit conversion of *pAddress from unsigned 32-bit int type to a narrower unsigned 16-bit int type. What's more, this change has no impact on our projects. As you are already using theili9486 component, which is not supplied in our STM32CubeF4. You should correct this on your side. Please allow me to close this thread.

Thank you again for your report. We are looking forward to reading from you again.

With Regards,