STM32F103 – STlink vs Serial programmer

[3dgeo]

Howdy,

what is the better way to upload and debug STM32F103? I'm using cheap"FTDI" serial programmer and it seems to work just fine, I've never used STlink (V2), what advantages STlink has over serial uploader? Should I change debugging and uploading interface for my product from serial to STlink? It mainly be used to upload HID bootloader.

[GromBeestje]

I assume with serial uploader, you mean using the BOOT0/BOOT1 pins to enter "programming mode" and then use the serial connection to flash the firmware.
If you use it only to upload a bootloader, and use the bootloader to flash the firmware, I don't see the advantage.

The advantage of STlink (or any other debugger) is the ability to actually debug the firmware, as in, step through the code, look at register content, etc.

[lucazader]

I would go with the if it ain't broke don't fix it approach here probably.

In saying that in general the st-link will be slightly easier if your general dev environment supports loading code using the st-link.
It doesn't require control over the BOOT pin to boot into the uart bootloader to download the flash.
It also allows you to properly debug the code with breakpoints etc if and when you need.

But yea if you already have a process that works for your product, and you are mainly talking about the production process (eg loading the HID bootloader into bare chips and then the final update happens later in the production process) then i think your current method is just as good as any other!

[3dgeo]

I assume with serial uploader, you mean using the BOOT0/BOOT1 pins to enter "programming mode" and then use the serial connection to flash the firmware.
If you use it only to upload a bootloader, and use the bootloader to flash the firmware, I don't see the advantage.

The advantage of STlink (or any other debugger) is the ability to actually debug the firmware, as in, step through the code, look at register content, etc.

Oh, You brought a point that slipped out of my mind – BOOT0/BOOT1 pins. Currently PCB design is with BOOT0/BOOT1 pulled down by 10K resistors. And I break out SWDIO and SWCLK for programming bootloader, I don't want to play with pulling up/down pins to enter programming mode, that's why I would like to migrate to ST link instead, plus extra debugging features would be nice.

But it's uncharted territory,  can I use only SWDIO, SWCLK, GND for ST link and provide 3.3V via product USB pot?

[thm_w]

But it's uncharted territory,  can I use only SWDIO, SWCLK, GND for ST link and provide 3.3V via product USB pot?

Yes. With the clone STLink + nucleo, it doesn't care if 3.3V connection is present as long as the chip is powered. But I always put 3.3V to allow external power of the device (at least for initial testing). You should have a spot to access RST as well, but generally its not needed.

My standard debug header is 3.3V/IO/CLK/Gnd.

[3dgeo]

SWDIO, SWCLK has to be pulled up/down on the PCB?

[jhpadjustable]

SWDIO, SWCLK has to be pulled up/down on the PCB?

Of course, just the same as any other input. The usual recommendation is SWCLK 100k to ground, SWDIO 100k to +V, which is easily tucked next to the debug connector.

[GromBeestje]

SWDIO, SWCLK has to be pulled up/down on the PCB?

Of course, just the same as any other input. The usual recommendation is SWCLK 100k to ground, SWDIO 100k to +V, which is easily tucked next to the debug connector.

Nope, the STM32F103 has internal pullups/downs.  TRM RM0008  paragraph 31.4.3 page 1081

To avoid any uncontrolled IO levels, the device embeds internal pull-ups and pull-downs on
the JTAG input pins:
• NJTRST: Internal pull-up
• JTDI: Internal pull-up
• JTMS/SWDIO: Internal pull-up
• TCK/SWCLK: Internal pull-down

[3dgeo]

Thank you!