STM32 flashing/programming

[TimSmall]

Since nobody else has mentioned it...

When using single wire debug, you should only connect the VCC (from the mcu board to the programmer) if the microcontroller is not already receiving a separate supply voltage.  If the mcu is already getting VCC from elsewhere (e.g. battery, or a separate supply), then you should only connect the other three lines (single wire data, clock, and ground), plus optionally (but recommended) reset.

As it happens, that's the config that I'm using for the STM32F401 (WeAct Studio dev board) which is sitting on my desk at the moment...  The MCU is receiving power over USB, so the debug probe doesn't have VCC connected.

Reset isn't always needed, but can be useful, because it's possible to put the chip into some states where the SWD interface doesn't work (e.g. some power saving sleep states) - so if the swd programmer hardware can also drive the reset line of the target mcu, then it can guarantee that it will always be able to interact with it via SWD and program the part etc.

For programming and debugging, I'm using https://probe.rs/ - but there are many other options of course, and you should use whatever tooling seems most appropriate for your development environment.

[ataradov]

There are not a lot of programmers that provide power. But there are a lot of programmers that use voltage level shifters, so they need target VCC to power the output buffers.

[SiliconWizard]

There are not a lot of programmers that provide power. But there are a lot of programmers that use voltage level shifters, so they need target VCC to power the output buffers.

Absolutely. When wiring a SWD adapter, you should *always* check that, as there is no hard guarantee and you could blow something up if not careful.

Strictly speaking, the standard JTAG connector (both the 20-pin and mini 10-pin one) defines a VTref pin, which is an *input* and serves as the target voltage ref for level shifting and detecting that the target is connected. It should not be an output and provide power to the target.

But many commercial programmers do provide target power as a convenience, which is not compliant (AFAIK) if using a standard JTAG connector, but if they use any other kind of connector, then everything goes and READ the manual.

[zapta]

>> I don't understand why you are bothering with this bootloader. The best thing you can do with it is forget that it exists.

Boot loaders are useful for firmware upgrade by users, but for development, SWD is definitely they way to go.

[ataradov]

No user ever will be using that bootloader. Are you going to ask your users to bust out their USB to UART adapter? Not a chance. Any real product will have a more useful and appropriate update method.

USB MSD bootloader are probably the most user friendly, but that still implies that your product has USB.

ROM bootloaders are useless and are a relic of the past when tools cost $100s for no real reason other than greed.

Typical ROM bootloaders don't include any encryption, so you will also be giving everyone your complete firmware.

[zapta]

My current design has a usb/serial adapter for data link and I provide a binary that flashes it with no extra tools. The binary is a python script converted to a binary using pyinstaller, and is distributed with the other binaries of the app.

https://github.com/zapta/daq/blob/f07ed5b4b486846a237b91fb82ccbbd1ab3feb26/host/src/flasher.py#L1

[ataradov]

This is fine for open projects oriented at technical people willing to run Python from the command line.

This will not work for commercial products where users at best can install an app from the store.

[zapta]

Yes, open code. And the flasher is a single binary so no need to install python. 

I am using this tool to generate the binary from the python sources https://pypi.org/project/pyinstaller/