Hints

stm32flash help and hints

GPIO sequences changes

Note that in versions prior to stm32flash 0.6 there was an implicit (but undocumented) 600 ms pause after the GPIO signalling. In version 0.6 and later there are only the pauses introduced by the commas (consistent with the documentation in the manual page). If your device requires additional time after the GPIO signalling, add trailing commas (each comma adds 100 ms) to your init sequence. Also from version 0.6 an exit sequence is always executed.

Raspberry Pi 3 UART and pin control

The mini-UART on the RPi3 has important limitations. According to a report the best config seems to be:

dtoverlay=miniuart-bt
enable_uart=1

and remove the segment from cmdline.txt:

console=serial0,115200

Then use ttyAMA0 for stm32flash.

The GPIO sysfs support has been removed in recent Raspberry Pi kernel builds, so instead of a -i sequence, use RPi pinctrl. Example with gpio17 on boot0 and gpio27 on reset:

pinctrl 17 op dh
pinctrl 27 op dl
sleep 0.1
pinctrl 27 op dh
sleep 0.2
sudo stm32flash -b 115200 /dev/ttyAMA0 -v -w generic_boot20_pc13.bin
sleep 0.5
pinctrl 17 op dl
pinctrl 27 op dl
sleep 0.1
pinctrl 27 op dh

Linux (< 4.10) and CH340/341 USB-serial adapters

The CH340/CH341 driver version delivered with older Linux distributions lacks support for parity. The STM32 bootloader requires even parity to be used. Typical symptom of the problem is that the initial communication (0x7F, 0x79) works, but no answer to the next command sequence (0x01+0xFE) is received (1). The problem can be fixed by installing a newer kernel or patching an old with a CH34x driver patch from https://github.com/karlp/ch341-linux/blob/master/0001-usb-serial-ch341-Add-parity-support.patch .
Note (1): all these initially transferred bytes look the same on the line when transmitted without parity or when transmitted with even parity, because the parity bit would be '1' as a stop bit would be. The 0x01+0xFE sequence cannot be received with even parity if the characters are transmitted end to end, resulting in a framing error due to a missing stop bit.

This is no longer a problem in Debian 10 (buster), Ubuntu 18.04, Fedora 26 or any system using Linux kernel 4.10 or newer.

(From https://sourceforge.net/p/stm32flash/tickets/81/?limit=25&page=1#7106)

MacOSX and PL2303 USB-serial adapters

Commented in http://code.google.com/p/stm32flash/issues/detail?id=36
It was a driver problem and the funny part is that I found a driver better than the Prolific's one.
It's from the osx-pl2303 project and the setup instructions are here : http://xbsd.nl/2011/07/pl2303-serial-usb-on-osx-lion.html"