Posted on September 27, 2017 at 19:03I want to turn on the led attached to PC.9. I do this:
LL_GPIO_InitTypeDef initStruct;
LL_GPIO_StructInit( &initStruct );
initStruct.Mode = LL_GPIO_MODE_OUTPUT_10MHz;
initStruct.OutputType = LL_GPIO_OUTPUT_PUSHPULL;
initStruct.Speed = LL_GPIO_SPEED_FREQ_HIGH;
initStruct.Pin = LL_GPIO_PIN_9; // that equals 0x04020002
LL_GPIO_Init( GPIOC, &initStruct )
This code will actually init PC.2 (not PC.9 as it's supposed to) to output push-pull.
Why? LL_GPIO_Init does this:
pinpos = POSITION_VAL(GPIO_InitStruct->Pin);
where
&sharpdefine POSITION_VAL(VAL) (__CLZ(__RBIT(VAL)))
so pinpos will be equal to
(__CLZ(__RBIT(
0x04020002
))) which is equal to 1.
Then current pin will be calculated like this:
currentpin = (GPIO_InitStruct->Pin) & (0x00000101U << pinpos);
so currentpint will be equal to 2.
And then
LL_GPIO_SetPinMode(GPIOx, currentpin, GPIO_InitStruct->Mode);
will be called, despite the fact that LL_GPIO_SetPinMode should only accept parameters like LL_GPIO_PIN_x.
Reasons:
- all inline functions in header files do not check their arguments with assert_param, so this error was not caught early
- lack of proper (i.e. automatic) testing?
- lack of public bugtracker
I have already posted this bug here but it got mixed up with my own ignorance and stupidity so I haven't got a proper reaction. I believe it's time to post it again.
#hal-ll #ll-bug #software-error #bug #ll #stm32f1
