Error in initializing ST-LINK device. Reason: (18) Could not verify ST device! Abort connection.

Fixer · ‎2019-10-18

I'm having an issue using STM32CubeIDE to program my blue pill boards. I get the below error each time.

Error in final launch sequence:

Error in initializing ST-LINK device.

Reason: (18) Could not verify ST device! Abort connection.

Error in initializing ST-LINK device.

Reason: (18) Could not verify ST device! Abort connection.

The strange thing is I have no issue programming my boards using ST-Link Utility. I thought that maybe the chips on my boards were counterfeit but I've tried boards from multiple venders now.

I've looked around online and while I found some people getting the "Error in initializing ST-LINK device." message I haven't seen anyone getting "Reason: (18)".

Any help would be appreciated.

Peter BENSCH · ‎2025-04-25

This thread relates to so-called Blue Pill and faked ST-LINK/V2, which uses illegally cloned STM32F103. ST resources are only dedicated to supporting genuine ST products. We are not committed to ensuring that clones/fakes products work properly with the firmware we provide.

We recommend to purchase genuine products from STMicroelectronics and purchase them from known and trusted distributors.

This thread will now be locked. However, if you face difficulties while using genuine ST products, we’re here to assist you. Please feel free to start a new thread, and our team, along with community members, will be ready to help you with any issues/questions you encounter.

Thank you for your understanding.

Regards
/Peter

In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

View solution in original post

Fixer · ‎2019-10-22

Ok, I solved it so I figured I'd update in case anyone comes across this thread in the future. It was 100% due to there being a counterfeit chip on my blue pill board. I bought some chips from DigiKey and used a hot air rework station to swap them out. I no longer get the error message I was seeing.

Beware of venders with counterfeit chips!

C. K. · ‎2019-10-22

I have this exact problem, though when using CubeProgrammer, it does upload to the Blue pill. However using the CubeIDE, I get this error message trying to flash it. Are you sure the actual chip was the problem?

Fixer · ‎2019-10-22

I'm pretty sure, man. Error 18 has to due with not being able to verify the MCU. Then once I put a new, known good, MCU on the board everything programmed as expected. Lots of blue pills has counterfeit MCUs on them. That's why they are so cheap.

C. K. · ‎2019-10-22

Do you think that the problem is only with the CubeIDE not being able to detect none-originial MCUs/linkers but that it works with others? Do you also use the mini st-link v2 USB?

Fixer · ‎2019-10-23

I could always program using St-Link Utility. I've read that the St-Link Utility doesn't check for valid MCUs before programming but that STM32CubeIDE does check. I wanted it to work with the IDE so I could use debugging.

I do use the Mini ST-Link V2 USB programmer.

Ozone · ‎2019-10-23

The ST-Link utility is, AFAIK, not longer maintained or updated, while the CubeProgrammer is pushed as it's replacement.

Counterfeits might have been less of a problem during the lifetime of the ST-Link Utility, explaining the absence respective checks.

JElli.1 · ‎2020-05-15

Yes, hate the blue pill with clone MCU on it. In my case I have a CKS32F103… instead of STM32F103…

However, if you do end up with one, there is a way to get it working with OpenOCD. >>

1. Use OpenOCD as your debugger (GDB will not work)

2. Find the config file : stm32f1x.cfg

Location is similar to this : >>

C:\ST\STM32CubeIDE_1.3.0\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.debug.openocd_1.3.0.202002181050\resources\openocd\st_scripts\target

3. Add the following near the top of stm32f1x.cfg (before the first If – statement):

set CPUTAPID 0

The zero tells OpenOCD to ignore id numbers, which means all clones or genuine MCUs will work.

4. Save the changes. Now your flash and debug should work.

Note: If you change to OpenOCD without changing “stm32f1x.cfg�?, you will get the following Error: “UNEXPECTED idcode: 0x2ba01477…. Expected: 0x1ba01477�?, and you will again be stuck.

Information Source: http://openocd.org/doc/html/TAP-Declaration.html#TAP-Declaration-Commands

OPunc.1 · ‎2020-06-06

I have done as you mentioned above. After that I am getting another type of error -->

Error in final launch sequence:

Failed to execute MI command:

load C:\\Users\\Acer\\Downloads\\Embedde-C\\My_workspace\\Target\\LED_Blink\\Debug\\LED_Blink.elf

Error message from debugger back end:

Error erasing flash with vFlashErase packet

Failed to execute MI command:

load C:\\Users\\Acer\\Downloads\\Embedde-C\\My_workspace\\Target\\LED_Blink\\Debug\\LED_Blink.elf

Error message from debugger back end:

Error erasing flash with vFlashErase packet

Failed to execute MI command:

load C:\\Users\\Acer\\Downloads\\Embedde-C\\My_workspace\\Target\\LED_Blink\\Debug\\LED_Blink.elf

Error message from debugger back end:

Error erasing flash with vFlashErase packet

Please let me know if you have any idea regarding this problem.

JElli.1 · ‎2020-06-06

Yes, I can help you with that. The reset is not working. Try this>>

On the “Debug Configurations�? – page (where you changed “Debug probe�? from …GDB to …OpenOCD), there is one more thing to do >>

Click: “Show generator options…�?
Change: “Reset Mode�? to “Software system reset�?
“Apply�? that, and try again