STM32F3cube 1.1.0 current state of MISRA compliance

[ru]

Posted on March 12, 2015 at 15:23

Hello ST team,

I am currently evaluating the STM32F3cube library. The documentation states, that it complies with MISRA 2004, which made me consider using the library in the first place. After some light browsing through the source code, I quickly found the following code in the file stm32f3xx_hal_adc_ex.c (Version 1.1.0 of 12-Sept-2014):

HAL_StatusTypeDef HAL_ADC_Init(ADC_HandleTypeDef* hadc) 
{ 
uint32_t WaitLoopIndex = 0; 
/* Set the intermediate state before moving the ADC voltage regulator */ 
/* to state enable. */ 
hadc->Instance->CR &= ~(ADC_CR_ADVREGEN); 
/* Set ADVREGEN bits to 0x01 */ 
hadc->Instance->CR |= ADC_CR_ADVREGEN_0; 
/* Delay for ADC stabilization time. */ 
/* Delay fixed to worst case: maximum CPU frequency */ 
while(WaitLoopIndex < ADC_STAB_DELAY_CPU_CYCLES) 
{ 
WaitLoopIndex++; 
} 
}

This code starts the voltage regulator of the ADC in the

HAL_ADC_Init

function. as stated in the stm32f3 manual, one has to wait 10µs after enabling the regulator, which is done using busy waiting in a loop using a non-volatile loop counter. There are a few more instances of this pattern inside the ADCexdriver. Of course this only works if the compilers's optimization is turned off (up to -O1 in gcc). Otherwise, the loopwould be removed, because it is dead code and has no effect on the program except for the duration. Since this also violates theMISRA coding rules and is easily detected by static code checkers, I was wondering, if I am missing some documentation, which tells me, which MISRA rules where checked and how. Also I would like to know which compilers and which compiler settings need to be used to get reliable code. I currently assume these are unintended bugs but it might as well be intetional if special compiler flags are required. I hope you can clarify this for me. Best regards #everything-is-awesome

[Rosiney Silva]

Posted on April 02, 2016 at 22:05

Thanks for the reference

clive1

.

[David Brooks]

Posted on April 15, 2016 at 21:08

Mayla, please see file attached 3/24/2016 2:37 PM. Thanks, David

[James Murray]

Posted on March 11, 2018 at 19:39

I know this is an old post, but the problem persists. The ST pages say that the HAL is MISRA compliant. I beg to differ.

e.g. from usbd_cdc.c

static uint8_t  USBD_CDC_DataOut (USBD_HandleTypeDef *pdev, uint8_t epnum)

{         USBD_CDC_HandleTypeDef   *hcdc = (USBD_CDC_HandleTypeDef*) pdev->pClassData;      /* Get the received data length */   hcdc->RxLength = USBD_LL_GetRxDataSize (pdev, epnum);      /* USB data will be immediately processed, this allow next USB traffic being    NAKed till the end of the application Xfer */   if(pdev->pClassData != NULL)   {     ((USBD_CDC_ItfTypeDef *)pdev->pUserData)->Receive(hcdc->RxBuffer, &hcdc->RxLength);      return USBD_OK;   }   else   {     return USBD_FAIL;   } }

A couple of obvious rule failures here:

1. There should only be a single return point per function.

2. The return variable on each function call must be checked.

Point 2 is particularly important because that function is ignoring the returned status from the lower layer.

James