Skip to main content
Bogdan Golab
Bogdan Golab
Lead
March 17, 2018
Solved

STM32F1 - LL_GPIO_Init() problem

  • March 17, 2018
  • 4 replies
  • 8458 views
Posted on March 17, 2018 at 20:45

Hi,

A piece of code from STM32CubeMX v4.0 and latest F1 drivers generated for STM32VLDiscovery (the button is pulled-down by external resistor):

static void MX_GPIO_Init(void)

{

LL_GPIO_InitTypeDef GPIO_InitStruct;

/* GPIO Ports Clock Enable */

LL_APB2_GRP1_EnableClock(LL_APB2_GRP1_PERIPH_GPIOC);

LL_APB2_GRP1_EnableClock(LL_APB2_GRP1_PERIPH_GPIOD);

LL_APB2_GRP1_EnableClock(LL_APB2_GRP1_PERIPH_GPIOA);

GPIO_InitStruct.Pin = LL_GPIO_PIN_0;

GPIO_InitStruct.Mode = LL_GPIO_MODE_FLOATING;

LL_GPIO_Init(GPIOA, &GPIO_InitStruct);

}

and the results from the Keil debugger:

0690X0000060A77QAE.png

So commented the line below to prove that there is only one line of code used for GPIOA initialization:

// LL_GPIO_Init(GPIOA, &GPIO_InitStruct);

and got as expected (the default settings for GPIOA)

0690X0000060A9WQAU.png

It seems that the LL_GPIO_Init gives messy config on more than one pin. Am I wrong?

Have no luck with F1 line and LL drivers - this issue seems to be continuation of my previous finding:

https://community.st.com/message/190160-re-stm32cubemx-v4240-stm32f1-gpio-ll-led-blinking-fails?commentID=190160#comment-190160

--------------------------------

So switching back to register programming when working with boards with low SRAM size. It takes less time than investigating issues in LL drivers.

I wonder if you use LL drivers for F1 line. I know that more people prefer SPL drivers for this line.

Note: this post was migrated and contained many threaded conversations, some content may be missing.
    This topic has been closed for replies.
    Best answer by STOne-32
    Posted on March 19, 2018 at 15:58

    Dear all,

    Thank you for the comments and opening the discussion on this GPIO LL driver limitation.  Indeed, we confirm the issue , and we confirm it  is fixed  in STM32CubeF1 Firmware patch Package V1.6.1 which will be in a couple of days on public  web site and available in CubeMx to download as well.  

    Cheers,

    STOne-32

    4 replies

    Willunen
    Willunen
    Associate III
    March 17, 2018
    Posted on March 17, 2018 at 21:06

    I think I have found something similar. When I do this:

      //*****************************************************************

      GPIO_InitStruct.Pin = LL_GPIO_PIN_4|LL_GPIO_PIN_5;

      GPIO_InitStruct.Mode = LL_GPIO_MODE_FLOATING;

      LL_GPIO_Init(GPIOA, &GPIO_InitStruct);

      GPIO_InitStruct.Pin = LL_GPIO_PIN_3|LL_GPIO_PIN_6|LL_GPIO_PIN_7;

      GPIO_InitStruct.Mode = LL_GPIO_MODE_OUTPUT;

      GPIO_InitStruct.Speed = LL_GPIO_SPEED_FREQ_HIGH;

      GPIO_InitStruct.OutputType = LL_GPIO_OUTPUT_PUSHPULL;

      LL_GPIO_Init(GPIOA, &GPIO_InitStruct);

      //******************************************************************

    the result looks like this:

    0690X00000604RGQAY.jpg

    The second LL_GPIO_Init reconfigures GPIO_PIN_5 from an input to an output!

    (I am using the stm32f1xx_ll_gpio.c suggested by Imen D as answer to your ''led blinking fails'' question.)

    Bogdan Golab
    Bogdan GolabAuthor
    Lead
    March 17, 2018
    Posted on March 17, 2018 at 21:14

    Yes, LL is risky now  - I mean swapping inputs with outputs!

    It seems that F1 LL drivers are not tested before releasing. GPIO is rather basic stuff...

    waclawek.jan
    waclawek.jan
    Super User
    March 17, 2018
    Posted on March 17, 2018 at 22:10

    Isn't this the same issue all over again, with not having initialized the whole structure used for the 'library' call?

    JW

    Bogdan Golab
    Bogdan GolabAuthor
    Lead
    March 17, 2018
    Posted on March 17, 2018 at 22:14

    Maybe. Unfortunately, I do not have time for debugging poorly implemented LL.

    I reported this problem (quite major issue, I think) 2 months ago. New STM32CubeMX 4.25.0  & F1 driver pack do not have the fix.

    How to make people use LL instead of SPL for F1?

    henry.dick
    henry.dick
    Associate II
    March 17, 2018
    Posted on March 17, 2018 at 23:35

    '

    So switching back to register programming when working with boards with low SRAM size. It takes less time than investigating issues in LL drivers.'

    that's the risk with any library.

    unfortunately in this case, rather than making SPL great again, ST has elected to spread its limited resources so everything is made mediocre.

    waclawek.jan
    waclawek.jan
    Super User
    March 18, 2018
    Posted on March 18, 2018 at 00:41

    You're contradicting yourself within two consecutive lines:

    unfortunately in this case, rather than making SPL great again,

    that's the risk with any library.

    So what's that great about SPL, exactly?

    JW

    PS. To be fair, SPL *did* come with *some* documentation which *did* contain a guideline about initializing the init structs - whereas Cube contains only the doxygen autovomit. But then nobody read the documentation back then, too, and this problem was a regular here. It sort of went away with most people relying on CubeMX generating their init stuff, which may be correct - I don't know, I can't run CubeMX as I refuse install Java and ST refuses to attach the JVM to their javoids.

    0690X00000609qCQAQ.png
    Bogdan Golab
    Bogdan GolabAuthor
    Lead
    March 18, 2018
    Posted on March 18, 2018 at 09:14

    CubeMX is good for me as resource management tool and init code generator. The problem is in case of LL that the LL is not documented (you do not know the defaults, etc). So sort of reverse engineering is required here to see why something does not work + what particular LL function is supposed to do.

    So it takes less tome for me to use Reference Manual and right registers than digging into the logic of bit manipulation, etc.

    Yes, agree that this post was a kind of noise from the issue perspective but from my perspective was useful (a hobbyist always benefits from comments coming from professionals).

    STOne-32
    STOne-32Best answer
    ST Technical Moderator
    March 19, 2018
    Posted on March 19, 2018 at 15:58

    Dear all,

    Thank you for the comments and opening the discussion on this GPIO LL driver limitation.  Indeed, we confirm the issue , and we confirm it  is fixed  in STM32CubeF1 Firmware patch Package V1.6.1 which will be in a couple of days on public  web site and available in CubeMx to download as well.  

    Cheers,

    STOne-32

    Bogdan Golab
    Bogdan GolabAuthor
    Lead
    March 19, 2018
    Posted on March 19, 2018 at 16:21

    Thank you for letting us know!

    Terms & ConditionsAccessibility statement