ST-LINK error (DEV_TARGET_NOT_HALTED)

[Doc McStuffins]

I am currently working on a bootloader using the NUCLEO-F446RE development board, which consists of a program that erases sectors 3-7 of the MCU's flash memory to create space for a program. When run my bootloader's erase function and then attempt to re-program the board using the "debug" button in the STM32CubeIDE, I get the following error on the console, and the board refuses to be reprogrammed:

STMicroelectronics ST-LINK GDB server. Version 5.2.3
Copyright (c) 2019, STMicroelectronics. All rights reserved.
 
Starting server with the following options:
 Persistent Mode : Disabled
 Logging Level : 1
 Listen Port Number : 61234
 Status Refresh Delay : 15s
 Verbose Mode : Disabled
 SWD Debug : Enabled
 
Waiting for debugger connection...
Debugger connected
 -------------------------------------------------------------------
 STM32CubeProgrammer v2.1.0 
 -------------------------------------------------------------------
 
 
 
Log output file: C:\Users\johnm\AppData\Local\Temp\STM32CubeProgrammer_a10620.log
ST-LINK SN : 066DFF485151717867194350
ST-LINK FW : V2J34M25
Voltage : 3.25V
Error: ST-LINK error (DEV_TARGET_NOT_HALTED)
Encountered Error when opening C:\ST\STM32CubeIDE_1.0.1\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.win32_1.0.0.201904021149\tools\bin\STM32_Programmer_CLI.exe
Error in STM32CubeProgrammer

This issue is only present when I use HAL drivers to erase a portion of the flash memory of the chip, as shown in the below code snippet. I do not believe that I am erasing any of my code, as the flash erase starts in sector 3, and the build size of my program is ~42Kbytes, which should only take up sectors 0-2.

HAL_StatusTypeDef status = HAL_FLASH_Unlock();
	if (status != HAL_OK) {
		DPRINT("unable to unlock flash before erasing, status 0x%x\n", status);
	}
 
	FLASH_EraseInitTypeDef erase_init;
	erase_init.TypeErase = FLASH_TYPEERASE_SECTORS;
	erase_init.Banks = FLASH_BANK_1;
	erase_init.Sector = FLASH_SECTOR_3;
	erase_init.NbSectors = 5; // erase sectors 3-7
	erase_init.VoltageRange = FLASH_VOLTAGE_RANGE_3;
	uint32_t sector_error;
 
	status = HAL_FLASHEx_Erase(&erase_init, &sector_error);
	if (status != HAL_OK) {
		DPRINT("error erasing firmware sector 0x%lx, status 0x%x\n", sector_error, status);
	} else {
		DPRINT("erased all firmware sectors\n");
	}
 
	status = HAL_FLASH_Lock();
	if (status != HAL_OK) {
		DPRINT("unable to lock flash before erasing, status 0x%x\n", status);
	}

Currently, the workaround to this issue that I have found is to connect to the board with the STM32 ST-Link Utility and perform a full chip erase before reconnecting and programming successfully with STM32CubeIDE. However, this workflow is slow and rather cumbersome. I have done my best to find any information about the DEV_TARGET_NOT_HALTED error but have so far found nothing. Is this a bug with STM32CubeIDE, or with my code? Some tips or assistance would be greatly appreciated!

[Inna_Z]

The same error, but I try to erase and program only 7 sector

[rk8266882]

• The same error, when using ST STD PERIPH library specifically to erase flash sector 4 on NUCLEO-F446RE dev.
• One more observation is the issue doesn't happen when all the sectors in the range 4-7 are erased.
• 

 

[Ozone]

> This issue is only present when I use HAL drivers to erase a portion of the flash memory of the chip, as shown in the below code snippet. I do not believe that I am erasing any of my code, as the flash erase starts in sector 3, and the build size of my program is ~42Kbytes, which should only take up sectors 0-2.

I would nonetheless check the map file, to see if the linker places anything at unexpected locations.

I'm not a friend of Cube/HAL, and confusing hidden code it comes with. Perhaps such Cube code runs in a timeout, and ends up in an endless loop.

How many flash banks the F446 has ? I suppose only one, and code execution would always stall during erase.

> Currently, the workaround to this issue that I have found is to connect to the board with the STM32 ST-Link Utility and perform a full chip erase before reconnecting and programming successfully with STM32CubeIDE.

As has usually been the last-resort method with "uncooperative" target code. In pre - Cube times, this used to be re-assigning JTAG/SWD pins, or sleep modes, which were keeping the debugger from getting access to the core.

[Dazdranagorn]

I’ve catch this issue with STM32CubeIDE 1.1.0 on Nucleo-144 (STM32F767ZIT6).

I disable Software system reset to void debugger stops on DEV_TARGET_NOT_HALTED in

Debug Configurations -> Debugger -> Reset Behavior Type: None.

In my case this works. It helps me debug around Flash access procedures. 

But is not proper decision.

[rk8266882]

This worked for me...

[JAhma.1216]

I just had the same issue, but managed to solve it.

I ran a test code like you, and with the same result.

Turns out, the debugger resets the MCU (probably without halting it quick enough) so the flash-erase is initiated just before the debugger starts trying to flash the program. Then of course the debugger can't flash properly (since flash controller is busy with the erase), causing this issue.

Adding a delay of a second or two in the beginning of my program (before the flash erase/write starts), solved the issue and I can now debug properly.

[cgirard]

This worked for me! Thanks for the explaination. 1s deday sufficed for me.

Also, debugging without reflashing also works, but it implies that you can't modify the code you're trying to debug, which is cumbersome to say the least.

[RBharol]

I faced the same issue today i.e.,

Error: ST-LINK error (DEV_TARGET_NOT_HALTED)

and I couldn't find a solution online to fix it. Finally I tried the following and it worked.

I am using STM32H745I-DISCO board. Here are the steps I took to fix the issue:

1) Removed power to the board.

2) Shoted JP3 jumper to keep STLink in Reset.

3) Set Jumper JP8 to USB Power.

4) Connected JLink to CN16 Tagconnect to use JLink.

5) Connected to JLink from Ubuntu command line by typing JLinkExe (You can use windows version too)>

6) Did unlock LM3Sxxx to unlock the flash (follow the instructions printed by the command)

7) Run erase

8) If any of the above fails, do unlock and erase until it passes.

9) You are all set. You can connect using STLink or JLink without issues.

10) Make sure to not program the version that killed it to begin with.

[srikarthik0601]

I dont have a Jlink to use, is there any other way?

 

[JBust.1]

Hi,

It happened to me with a stm32f411cc, I reserved memory in sector 5 in linker file, I wrote (I deleted the sector and then I wrote). from there began to get Error: ST-LINK error (DEV_TARGET_NOT_HALTED).

Fix it by pressing RST for a few seconds when the program is loading. with that it worked and continued programming normal.

[JDIVO.1]

Plug and unplug the device and then retry. For me it worked.

[Hueli.1]

I had the same issue after flashing a corrupted build.

The solution is to select Hardware reset under Reset mode in STM32Cube Programmer