3

So I'm using an STM32F103C8T6 board and it was working fine a few days ago but then tried to load a code with keil vision compiler these days and it showed this message STLINK Error(DEV_TARGET_HELD_UNDER_RESET). After that using the STM32CubeProgrammer also shows the same problem, only connects with the "hot plug" mode as you can see here

Its cleary a reset error, but I really dont know how it happened and don't find much resources on the internet with this problem and now I can't download any code in my stm32f103 board it shows this message

After researching on the internet found it might be soldering problem, but I dont think its the case, i'm only using the microcontroller, not any bread board circuit, and it was perfectly fine days ago. All my write and read protections checkboxes are unchecked in the STM32CubeProgrammer sections too.

I guy on the stcommunity just said "he went through all CPU pins and the board started working." but is it a problem with the pin reset? in the STM32F103C8T6 board it has a reset buton but how can a search a problem in it?

Juliane
  • 31
  • 1
  • 2
  • 5
  • The same is happening to me right now with the STM32F103C, what programmer are you using? I'm using a discovery board as an ST-Link programmer. – smajtkst Jan 06 '21 at 06:32

5 Answers5

5

Ok, this is what I did and now it seems to be working (I'll try to be as descriptive as I can, so you or anyone who's got stuck into this can compare):

  1. I'm using STM32CubeProgrammer v2.6.0 under Ubuntu. The parameters to connect to the target are:
  • Port: SWD
  • Freq: 4000 kHz
  • Mode: Normal
  • Access Port: 0
  • Reset Mode: Software reset
  • Shared: Disabled

  1. I'm using an STM32f4 Discovery as a programmer, to achieve this the jumpers should be disconnected. It is supposed that SB11 jumper (under the board) should be unsoldered too, but as you will see I'm not using the reset line on SWD. The target (STM32F103C8T6) is powered independently (+3.3V).

  2. The connections between the target and programmer are the following:

  • Prog pin1 (VDD) --> NC
  • Prog pin2 (SWD Clock) --> PA14 (Pin#37)
  • Prog pin3 (GND) --> VSS (Pins# 23,35,47 and 9 if common digital analog ground)
  • Prog pin4 (SWD I/O) --> PA13 (Pin#34)
  • Prog pin5 (NSRT) --> NC
  • Prog pin6 (SWO) --> NC

I have access to the target's NSRT (Pin#7) through a push-button (this is important).

Once all this is ready, what I did was to press and hold the reset button, then press the connect button in STM32CubeProgrammer (without releasing the reset), and wait just two seconds, then release the reset. After this process, the target was connected and I was able to program it normally. The program will not run immediately, you need to push and release the reset button again.

Dharman
  • 30,962
  • 25
  • 85
  • 135
smajtkst
  • 461
  • 4
  • 6
  • I tried just what you did pressing the reset button on the board, but it still showing the same message.I'm using win10 and CubeProgrammer v2.6.0, same parameters you use.I'm using an ST-LinkV2 dongle connected to it,with the 3.3v CLW,DIO,GND connections.You can google it to see how I did(can't load any pictures here).On other forums also said to reset the chip similar as you showed.On the STLink utility software, it shows the same error "core held on reset".Do you think I might have changed something in the board configuration that put it on the reset mode?Or that my chip might be damaged? – Juliane Jan 26 '21 at 01:22
  • Can you measure the reset pin voltage on your board? If it is left unconnected from the ST-LinkV2 programmer it should always be 3.3V. If not, your board may have some impedance issues. – smajtkst Jan 27 '21 at 05:30
  • @user1517142 Not me. I am not an author of this post. I only edited it. Please upvote posts instead of saying thanks in the comments. This is a much better way of showing appreciation. – Dharman Feb 23 '21 at 22:21
0

Juliane - the (DEV_TARGET_HELD_UNDER_RESET) message means that something is holding nrst to ground. You can't do much apart from 'hot plug' when in this mode. If you have a reset button then it may have failed in a connected position which will pull NRST to ground defeating the internall pullup.

Can you check the resistance across you reset button in down and up position. I suspect it is 0 ohms (or at least lower than internall pullup resistor).

If you don't have a reset button then check to see what circuitry is around NRST and try to work out why its pulling to ground.

owennewo
  • 301
  • 2
  • 3
0

First you need to clear the existing flash memory it can be done with ST Link Utility or STM32CubeProgrammer

Hold down Reset button while clicking 'connect' on STM-Prog, then navigate to 'Erasing & Programming' and click 'Full chip Erase'

or

while holding reset click Full Chip Erase on ST Link Utility

After the chip is clean try setting the Debug to Serial wire this will allow to flash new code to the board multiple times without having to clear the flash memory or holding reset before upload

in Pinout & Configuration

enter image description here

or in stm32f1xx_hal_msp.c

enter image description here

fiztech-code
  • 1
  • 1
0

"DEV_TARGET_HELD_UNDER_RESET" can also have a hardware reason. I experienced this by accident with a PCB where I mixed up some numbers and ended up with a 10 Ohm resistor instead of a 10k Ohm resistor between 3V3 and the NRST pin on a G431RB. Usually I use a 10k resistor to connect the Reset Switch to the NRST Pin.

The end of the story was, that I was not able to connect to the MCU, the error message was "DEV_TARGET_HELD_UNDER_RESET" and I had some hard time to figure out what it was. Once I replaced the 10 Ohm Resistor with the correct value (10 kOhm) anything worked fine.

Chris_B
  • 359
  • 5
  • 13
0

i got the same error. But holding the reset pin and clicking connect and releasing it did the trick for me after atempting the same procedure two times.

Purnima
  • 13
  • 4
  • Your answer could be improved with additional supporting information. Please [edit] to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers [in the help center](/help/how-to-answer). – Community Jul 19 '23 at 21:11