Configuring UART on STM32F103C8T6 (Bluepill) kills connection to ST-Link

[hbr]

When configuring UART on the board, according to https://wiki.st.com/stm32mcu/wiki/Getting_started_with_UART the program can be flashed once. When trying to flash again the system reports:

Target no device found

Error in initializing ST-LINK device.

Reason: No device found on target.

This happens even when just the configuration is set, no data transmitted and MS_USART_UARTx_Init() is commented out. The error occurs with every UART. It does not disappear when deleting the UART configuration in the IOC editor and regenerate the code without any references to UART. With BOOT0 set to high, reconnecting to ST-Link and flashing another program without configured UART the board behaves normally again. Commenting out HAL_Init() prevents this error, but I strongly assume that leads to other problems. This only happens to the Bluepill board, testing the same configuration with an STM32F407VGT6 (STM32F4-Discovery and an STM32F401CEU6 (Blackpill) stay inconspicuously.

Any ideas how to circumvent this behavior?

[waclawek.jan]

Make sure your program does not set AFIO_MAPR.SWJ_CFG in a way which disables debugging.

Also make sure you don't set system clock outside its operational envelope.

Also, it's unlikely that you have an STM32 on a bluepill board.

JW

[MNapi]

How do you have pins PA14, PA13 setup ?

Debug -> No Debug  (then the problem is here)

or

Debug -> Serial Wire

[Andrew Neil · Accepted solution]

---

@waclawek.jan wrote:

it's unlikely that you have an STM32 on a bluepill board.

---

Indeed.

@hbr  See this thread for a current example of the tale of woe resulting from the bluepill fakery:

https://community.st.com/t5/stm32-mcus-products/blue-pill-stm32f1-board-gets-programmed-through-arduino-ide-but/td-p/667923

[hbr]

After some investigations I tend to the assumption that this is not an original STM32F103C8T6. The information the board gave are not as clearly as in other posts stated, but in sum it looks like this is a fake. I.e. the JDEC data is valid for STMicroelectronics. The test program found in Your linked forum "Bluepill Diagnostics" current version 1.6.40 shows only on anomaly, the DBGMCU_IDCODE is zero. It should be different for ST MCUs. STMCubeProgrammer, successor to the st-link tool, shows zeros where they should not be.

The only strange thing is that there were no problems before. Each project with them worked perfectly.

[hbr]

Thanks for Your answer. The problem seems to be another one. It is very unlikely that I used a real ST MCU but a fake one. This was the first topic I run into trouble with the clone.

[hbr]

Thanks for the link. I made some further investigations with other tools and it strongly looks like I got a clone. In my reply to @waclawek.jan I gave some more details.

The clones are getting better, my ST-Link V2 has a clone inside, an APM32F103CBT6. STLinkUpgrade v3.15.6 updated the firmware without complains.

This was the first project where some trouble occurred, so I didn't think it could be a fake.