STM32F1 - LL_GPIO_Init() problem

[Bogdan Golab]

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:

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)

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.

[Willunen]

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:

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.)

[waclawek.jan]

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]

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

[Bogdan Golab]

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]

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.

[Willunen]

Posted on March 17, 2018 at 22:35

What do you mean by 'not having initialized the whole structure'? Should I also have to include speed and outputtype?? in the structure for an input?

Wilko

[Bogdan Golab]

Posted on March 17, 2018 at 23:07

Yes, Jan might be right. In my case there should be in the code generated by STM32CubeMX:

GPIO_InitStruct.Mode = LL_GPIO_MODE_INPUT;

[waclawek.jan]

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.

[Bogdan Golab]

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).