LL_MPU_ATTRIBUTES_NUMBERx possible bug in STM32Cube_FW_H5_V1.5.0

[TThan]

Hi,

I am using STM32Cube_FW_H5_V1.5.0.

I initialize a MPU region with the following code, using only LL-calls:

LL_MPU_ConfigRegion(LL_MPU_REGION_NUMBER6, LL_MPU_REGION_PRIV_RW|LL_MPU_INSTRUCTION_ACCESS_DISABLE|LL_MPU_ACCESS_NOT_SHAREABLE, LL_MPU_ATTRIBUTES_NUMBER2, 0x90000000U, 0x9FFFFFFFU);

The corresponding MPU register MPU_RLAR_Ax gets set to 0x9FFFFFE3, wich is obviously wrong because I wanted to select attribute#2 and instead the attribute field gets set to 0x1.

For verification I did the same initialization using HAL-calls:

MPU_Region_InitTypeDef       region;
region.Enable           = MPU_REGION_ENABLE;
region.Number           = MPU_REGION_NUMBER6;
region.AttributesIndex  = MPU_ATTRIBUTES_NUMBER2;
region.BaseAddress      = 0x90000000U;
region.LimitAddress     = 0x9FFFFFFFU;
region.AccessPermission = MPU_REGION_PRIV_RW;
region.DisableExec      = MPU_INSTRUCTION_ACCESS_DISABLE;
region.IsShareable      = MPU_ACCESS_NOT_SHAREABLE;
HAL_MPU_ConfigRegion(&region);

Now the MPU register MPU_RLAR_Ax gets set to the correct value of 0x9FFFFFE5.

I think the bug is within the LL_MPU_ConfigRegion() code. The current implementation of this function in fw1.5.0 is:

__STATIC_INLINE void LL_MPU_ConfigRegion(uint32_t Region, uint32_t Attributes, uint32_t AttrIndx, uint32_t BaseAddress,
                                         uint32_t LimitAddress)
{
  /* Set region index */
  WRITE_REG(MPU->RNR, Region);

  /* Set region base address and region access attributes */
  WRITE_REG(MPU->RBAR, ((BaseAddress & MPU_RBAR_BASE_Msk) | Attributes));

  /* Set region limit address, memory attributes index and enable region */
  WRITE_REG(MPU->RLAR, ((LimitAddress & MPU_RLAR_LIMIT_Msk) | AttrIndx | MPU_RLAR_EN_Msk));
}

where line 11 should be changed to:

  WRITE_REG(MPU->RLAR, ((LimitAddress & MPU_RLAR_LIMIT_Msk) | (AttrIndx << 1) | MPU_RLAR_EN_Msk));
}

A change of the LL_MPU_ATTRIBUTES_NUMBERx definitions might be another option to solve this, but might have a major impact on the rest of the firmware pack since these definitions are used in a lot of places.

Thank you very much for confirming this bug. If it is a real bug and not a miss-interpretation on my side I would be very happy to see it fixed eventually.

Best Regards

  Thomas

[SirineST · Accepted solution]

Hello @TThan 

Thank you for reporting this point. An internal ticket is created in order to investigate and fix this potential defect (ticket number 215184)

With regards