MISRA C Compliance

[thebruce87m]

Hi All,

I have come across the following information:

• The STM32L4/L4+ HAL and low-layer drivers User manual UM1884 available here states that the HAL- and LL-driver source are MISRA C:2004 compliant and is checked with CodeSonar.
• Running PC-Lint 9.00L in the same manner as CMSIS described here: link gives a large number of non conformances for both MISRA C:2004 and MISRA C:2012 .
• On the ST forums, a post states "A MISRA validation report is available on request from your ST contact." link

I don't have access to CodeSonar but pc-lint is an industry standard tool for checking MISRA compliance and indeed used by ARM to check CMSIS so I trust the results.

The PC-Lint tool gives multiple violations for the HAL library, for example the code below in stm32l4xx_hal_i2c.c:

HAL_StatusTypeDef HAL_I2C_Init(I2C_HandleTypeDef *hi2c)
{
  /* Check the I2C handle allocation */
  if (hi2c == NULL)
  {
    return HAL_ERROR;
  }

  /* Check the parameters */
  assert_param(IS_I2C_ALL_INSTANCE(hi2c->Instance));
  assert_param(IS_I2C_OWN_ADDRESS1(hi2c->Init.OwnAddress1));
  assert_param(IS_I2C_ADDRESSING_MODE(hi2c->Init.AddressingMode));
  assert_param(IS_I2C_DUAL_ADDRESS(hi2c->Init.DualAddressMode));
  assert_param(IS_I2C_OWN_ADDRESS2(hi2c->Init.OwnAddress2));
  assert_param(IS_I2C_OWN_ADDRESS2_MASK(hi2c->Init.OwnAddress2Masks));
  assert_param(IS_I2C_GENERAL_CALL(hi2c->Init.GeneralCallMode));
  assert_param(IS_I2C_NO_STRETCH(hi2c->Init.NoStretchMode));

...

  return HAL_OK;
}

Shows multiple return statements in the function HAL_I2C_Init(). PC-Lint shows this as an error below:

    return HAL_ERROR;
    ^
..\Drivers\STM32L4xx_HAL_Driver\Src\stm32l4xx_hal_i2c.c(477,0): Note 904: Return statement before end of function 'HAL_I2C_Init(I2C_HandleTypeDef *)'
    [MISRA 2004 Rule 14.7, required]"

So my questions are:

• Are the libraries truly MISRA C:2004 compliant?
• Is it possible to get instructions on how to run a MISRA tool against the libraries?
• If we can't get a tool to pass the libraries, do we just rely on a validation report?

[ALABSTM]

Hi @thebruce87m,

Thank you for reporting this issue. It will be forwarded to our development teams. I will let you updated as soon as they provide me with their feedback. Thank you for your patience.

Take care and stay safe.

With regards,

[ALABSTM]

Hi @thebruce87m,

Thank you again for both reports, this one on GitHub and the other on the ST Community forum.

To answer your first question, I confirm that our STM32L4/L4+ HAL- and LL-driver source are MISRA C:2004 compliant. However, compliance does not necessarily mean strict and absolute conformity to all rules.

• Indeed, there are mandatory rules which we have to guarantee our drivers comply to.
• But there are also required and advisory rules which we always try to comply to, unless doing so would degrade some quality aspects like code readability, for instance.
  • Such cases are not frequent (although it might look so when reading the PC-Lint report you shared with the ST Community).
  • Anyway, in such cases, a waiver (or derogation) is documented - in conformity with the MISRA C guidelines - with the rationale justifying the deviation.

Regarding the way to perform MISRA C checks on our HAL- and LL-driver, there are no particular instructions. We use the check mechanism offered by IAR's IDE as briefly explained from page 5 to page 7 (Implementation and interpretation of the MISRA C rules) of this document.

Regarding the obtention of a MISRA C check report, it is possible under the condition a NDA (Non-Disclosure Agreement) is signed by the requester.

Please allow me now these few comments on the PC-Lint report you shared with the ST Community:

• Deviations reported are mainly related to rules 2.2 (52%), 14.2 (18%), and 14.7 (12%) out of 2075 reported deviations. All these rules are required ones.
• Moreover, many error messages are redundant.
• Regarding rule 2.2 (source code shall only use / ... / style comments), reported deviations are mainly related to the stm32l4xx_hal_conf.h file (92%) out of 1079 reported deviations (including redundant ones).
  • These messages correspond to the modules selection lines (shown in the code snippet below).
  • Among the stm32l4xx_hal_conf.h files included in our examples, I could not find non-compliant C-style comments.
  • In case I missed some, I do apologize for the foresight.
  • Do not hesitate to report it. They would be fixed in a future release.
  • In case you customized the stm32l4xx_hal_conf_template.h for the need of your application, would it be possible that you used non-compliant C-style comments? https://github.com/STMicroelectronics/STM32CubeL4/blob/1ebb94256904a8b081e38caaffd4da7c2003136e/Drivers/STM32L4xx_HAL_Driver/Inc/stm32l4xx_hal_conf_template.h#L33-L42
• Regarding rule 14.2 (all non-null statements shall have a side-effect), the error messages seem to be related to the use of the assert_param(exp) macro.
  • Indeed, in case symbol USE_FULL_ASSERT is not defined at your project level, the macro is replaced by the no-side-effect statement ((void)0U).
  • Below are the two possible definitions of this macro. https://github.com/STMicroelectronics/STM32CubeL4/blob/1ebb94256904a8b081e38caaffd4da7c2003136e/Drivers/STM32L4xx_HAL_Driver/Inc/stm32l4xx_hal_conf_template.h#L457-L471
• Regarding rule 14.7 (a function should have a single point of exit at the end of the function), there are indeed deviations from this rule within several source files.
  • You may have noticed the deviation is always the same: a first "return" statement is placed after the functions' parameters check.
  • We are aware of this practice and, according to our coding rules, the rationale is "avoiding significant nested if or overhead of code".
  • Below are two examples from L4 HAL source drivers: https://github.com/STMicroelectronics/STM32CubeL4/blob/1ebb94256904a8b081e38caaffd4da7c2003136e/Drivers/STM32L4xx_HAL_Driver/Src/stm32l4xx_hal_dma.c#L153-L164 https://github.com/STMicroelectronics/STM32CubeL4/blob/1ebb94256904a8b081e38caaffd4da7c2003136e/Drivers/STM32L4xx_HAL_Driver/Src/stm32l4xx_hal_i2c.c#L472-L481

I hope you find in these explanations answers to your questions. Thank you once more for your reports. Take care and stay safe.

With regards,

[thebruce87m]

Thanks for the response. We are pursuing an NDA in order to get the X-CUBE-STL libraries so I will ask for the MISRA report once we have this.

Note that I am not the user on the forum that posted the report - as of the time of writing this I do not have any posts at all on the forum - but it was interesting to see your analysis.