AnsweredAssumed Answered

Bug in LL library for stm32f1xx

Question asked by khazanskii.roman on Sep 27, 2017
Latest reply on Mar 27, 2018 by khazanskii.roman

I 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

 

    #define 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.

Outcomes