0
\$\begingroup\$

I have a very minimal setup for a STM32L412KBT6

It's hooked up on a prototyping board: figure0 The circuit is done according to the official reference guide and effectively looks like this: figure1 (Sorry for the amateurish schematic)

I have a basic blink project written in C++ using PlatformIO with the Arduino core. Here is my program:

#include <Arduino.h> #define LED_PIN PA5 void setup() { pinMode(LED_PIN, OUTPUT); } void loop() { digitalWrite(LED_PIN, HIGH); delay(1000); digitalWrite(LED_PIN, LOW); delay(1000); }

And my platformio.ini:

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

Uploading the code with my STLinkV2 works fine and returns:

CURRENT: upload_protocol = stlink Uploading .pio\build\nucleo_l412kb\firmware.elf 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 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x1fff31f8 msp: 0x20001bb0 ** Programming Started ** Warn : Adding extra erase range, 0x08002a80 .. 0x08002fff ** Programming Finished ** ** Verify Started ** ** Verified OK ** ** Resetting Target ** shutdown command invoked

And looking at the program flash in STM32CubeProgrammer seems to have some data written to it: figure2 The configuration byte is left as default: figure3 However, it seems really unreliable whether the program boots. After programming usually nothing happens, and resetting the MCU does nothing either. Messing with the NRST pin and disconnecting the STLinkV2 USB power sometimes causes the program to start running correctly, but this isn't always the case. I've also tried this with a broken-out nucleo STLink programmer with same results. I've also tried 3 different MCU:s just to make sure the MCU or it's breakout board solder joints aren't faulty. I've also tried every combination of the option bits: nBOOT1, nSWBOOT0 and nBOOT0. Bypassing the PH3/BOOT0 pin with nSWBOOT0 also sometimes makes the program boot right after applying the option byte, but this too is very inconcistent and only works on about 1/10 attempts. My circuit's VCC is at 3.3V.

In short: My MCU seldom boots into it's program memory with given PlatformIO setup and schematic. Setup has been tried with multiple MCU:s and 2 different STLink progrmmers with no difference.

\$\endgroup\$
13
  • \$\begingroup\$ Probably worth mentioning: Sometimes it also starts wrking if I disconnect the programmer from my PC and reconnect it and then click "halt" and then "run" in STM32CubeProgrammer, but this is only slightly more reliable than rewriting the option byte. \$\endgroup\$ Commented Mar 6 at 10:53
  • \$\begingroup\$ So what is the exact question you want an answer for? Also when you say the schematic is done according to official reference guide, no, it isn't, in reality it's very far from it and includes mistakes and other things not made based on the guides. \$\endgroup\$ Commented Mar 6 at 11:49
  • \$\begingroup\$ @Justme I want it to consistently boot into the program memory without having to mess around with the programmer wiring and the option bits. Could you point out what is wrong with the schematic? \$\endgroup\$ Commented Mar 6 at 12:30
  • \$\begingroup\$ For example a ground pin is unconnected. No bypass cap on VDDA. And frankly, from where you even came up with the inductor value of 1 mH. It might be better to throw it away and replace it with a piece of wire. \$\endgroup\$ Commented Mar 6 at 13:19
  • \$\begingroup\$ @Justme I apologize for the oversight. Pin 32 is grounded on the breadboard. I also removed the inductor, which was incorrectly labeled, I used a 10μH coil. I'll upload a corrected version of the schematic to my initial post that represents the current configuration better. Sorry again for the incorrect schematic, it was hastily made. \$\endgroup\$ Commented Mar 6 at 13:32

1 Answer 1

Reset to default
-1
\$\begingroup\$

Make sure your SWCLK and SWDIO pins have external pullup resistors. Otherwise it may be entering a random debug mode on power up. Generally it needs program code to run to activate the internal pullup resistors: while the MCU is reset, the code is not run, and the pins float. It can also be worth having a capacitor on BOOT0.

(the SWCLK/SWDIO pins floating or being inputs at reset can be used to overcome an MCU where the SWCLK and SWDIO pins are configured as output for the application, by resetting it and attempting to connect with an STLINK, sometimes you hit it before the pins are reconfigured as output and can get debug operation again)

\$\endgroup\$
4
  • \$\begingroup\$ This is incorrect. And on two points. You can easily verify the documentation that the MCU has built-in resistors and it specifically mentions having embedded resistors remove the need to add external resistors. Also the SWCLK should have a pull-down, not pull-up. Entering accidentally into weird mode due to SWD pins has never been an issue. And the pull-ups are enabled in reset and if you want to disable them you explicitly need to reconfigure the pins. Boot0 capacitor is also useless, nobody controls the Boot0 pin. In designs with Boot0 cap, you need to wait for it to charge/discharge. \$\endgroup\$ Commented Mar 6 at 12:42
  • \$\begingroup\$ @Mike James Thank you for your input. However, there seems to be no difference after doing the changes you suggested. I added pullups for SWCLK(PA14) and SWDIO(PA13). These are at 10KΩ, please let me know if these are sufficient. I also put a 100nF capacitor between BOOT0(PH3) and VCC. There is also a 100nF capacitor between ground and NRST as recommended in the datasheet. I failed to mention this in the schematic and it's not visible on the breadboard since it's below the MCU breakout. \$\endgroup\$ Commented Mar 6 at 13:03
  • \$\begingroup\$ @Justme -- don't the pullups and pulldowns need to be specifically enabled, though? A pullup that isn't enabled isn't there, and we can't see the setup code. \$\endgroup\$ Commented Mar 6 at 20:04
  • \$\begingroup\$ @ScottSeidman True, we can't see the setup code, but what I said earlier is true, the debug pins are in AF pull-up/pull-down mode after reset says the manual. If you want to use the pins as standard GPIO they need to be specifically set out of AF mode to standard GPIO, with or without pull-up, etc. But the pins boot up as JTAG/SWD pins with respective pull resistors. \$\endgroup\$ Commented Mar 6 at 21:29

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.