(DEV_TARGET_RESET_ERR)unable to program stm32f407 MCU

[Cpatt.1]

WHILE PROGRAMMING STM32F407 "DEV_TARGET_RESET_ERR'' ERROR IS REFLECTING

[Sarra.S]

Hello @Cpatt.1​ ,

The DEVTARGETRESET_ERR error is usually caused by an issue with the connection between the STM32F407 and the programmer.

To fix this,

1) first make sure that the USB connection is properly connected

2) Check the settings in STM32CubeProgrammer to ensure that the correct port, frequency, and reset mode are selected.

3) Double-check that the jumpers and connections between the STM32F407 and the programmer are correct.

If you're still having issues, try unplugging the USB cable and then re-plugging it back in after installing the appropriate driver.

Hope that helps!

[Cpatt.1]

Hi, thank you for your respones,

with STM32cubeProgrammer i'm able to connect but when i'm using STM32CubeIDE its giving error as "DEV_TARGET_RESET_ERR''

[Sarra.S]

Hello again @Cpatt.1​,

Could you please refer to this thread which suggests a solution that seems to work for several people.

[daatkins]

Hi everyone,
Sorry for resurrecting an old thread, but I have this exact same error.

I’m trying to program the STM32F407 on my own board design using an STLink v2 with latest firmware and STM32CubeProgrammer v2.15.0 running on Win10 64-bit.

I can’t get the Cube Programmer to connect if RESET MODE is set to Hardware or Software reset (I receive a DEV_TARGET_RESET_ERR error) but I can connect if Core reset mode is selected.

Programming results in the log file below, and despite the verification error at 16:50:32:337, the board starts up running the new code after a manual reset or power cycle.

I’ve tried updating the libusb file to version 1.0.24 (as well as to the latest 1.0.26 version) as recommended in the linked thread without success and also tried installing the Cube Programmer onto three PCs (2x Dells and 1xAsus, all Win10 x64).

Thanks for any help.

16:50:29:654 : Memory Programming ...
16:50:29:654 : Opening and parsing file: Gas_station_PoC_v1.elf
16:50:29:664 : File : Gas_station_PoC_v1.elf
16:50:29:664 : Size : 68.82 KB
16:50:29:664 : Address : 0x08000000
16:50:29:664 : Erasing memory corresponding to segment 0:
16:50:29:664 : Memory Erase via FlashLoader!
16:50:29:664 : Memory erase...
16:50:29:668 : halt ap 0
16:50:29:689 : Erasing internal memory sectors [0 4]
16:50:29:689 : Init flashloader...
16:50:29:689 : halt ap 0
16:50:29:707 : run ap 0
16:50:29:707 : halt ap 0
16:50:29:707 : Loader sector erase...
16:50:29:708 : run ap 0
16:50:31:174 : halt ap 0
16:50:31:176 : Download in Progress:
16:50:31:176 : Size : 70468 Bytes
16:50:31:176 : Address : 0x08000000
16:50:31:180 : halt ap 0
16:50:31:208 : Loader write range...
16:50:31:439 : Init flashloader...
16:50:31:440 : halt ap 0
16:50:31:448 : run ap 0
16:50:31:449 : halt ap 0
16:50:31:458 : run ap 0
16:50:31:716 : run ap 0
16:50:31:861 : Segment[0] downloaded successfully
16:50:31:861 : File download complete
16:50:31:878 : Time elapsed during download operation: 00:00:02.198
16:50:31:895 : Verifying ...
16:50:31:896 : Read progress:
16:50:32:337 : Error: Data mismatch found at address 0x080000B0 (byte = 0xDE instead of 0xDD)
16:50:32:337 : Error: Download verification failed
16:50:32:356 : RUNNING Program ...
16:50:32:356 : Address: : 0x08000000
16:50:34:000 : Warning: The core is halted
16:50:34:016 : Start operation achieved successfully

[daatkins]

Hi again,

I think I’ve fixed the issue; details below for anyone else with the same problem…

I noticed that the STM32F407 datasheet lists the NRST pin as bidirectional (Pin type= I/O) whereas I was driving it from a POR/WDT supervisory chip that has a push-pull output stage, so the processor wouldn’t be able to assert the reset pin.

Lifting the RESET output pin on the supervisory chip and inserting 1K in series seems to have fixed the problem.