Plain STM32L412 not always running program

,
1

I have a very minimal setup for a plain STM32L412KB on a LQFP breakout board.
I’ve used this guide to properly power the chip.
For the programmer, I’m using a broken out STLINK portion of a Nucleo64 board:

ST link and target MCU
ST link and target MCU400×327 28.5 KB

And I’ve followed this thread for hooking it up, I’ve only added a wire between the NRSTpin and the 5th pin on the STLINK SWD header.
Both the STLINK and board show up fine on STM32CubeProgrammer, the option bytes are all defaults except for: BOR_LEV, nSWBOOT0 and nBOOT0
fig0
fig02001×728 98.5 KB

And Platformio uploads the code succesfully under these settings:

[env:nucleo_l412kb]
platform = ststm32
board = nucleo_l412kb
framework = arduino
debug_tool = stlink
upload_protocol = stlink
build_flags = -DCONFIG_DISABLE_DEBUG=1

And with this output in the terminal:

xPack OpenOCD, x86_64 Open On-Chip Debugger 0.10.0+dev-00378-ge5be992df (2020-06-26-09:29)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
debug_level: 1

srst_only separate srst_nogate srst_open_drain connect_deassert_srst

Error: target voltage may be too low for reliable debugging
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x1fff31f8 msp: 0x20001bb0
** Programming Started **
Warn : Adding extra erase range, 0x08002a88 .. 0x08002fff
** Programming Finished **
** Verify Started **
** Verified OK **
** Resetting Target **
shutdown command invoked

However, I’ve only seen my basic blink program with an LED connected between PA5 and ground run only once or twice after uploading. Disconnecting the programmer and resettings the micro doesn’t restart the program. The memory looks to still be identical when read over STM32CubeProgrammer.
In short: A basic blink program only occasionally runs directly after programming, and even that doesn’t always work. the blink program never works when the board is diconnected from the programmer and then reset.
What could be the issue here?
Besides the recommnded decoupling capacitors mentioned in the design guide, the MCU is on just a basic breakout board powered at 3.3V without any other passives/actives hooked up to it. The MCU is freshly out of the reel and the powering scheme is as basic as it gets while still complying with the design guidelines laid out by the document mentioned in this post.

2

So how are you making sure that the MCU boots into the firmware in flash memory and not in system memory (aka the UART bootloader)? Changing those without changing the voltage at the BOOT0 pin might cause exactly that, no?

0690X00000605O2QAI
0690X00000605O2QAI784×210 20.9 KB

3

The STM32L412KB does not have a BOOT1 pin.
Unchecking the nSWBOOT0 bit should override the BOOT0/PH3 pin status:
“Unchecked: BOOT0 taken from the option bit nBOOT0”.
How is this any ifferent from pulling BOOT0 low?

4

Does the problem go away when you revert to the default option bytes?

5

No. The issue remains with the default settings.
I’ve tried a couple different MCU:s to make sure the issue isn’t exclusive to a single MCU.

6

I put up a general question on the ElectricalEngineering stack exchange with some more details on how the circuit is built here: stm32 - Inconsistent boot behaviour with STM32L412 - Electrical Engineering Stack Exchange