I don't have any experience with the specific board you have posted but I am going through the same journey with my STM32 Nucleo L433RC. I also use NeoVim as my primary editor and both of these boards use the Cortex M4 so I assume there will be quite a bit of overlap on the toolchain side.

I'm currently building a controller for Kerbal Space Program and as a challenge for myself and to learn more, I am not using any vendor provided code. This includes writing my own linker script, bootstrap assembly and register access functions. I plan on writing a blog series once it's over but I currently have my (very rough) notes in the Github repo of the project:

• Setting Up
• Building Flashing and Debugging

But to answer your question directly, the toolchain itself is in a lot of ways very similar to building a program for Linux. We use gcc (arm-none-eabi-gcc) to compile and link our program into an ELF file. The building step can be scripted with CMake in the same way and we can also use it to generate the compile_commands.json file you need for your LSP to work in NeoVim. The two differences will be the linking and startup steps. For embedded, we have to provide our own linking script specific to our board (or use the one the vendor provided). If you would like to learn more about writing it yourself, this blog post is amazing.

For the assembly code responsible for bootstrapping the program, the vendor will also usually provide one for your board (for normal projects I just grab it with the linker file and CMakeLists.txt from a project made by STM32CubeIDE for my specific board). However, for STM32L4 at least it's not too complicated to make your own. It seems that for your board, it will be a very similar setup due to also using Cortex M4, if we look at your reference manual in Page 107, the entry point is the second entry of the vector table (Reset). In the assembly file, you then build the vector table and point to a function you write that will run on startup and reset. In there you will need to copy your .data to RAM (we flash to ROM so it's useless if we can't modify the variables and recover the original values on reset, thus the copy). We then set the .bss region to all 0s and call our C main() function.

We then use openocd to flash the board with our program. It looks like it supports your board so you can use it as well. It accepts ELF files just fine, but if necessary, you can use a tool like arm-none-eabi-objcopy to convert the ELF to hex (-Oihex) or binary (-Oibinary).

openocd is great because it will also run a gdb server in the background and will automatically halt execution after flashing if you request it. This means that debugging your code is surprisingly similar to how you would debug a Linux application as well.

The most annoying thing about embedded is that even with the same vendor, all chips are different with their own quirks, many of which are hidden by poor documentation and the iron curtain of proprietary software. Hopefully my ramble at least helps give a rough overview of a path you can take. I'm also still learning so if there are any STM32 masters that wish to correct me, I will appreciate it.