STM32G071KBU6 unable to program with STLink V3-minie

[DylanChurch]

While designing Electronic speed controllers for a 6s battery, an stm32 was decided to use as the MCU. 

After receiving our first PCBs, we were unable to successfully program them with the stlinkv3 minie. Attached is an image of the schematic of where the STM lies on the board as well as the attached components. When the boards first came in the stm32 was able to be flashed with a program, but after the first flash they could not be connected to any more. This is with using an external power supply as the stlink v3 didn't seem to provide power as the prg tool was unable to detect the chip.

After continued testing (and changing out the mcu) the issue persisted although with a slight deviation, it would allow us to program it once or twice but when we clear the flash, it would lose connection and throw an error of dev_target_held_under_reset. In case it is relevant, the only connection type that can even read the flash of the chip is hot plug but that is unable to change the data as far as I am aware.

Trying to alleviate this issue, the reset decoupling capacitor was removed in case there was something causing a short, as well as a blank pcb being used with just the microcontroller and capacitors included. Still no luck. In case it was the program that was being applied, the program was changed to a simple blink program, however, even this will not work. We have 2 different layout/schematics for two different tasks that both use the same microcontroller and neither of them are able to program. Either the program tool says no stm32 found, or it says that it is held under reset. I have searched many forums and have not found any solutions that work, including using a 10kOhm resistor from 3.3v to the reset pin in case the internal pullup was not providing enough power to the pin. None of these solutions work. The original software (bootloader and firmware of AM32) works on a nucleo test board with the same steps used to program the custom pcb and the same microcontroller (although different package, they are both 128k flash g071).

This is very frustrating as we have not been able to even test the hardware that we have designed for the past 2 months as we have been stuck trying to program the boards for so long. Any help or solutions that could be provided would be absolutely lovely. The layout of the microcontroller for one of the PCBs is also provided with the reset path highlighted. (Continuity of all of the paths has already been tested and there are no issues in that respect.

[DylanChurch]

When i first power on the stm32 connected to the stlinkv3 minie, the nrst pin has 2.4V across it, however while keeping multimeter on the pin, the voltage steadily drops till it goes under 1.4V.

[Karl Yamashita]

You have ports on SWDIO and SWCLK. Are they connected else where other than to J1?

[DylanChurch]

All of the ports for swd (clk io and rst) are only connected to the header for programming. I dont use them anywhere else. I can send a full schematic ss if needed.

[DylanChurch]

The last code I uploaded i didnt configure the swd pins (only set pb4 as gpio) could this cause it to lose access? Its weird because I was able to flash it more than once...

[Karl Yamashita]

Yes, configuring the debug pins can cause issues. There is a trick to programming but you'll need reset the Nrst pin quickly while connecting the programmer. Takes some timing. If you're debugging, then those pins can't be used for gpio, just only during run time. . 

[DylanChurch]

I didn't set the pins to be GPIO or anything, i just didn't assign them in cubeMX, would that really cause this issue? If that is the case, why did it let me flash it a couple times with the same project before it failed.

[AbrahamIsaac]

dev_target_held_under_reset error usually means your code is reconfiguring the SWD pins as GPIOs or hitting a low-power mode the second it boots.

Since you can only see it in "hot plug," you need to jump into CubeProgrammer. 
There set your Connection Mode to "Under Reset" with the Reset Mode on "Hardware Reset" to catch the core before your firmware locks the debugger out.

Double checking your power as well. if you're really drawing 70mA while idle with the programmer, you've likely got a microscopic bridge or a latch-up on that discolored PCB that's causing the flash mass erase to fail mid-cycle.

[DylanChurch]

I have tried the connection stuff you mentioned, if you look in the original screenshot of the programmer those are the settings being used. As far as a bridge, that's possible but I'm not sure where it would happen, I've checked the wires multiple times and there were no shorts/

[Andrew Neil]

---

@DylanChurch wrote:

I didn't set the pins to be GPIO or anything, i just didn't assign them in cubeMX, would that really cause this issue? 

---

It shouldn't do.

If you don't do anything with them in CubeMX, they should just stay at default - which is SWD.

You could post your .ioc file...

[gbm]

For the SWD pins to work, you should either configure it as SWD or leave them unused - BUT THEN DON'T TICK the "set unused pins as analog" option.