Newbie STM32 black-pill question

[dorkshoei]

I purchased two STMF401 black-pill from here:  https://www.aliexpress.us/item/2255800863525536.html

I've previously used the blue-pill,  which I've not had any issues with.

Originally if I connected the black-pill to USB-C,  both the power and the user (next to C13) LEDs would light.  I could enter DFU mode (hold down BOOT0, press RST) and then the user LED would go off.

I tried to flash the black-pill LED blink demo via SWD (STLink/v2) but none of the ones I found would blink the LED (I tried various versions for the common ports the LED is wired to).  More oddly, now when I connect to just USB-C,  the user LED no longer comes on.   I can still enter DFU mode.

Above happened for both devices.     Using STLink (1),  if I read back the device memory it matched what I flashed.    If I manually connect 3.3V to the LED, it lights.     I've also tried flashing the blink demos using DFU (2) rather than SWD.   No difference.

I'm probably doing something very dumb but I'm unsure what it is.

I asked the seller for the schematic for the device.  They said they would provide but never did and have now stopped responding. 

1: https://github.com/stlink-org/stlink
2: https://github.com/GGLinnk/dfu-util

[CountChocula]

Did you make sure that you compiled your code for the correct MCU? It looks like this board comes in at least two different models; if you're compiling against the wrong processor, it's possible that your code is just erroring out right away and halting the CPU. You could also try to debug the code to see if it runs and where it hangs.

[iMo]

There are links to schematics on this page as well..

https://stm32world.com/wiki/Black_Pill

[dorkshoei]

Did you make sure that you compiled your code for the correct MCU? It looks like this board comes in at least two different models; if you're compiling against the wrong processor, it's possible that your code is just erroring out right away and halting the CPU. You could also try to debug the code to see if it runs and where it hangs.

It's possible but what I'm mostly curious about is why the LED no longer lights when I connect the board to USB-C.   It originally did and the LED would go off when you'd enter DFU mode.    Entering DFU mode still works but there is no LED.      Is there some form of "bootloader" that I've overridden with my code?  I've read various mentions of Arduino compatible "bootloaders" etc.

There are links to schematics on this page as well..

https://stm32world.com/wiki/Black_Pill

I'd read there were varying versions.

[jgrossman]

What was the original firmware doing? The user LED going off doesn't surprise me, since the firmware probably isn't set up to drive it.

https://stm32world.com/wiki/Black_Pill#Miscellaneous_Links
https://stm32-base.org/assets/pdf/boards/original-schematic-STM32F411CEU6_WeAct_Black_Pill_V2.0.pdf

Looks like it's connected to PC13. Is this the pin your blinky example is trying to toggle?

[CountChocula]

It's possible but what I'm mostly curious about is why the LED no longer lights when I connect the board to USB-C.   It originally did and the LED would go off when you'd enter DFU mode.    Entering DFU mode still works but there is no LED.      Is there some form of "bootloader" that I've overridden with my code?  I've read various mentions of Arduino compatible "bootloaders" etc.

I assume that you're talking about the user LED here… at boot, that GPIO pin is held floating and needs to be turned on via code in order for the LED to light. Therefore, the CPU is halting before it gets to the point where the code instructs the LED GPIO pin to go high. Most likely, this is because you've either:

- Uploaded new code that overwrote the original and does not turn on the LED
- Uploaded new code that does, but has not been compiled in a way that it's executing properly on the processor (hence the suggestion to make sure you're compiling for the correct STM32 model)
- Possibly, but very unlikely, have damaged the CPU


—CC

[dorkshoei]

I assume that you're talking about the user LED here… at boot, that GPIO pin is held floating and needs to be turned on via code in order for the LED to light. Therefore, the CPU is halting before it gets to the point where the code instructs the LED GPIO pin to go high. Most likely, this is because you've either:

I'm referring to when the USB-C cable is connected.

Originally,  before I flashed anything.   If the device was connected to USB-C,   both the user and POWER LEDs would be lit.   The user LED (next to C13) would go off after I entered DFU mode (POWER LED remained on).

Since flashing the code (which it's possible is bad) when I connect to USB-C,  the user LED no longer comes on but I can still enter DFU mode.

EDIT:  I will look at the code I'm flashing some more,  verify it's correct.  It's supposed to blink PC13 but I was unsure what was going on wrt above?

[CountChocula]

Originally,  before I flashed anything.   If the device was connected to USB-C,   both the user and POWER LEDs would be lit.   The user LED (next to C13) would go off after I entered DFU mode (POWER LED remained on).

Since flashing the code (which it's possible is bad) when I connect to USB-C,  the user LED no longer comes on but I can still enter DFU mode.

EDIT:  I will look at the code I'm flashing some more,  verify it's correct.  It's supposed to blink PC13 but I was unsure what was going on wrt above?

I suspect that somehow we're talking a bit past each other

What was happening before you flashed the device is that there was already some code on it that was booting properly turning on the LED. Now that you have uploaded new code, that old code is gone—replaced with yours, which, for a reason that you haven't yet determined, is not turning on the LED. Your code doesn't get wiped out when you remove power, so disconnecting and reconnecting the USB-C connector doesn't make any difference.

I hope this helps clarify things a little! Let us know if you need help figuring out why the code isn't working. Cheers!

[dorkshoei]

What was happening before you flashed the device is that there was already some code on it that was booting properly turning on the LED.

Yes, the above dawned on me right after I wrote the reply.   Totally obvious.   Sorry I was being dense.

I'd have been better off buying the 411 as there is more pre-canned code for it.

I don't see any specific gcc flags that would target 411 vs 401.   libopencm3 has a set of tools that generate a linker file based on following regex:

stm32f411?e* stm32f4 ROM=512K RAM=128K
stm32f401?c* stm32f4 ROM=256K RAM=64K

I'd already made these changes to the linker file for this:  https://github.com/trebisky/stm32f411/tree/master/blink1 but the code still doesn't work.

I was trying to avoid using the bloatware STM gui but perhaps it might be better initially as there are more examples using that.

Appreciate the help.  Can't believe I didn't understand what was going on with the LED.  Sigh.

[jgrossman]

I was trying to avoid using the bloatware STM gui but perhaps it might be better initially as there are more examples using that.

I like using the MX tool standalone for exactly as long as it takes to set up pins the first time. Then I generate somewhere as a reference and never touch the IOC file again. It's a great ramp to doing the stuff I actually want to do instead of setting up clocks/pins/dma all day.

[CountChocula]

I was trying to avoid using the bloatware STM gui but perhaps it might be better initially as there are more examples using that.

My suggestion is to use CubeMX to get started, at least until you know that all the pieces of your toolchain are working. Alternatively, consider Arduino IDE or PlatformIO—with the intent of removing as many unknown variables from the equation. I had a really hard time getting my first STM32 to work… the tooling is truly byzantine. Good luck!


—CC

[dorkshoei]

I was trying to avoid using the bloatware STM gui but perhaps it might be better initially as there are more examples using that.

My suggestion is to use CubeMX to get started,

We'll have to see.  I installed it.  It's even worse than I imagined and I was imagining bad.   License agreements,  requirements to log in while using tool.   I was able to select the C13 pin but my efforts to "generate code" keep resulting in popups asking me which external program I want to use to open this .project file (Toolchain == STM32CubeIDE) or .eww file (Toolchain == EWARM which was the default after installing).

I generally despise these Eclipse based UIs.

Anyways, I appreciate the help!

[DavidAlfa]

Thsi is your board.
https://stm32-base.org/boards/STM32F401CCU6-WeAct-Black-Pill-V1.2.html

(...) I was able to select the C13 pin but my efforts to "generate code" keep resulting in popups asking me which external program I want to use to open this .project file (...)

Use CubeIDE instead. Basically, it's Eclipse + CubeMX.

Try the attached project, flash the precompiled .bin file inside Release folder.
It just blinks PC13 LED at 1Hz.

To import it, extract the file and place the 401 folder in user_folder/STM32CubeIde/Workspace, then open CubeIDE, go to file / Import / Existing projects, choose that folder.
I stripped it off HAL / CMSIS libs to save space, so when you open the project in CubeIDE, open the 401.ioc file inside the IDE (Will open built-in CubeMX), then click Code Generation(The golden gear near to build / debug buttons), then close CubeMX.
This will restore all the missing libs , should compile fine after that.

[dorkshoei]

Use CubeIDE instead. Basically, it's Eclipse + CubeMX.

Thanks.  That worked a lot better.   I still really dislike anything Eclipse based.

Try the attached project, flash the precompiled .bin file inside Release folder.

Once I realized I need CubeIDE not CubeMX I was able to follow the instructions here:  https://daniellethurow.com/blog/2021/6/16/getting-started-with-stm32-black-pill-getting-blinky-with-stm32cube-ide

The LED blinks now

I'm still much happier working with emacs,  bash and gcc .... so I'll work towards that goal.

I appreciate everyones help.

[dorkshoei]

The LED blinks now

Though neither will now go into DFU mode.  Windows now shows "Unknown USB Device (Device Descriptor Request Failed)" on both boards.

Same as reported here:  https://www.reddit.com/r/embedded/comments/tm345t/comment/i1x6n7g

Changing usb port/cable makes no difference.   I can stick to using SWD (STLink) but it's odd as it was working fine back when the LED wouldn't blink :-)

[DavidAlfa]

CubeIDE is nice to start, then you could go with libopencm3, makefiles...
But you don't have to use HAL in CubeIDE!
You can choose low level (LL) libs instead (MX, project manager, advanced, set all to LL), the result will be very close to opencm3, way lower memory usage, but requiring lots of additonal R&D.
Of course a guy spending 8h a day with stm32s for a living will do this in a breeze, will have done the fighting and already know all the little things.

Attached LL project. Again, regenerate the project before building.

Note that now you'll have to do a lot more of research, no more "HAL magic" !
Just an example after setting LL for the same project:
- Why is systick not working? Figure out that SysTick need its IT enabled by the user.
- There's no systick function, you have to make your own.

Now that's where the trains collide: HAL might not be extremely efficient, but gets your project running in no time, where LL or baremetal might be better optimized, but needs a much longer development and the results heavily depend on the programmer's hands.
Depending on the circumstances, buying a larger chip might be a better option than spending months of development, not only due R&D costs, but the time!

I'm still much happier working with emacs,  bash and gcc .... so I'll work towards that goal.

Eclipse might not be the best IDE in the world, but I greatly appreciate it.
How do you find out what function to call in emacs? Or an external variable name?
Let's say you forgot... Hmm was it GPIO_Toggle? Toggle_GPIO? LL_GPIO_Toggle?
In Eclipse/CubeIDE you can find out instantly without opening any files.
Write GPIO_ (Control+Space) -> Shows all the stuff containing that. Ah! It was GPIO_TooglePin!

Doing it with plain text editor seems tiresome, slow and inefficient.
We have 8-core cpus with 32GB RAM, fast SSDs... for peanuts, so I'd rather have a small slowdown when opening CubeIDE than switching between 20 header files for every single thing or memorize it all.

I already wrote about this several times (Don't take it bad, just my personal preference!)

Some dinosaurs still argue emacs/text editor is the way to go...
But no thanks, it's like saying hand-made iron smelting in clay furnaces by sweating slaves is better than modern industrial techniques  .

- Real-time syntax checking just great, makes your life easier. I appreciate my time, with a simple text editor, you won't notice if you accidentally typed "rpintf" until compiling.
- Control+click and mouse hovering are great to have a quick glance/fly to the declaration/definition, it's incredibly useful, otherwise you hav to remember everything.
- Embedded debugging, variables, expressions, all-in-one package makes it extremely simple to setup...
- Making Makefiles by hand? Erm, no thanks, I already waste a lot of time with those heeecking registers and buggy peripherals 

[dorkshoei]

Some dinosaurs still argue emacs/text editor is the way to go...

You can use vi if you wish 

I don't mind IDEs for real-time syntax etc.  Codeview is OK.

Eclipse is just bloated.  The whole dynamic updating of java components from the cloud also sucks.  It's too easy to end up with an unmaintainable mess.

Vendors embedding eclipse is even worse.  Two vendor IDEs,  two copies of Eclipse.

[DavidAlfa]

You *don't* have to keep all the mess updated. In fact I'm reluctant to, too much bad stories, strong as thin glass.

[dorkshoei]

You *don't* have to keep all the mess updated. In fact I'm reluctant to, too much bad stories, strong as thin glass.

I'm aware you don't.   it doesn't change my utter dislike of Eclipse.   Should I get over it and just use the STM IDE,  maybe

[Georgy.Moshkin]

I have WeAct F411 and F401 boards and think that the best way to enter USB bootloader is to re-connect USB cable while keeping BOOT0 button pressed:
https://youtu.be/ZDnjVH8sNf8

Something tells me that pressing reset button + boot0 will not help with re-enumerating USB devices.
E.g., for F103 and H7B0 I use method descried here:

Code: [Select]

   
    /*
     * Force host to re-enumerate device
     */
    GPIO_InitTypeDef GPIO_InitStruct = { 0 };              // All zeroed out
    GPIO_InitStruct.Pin = GPIO_PIN_12;                     // Hardcoding this - PA12 is D+
    GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_PP;            // Push-pull mode
    GPIO_InitStruct.Pull = GPIO_PULLDOWN;                  // Resetting so pull low
    GPIO_InitStruct.Speed = GPIO_SPEED_HIGH;               // Really shouldn't matter in this case
    HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);                // Initialize with above settings
    HAL_GPIO_WritePin(GPIOA, GPIO_PIN_12, GPIO_PIN_RESET); // Yank low
    HAL_Delay(50);                                         // Enough time for host to disconnect device
    HAL_GPIO_WritePin(GPIOA, GPIO_PIN_12, GPIO_PIN_SET);   // Back high - so host will enumerate
    HAL_GPIO_DeInit(GPIOA, GPIO_PIN_12);                   // Deinitialize the pin

This code should be called before calling MX_USB_DEVICE_Init(); (comment original one and use it inside "USER CODE BEGIN 2")

To ensure USB detection when entering bootloader mode, try to re-connect USB cable while keeping BOOT0 button pressed.

[darkspr1te]

Thought i would chime in here as have been using this stm recently.
Yes the best method is to unplug then hold boot0 and replug, Windows has to see the enumeration signal which only happens on plug in or you have to send a USB signal to do it but it wont happen if you just reset+boot0.
For IDE i find that Visual studio+platform io works great for me, here is my normal work flow.


if am basing on stm codebase:-
First i start STM CubeMX and select my MCU, i then enable my various systems like USB, RCC etc and enable my gpio's , here you can specify the names of gpios and they are added as constants/defines to the final source.
once you have set your clocks and enabled  all your peripheral's goto the project manager page.
On the project manager page I normally select Makefile as Toolchain IDE as i often am in linux or WSL and typing "make clean && make " is quick for my brain , it also makes for a handy reference needed later (no pun intended)
here also you can select heap size and more.
next I select my export location/folder and click Generate code


This gives us a "Generic codebase" to start from and should compile and upload to the device without issue but note it wont do anything other than setup a few gpios and clocks and not much else but sit in a while loop.
Next i create another need file for platformio and thats the platformio.ini file which is placed in the same folder as the Makefile,

Code: [Select]



[platformio]


src_dir      = ./


[env:stm32f407_nand]
platform = ststm32
board = vccgnd_f407zg_mini
framework = stm32cube
src_filter = +<Core/Src/*>
            +<USB_DEVICE/App/*>
            +<USB_DEVICE/Target>
monitor_port = com4


build_flags =
        ;-D__STATIC_INLINE=
        -DVECT_TAB_OFFSET=0
        -Wunused-variable
        -DDEBUG       
        -ffunction-sections
        -fdata-sections
        -funroll-loops
        -Wl,--gc-sections
        -Wno-implicit-function-declaration
        -ICore/Inc
        -IUSB_DEVICE/App
        -IUSB_DEVICE/Target
        -IMiddlewares/ST/STM32_USB_Device_Library/Core/Inc/
        -IMiddlewares/ST/STM32_USB_Device_Library/Class/Inc



Next I load platformio (visual studio+platformio)  and select open folder, browse to the folder with Makefile and platformio and let the platformio backend load up.
In the above example of platformio.ini I have included examples of including the USB drivers folders in both the make side and Include side (src_filter for make & build_flags for the includes )
please note that your USB_DEVICE code folder may have a different name if you dont select Makefile as output format in CubeMX
The 'board =  board_name' part of the platformio.ini is where you set your actual board type, there are 100's built into platformio and the platformio wiki has a list of what you write here for your specific board , if your specific board/xtal combo does not exist in the list then it's real easy to choose a close match and just alter those small changes in the platformio.ini file,
a example would be under build_flags you add

Code: [Select]

      -DHSE_VALUE=8000000

On my github i have many examples
https://github.com/darkspr1te


The reasons i have this workflow is platformio supports more than just STM mcu's so it allows me to load up code for two different devices and port code from one to the other. It also supports Arduino/CMSIS/Standard Peripheral Lib/STMCube/libopencm3, The arduino support is really handy if you dont want to sit there and build backend but create some quick code and not worry about USB clocks etc just bash some gpoi and be done with it.


platformio also supports many programmers like stlinkv2, DFU mode, serial tll upload , jtag and more.
the backend is also really patchable so if you need certain things to happen before compile (eg a bitmap font into C array ) it can easily be done either in the platformio.ini file or in the many python scripts it runs on. this also goes for after compile etc
Another handy feature is for the stm32 libs you can specify the version you want , this is handy for using code you found but wont compile under the latest cubemx backend , eg 'framework = stm32cube@8.9' would load the old codebase where gpio was written as GPIO_Pin_0 where in the later (past v9) it's written as GPIO_PIN_0

[dorkshoei]

For IDE i find that Visual studio+platform io works great for me, here is my normal work flow.
....
On the project manager page I normally select Makefile as Toolchain IDE as i often am in linux or WSL and typing "make clean && make " is quick for my brain , it also makes for a handy reference needed later (no pun intended)
....
Next I load platformio (visual studio+platformio)  and select open folder, browse to the folder with Makefile and platformio and let the platformio backend load up.

Thanks for this.   I'm confused,  in your first example (ToolchainIDE=Makefile) and you're running make from WSL,  what is the toolchain?  Linux "arm-none-eabi"?   Also how then does needing VS+platformio fit in?   Doesn't this replace Linux/WSL tooling?

It's not entirely clear to me what - in the VS+PlatformIO configuration - provides the actual ARM toolchain?

I understand better now the distinction between CubeMX  and CubeIDE though it still feels "messy" to have to invoke CubeMX and then import this into PlatformIO,  though obviously doing everything bare metal like I was trying is complicated++.

I see my board in platformio (https://docs.platformio.org/en/latest/boards/ststm32/blackpill_f401cc.html) though what's being created is a pretty small ini file and a large amount is still delegated I guess to hand or CubeMX.   My initial thought was it would be a lot easier if platformio did all this and maybe that is the long term intent?  aka "patches accepted".  I see mention alluding to that here:  https://community.platformio.org/t/using-stm32cubemx-and-platformio/2611/56

[pcprogrammer]

I understand better now the distinction between CubeMX  and CubeIDE though it still feels "messy" to have to invoke CubeMX and then import this into PlatformIO,  though obviously doing everything bare metal like I was trying is complicated++.

Guess it depends a bit on experience with microcontrollers overall, but I found it easier to just go bare metal then to dive into the stuff provided by STM be it HAL or LL. Definitely easier to find faults because it will all be your own code as long as you are not using third party libraries.

The whole setup with the HAL where you have to fill a structure with the intended settings, and then call the needed functions to make things work, it takes certainly less code space when you write to the peripheral registers directly.

Just download the datasheet and the reference manual for the MCU in question and find out how the peripherals are addressed on this lower level. Once you pick up some experience with that you probably won't go back to HAL. Sure some will argue about portability but even with the HAL it is not always possible to reuse the exact same code on another target.

About an IDE. just look for one that you feel comfortable with. See if it is possible to hook in the needed toolchain and work with that. I myself am using an old version of netbeans and it serves me well.

About your initial issue with loading your own code stopping the user led turning on, but the DFU still working, you have to realize that the MCU has some fixed program memory in it that holds the code for the DFU or serial programming for that matter, that can't be erased. It is totally separate from the FLASH memory used to hold your program. On reset the processor reads the state of the boot pin and jumps to either the code in the user FLASH or to the code in the system memory. When it starts the code in the system memory it is possible to program the user FLASH via a couple of different methods, depending on what the MCU offers. DFU or serial, etc.

[jgrossman]

A particular vendor spin of eclipse I use at work will sometimes throw a Java exception when hovering over some items in the toolbar and bring the whole thing to a halt. I LOVE eclipse.

[DavidAlfa]

A particular vendor spin of eclipse I use at work will sometimes throw a Java exception when hovering over some items in the toolbar and bring the whole thing to a halt. I LOVE eclipse.

It's not eclipse's problem, but the vendor's, introducing a new bug when customizing Eclipse.

The whole setup with the HAL where you have to fill a structure with the intended settings, and then call the needed functions to make things work, it takes certainly less code space when you write to the peripheral registers directly.

But LL is pretty efficient, very little bloated, if any, mostly macros and simple functions.
I like it pretty much!

Code: [Select]

typedef struct {
  GPIO_TypeDef*         port;
  LL_GPIO_InitTypeDef   init;
} GPIO_Init_t;

const GPIO_Init_t GPIO_cfg[] = {
    { SWC_Port,   { SWC_Pin,  LL_GPIO_MODE_ANALOG }},
    { SWD_Port,   { SWD_Pin,  LL_GPIO_MODE_ANALOG }},
    { PWM_Port,   { PWM_Pin,  LL_GPIO_MODE_ALTERNATE, LL_GPIO_SPEED_FREQ_VERY_HIGH, LL_GPIO_OUTPUT_PUSHPULL, LL_GPIO_PULL_NO, PWM_AF }},
    { CCP_Port,   { IR_Pin,   LL_GPIO_MODE_ALTERNATE, LL_GPIO_SPEED_FREQ_VERY_HIGH, LL_GPIO_OUTPUT_PUSHPULL, LL_GPIO_PULL_NO, IR_AF }},
    { RED_Port,   { RED_Pin,  LL_GPIO_MODE_OUTPUT,    LL_GPIO_SPEED_FREQ_VERY_HIGH, LL_GPIO_OUTPUT_PUSHPULL }},
};

  for(uint8_t i=0; i<sizeof(GPIO_cfg)/sizeof(GPIO_Init_t); i++)
    LL_GPIO_Init(GPIO_cfg[i].port, (LL_GPIO_InitTypeDef*)&GPIO_cfg[i].init);


LL_GPIO_Init itself is pretty small:

Code: [Select]

ErrorStatus LL_GPIO_Init(GPIO_TypeDef *GPIOx, LL_GPIO_InitTypeDef *GPIO_InitStruct)
{
  uint32_t pinpos;
  uint32_t currentpin;

  /* Check the parameters */
  assert_param(IS_GPIO_ALL_INSTANCE(GPIOx));
  assert_param(IS_LL_GPIO_PIN(GPIO_InitStruct->Pin));
  assert_param(IS_LL_GPIO_MODE(GPIO_InitStruct->Mode));
  assert_param(IS_LL_GPIO_PULL(GPIO_InitStruct->Pull));

  /* ------------------------- Configure the port pins ---------------- */
  /* Initialize  pinpos on first pin set */
  pinpos = 0;

  /* Configure the port pins */
  while (((GPIO_InitStruct->Pin) >> pinpos) != 0x00u)
  {
    /* Get current io position */
    currentpin = (GPIO_InitStruct->Pin) & (0x00000001uL << pinpos);

    if (currentpin != 0x00u)
    {
      /* Pin Mode configuration */
      LL_GPIO_SetPinMode(GPIOx, currentpin, GPIO_InitStruct->Mode);

      if ((GPIO_InitStruct->Mode == LL_GPIO_MODE_OUTPUT) || (GPIO_InitStruct->Mode == LL_GPIO_MODE_ALTERNATE))
      {
        /* Check Speed mode parameters */
        assert_param(IS_LL_GPIO_SPEED(GPIO_InitStruct->Speed));

        /* Speed mode configuration */
        LL_GPIO_SetPinSpeed(GPIOx, currentpin, GPIO_InitStruct->Speed);
      }

      /* Pull-up Pull down resistor configuration*/
      LL_GPIO_SetPinPull(GPIOx, currentpin, GPIO_InitStruct->Pull);

      if (GPIO_InitStruct->Mode == LL_GPIO_MODE_ALTERNATE)
      {
        /* Check Alternate parameter */
        assert_param(IS_LL_GPIO_ALTERNATE(GPIO_InitStruct->Alternate));

        /* Speed mode configuration */
        if (currentpin < LL_GPIO_PIN_8)
        {
          LL_GPIO_SetAFPin_0_7(GPIOx, currentpin, GPIO_InitStruct->Alternate);
        }
        else
        {
          LL_GPIO_SetAFPin_8_15(GPIOx, currentpin, GPIO_InitStruct->Alternate);
        }
      }
    }
    pinpos++;
  }

  if ((GPIO_InitStruct->Mode == LL_GPIO_MODE_OUTPUT) || (GPIO_InitStruct->Mode == LL_GPIO_MODE_ALTERNATE))
  {
    /* Check Output mode parameters */
    assert_param(IS_LL_GPIO_OUTPUT_TYPE(GPIO_InitStruct->OutputType));

    /* Output mode configuration*/
    LL_GPIO_SetPinOutputType(GPIOx, GPIO_InitStruct->Pin, GPIO_InitStruct->OutputType);
  }
  return (SUCCESS);
}


[SiliconWizard]

Yes, for those who do not want the bloat or quirks of the STM32 HAL, and don't want to bother either with directly accessing registers, the STM32 LL library is a good alternative and not enough known.

[langwadt]

You *don't* have to keep all the mess updated. In fact I'm reluctant to, too much bad stories, strong as thin glass.

I'm aware you don't.   it doesn't change my utter dislike of Eclipse.   Should I get over it and just use the STM IDE,  maybe

and if you use the STM ide you'll be done and drinking coffee watching the finished project before you find the right page of the usermanual for the mcu

[liaifat85]

For pinout and other info in one place, you can take a look at this: https://www.theengineeringprojects.com/2019/12/introduction-to-stm32-microcontroller.html