This does not seem to work anymore. After I flash the bootloader, ST-LINK Utility v4.5 reports "Unknown firmware type. Don't know hot to upgrade."

After flashing the bootloader, you then can use stsw-link007 to flash (a version of) the ST-Link firmware.  This is the process I found necessary to completely reflash the Chinese ST-Link clones.

The bootloader link above links to the protected bootloader. I believe, this bootloader protects the flash from tampering with, something that people may not want, especially if they want to repurpose their blue pill later. There are also bootloaders, where that flash protection has been disabled: https://github.com/Krakenw/Stlink-Bootloaders

Blue-pill as USB Altera Byte Blaster :-)

https://radiokot.ru/forum/viewtopic.php?f=60&t=130723

Thank you,

The title is changed.

I do not have source codes. I suppose that this is to make sure that the equipment is correct.

I think the title is swapped and the right one is " using blue-pill as st-link".

I also did this long time ago but I always wondered what is the purpose of the resistor devider connected to PA0

I can think of two possibilities:

- The original firmware probably want  to look at the actual I/O rail in the target.  The clones are simplified version from the eval board debugger.  They don't have separate power rails or the level shifting circuits that the full design stand alone "debug pod" version  would have.

- could also be a strapping option to tell the firmware what features it support.  I think that's unlikely due to the amount of unused pins.

As a start, I downloaded the firmware 2.J16.S4

STM32 ST-LINK Utility has updated firmware up to version 2.J25.S4

Everything works stably. In theory, you can take the original scheme on the site STM and check. I did not have such a task.

The ST-Link V2.1 schematic shown in the Nucleo documentation have pin 1 of the SWD header connected (through a diode and 100 ohm resistor (marked [N/A])) to that AIN 1 signal on PA0.  Pin 1 of the SWD is supposed to be connected to the target power.

On the boards I looked at, the diode is populated, but the resistor is not.

Why would you install a diode to just have it flap in the breeze?

If the resistor was populated, the target Vcc would pull up that voltage divider letting the ST-Link firmware know the target voltage.

From the UM1075 User manual of ST-Link, it says:

"The power supply from the application board is connected to the ST-LINK/V2 debugging and programming board to ensure signal compatibility between both boards."

Clive on the STM forum wrote:

"The stand-alone ST-LINK has buffers so that the debugger and the target board can run at different voltages. The NUCLEO/DISCO boards don't have these buffers, and just use/assume the use of 3.0V or 3.3V signalling.

Most of the pins are 5V tolerant, and the VIL/VIH vs VOL/VOH provide a lot of leeway. The idea would be to avoid back-feeding current into a processor via the GPIO pins and skewing the current measurements.

If the target STM32 were running at 1.25V I'd probably want the buffers"

I found this on the web:

https://electronics.stackexchange.com/questions/167414/how-to-reconnect-nucleo-to-st-link-part

"... also make sure that R9 on the stlink exists, on mine it was empty, I had to solder a 4K7 resistor, before that voltage was read as 0V by the stlink and open OCD was issuing a warning message "target voltage may be too low for reliable debugging”