cancel
Showing results for 
Search instead for 
Did you mean: 

misleading assert_param() failures

noobee
Associate II
Posted on April 08, 2015 at 04:45

so i tried turning on ''

#define USE_FULL_ASSERT

'' in stm32f1xx_hal.h and found it complaining about a bunch of errors (false positives). listing two common ones here: stm32f1xx_hal_gpio.c line 210

assert_param(IS_GPIO_PULL(GPIO_Init->Pull));

afaik, this test is not needed at line 210 since it is needed only if the pin is configured as input. indeed, there is a explicit test later in line stm32f1xx_hal_tim.c lines 3065-3071

assert_param(IS_TIM_CHANNELS(Channel));
assert_param(IS_TIM_PWM_MODE(sConfig->OCMode));
assert_param(IS_TIM_OC_POLARITY(sConfig->OCPolarity));
assert_param(IS_TIM_OCN_POLARITY(sConfig->OCNPolarity));
assert_param(IS_TIM_FAST_STATE(sConfig->OCFastMode));
assert_param(IS_TIM_OCNIDLE_STATE(sConfig->OCNIdleState));
assert_param(IS_TIM_OCIDLE_STATE(sConfig->OCIdleState));

imo, only

sConfig->OCFastMode

needs to be tested since it is explicitly used in this function. in general, all other fields should be tested in the functions that they are used. in my case, i got another false positive on

assert_param(IS_TIM_OCN_POLARITY(sConfig->OCNPolarity));

the assert_param() seems like a nice feature to check that the parameters are filled in. but it's not useful when i get a full page of warnings, most if not all are false positives. thanks!
1 REPLY 1
Posted on August 17, 2015 at 13:11

Hi noobee,

Thanks for reporting these issues. Improvements will be considered in next releases.

-Shahrzad-