| --flash=n[k, M] | st-flash | One can specify `--flash=128k` for example, to override the default value of 64k for the STM32F103C8T6<br/>to assume 128k of flash being present. This option accepts decimal (128k), octal 0200k, or hex 0x80k values.<br/>Leaving the multiplier out is equally valid, e.g.: `--flash=0x20000`. The size may be followed by an optional<br/>"k" or "M" to multiply the given value by 1k (1024) or 1M (1024 x 1024) respectively.<br/>One can read arbitary addresses of memory out to a binary file with: `st-flash read out.bin 0x8000000 4096`.<br/>In this example `4096 bytes` are read and subsequently written to `out.bin`.<br/>Binary files (here: `in.bin`) are written into flash memory with: `st-flash write in.bin 0x8000000` | v1.4.0 |
| --format | st-flash | Specify file image format to read or write. Valid formats are `binary` and `ihex`. | v1.3.0 |
| --freq=n[k, M] | st-info<br/>st-flash<br/>st-util | The frequency of the SWD/JTAG interface can be specified, to override the default 1800 kHz configuration.<br/>This option solely accepts decimal values with the unit `Hz` being left out. Valid frequencies are:<br/>`5k, 15k, 25k, 50k, 100k, 125k, 240k, 480k, 950k, 1200k (1.2M), 1800k (1.8M), 4000k (4M)`. | v1.6.1 |
| --opt | st-flash | Optimisation can be enabled in order to skip flashing empty (0x00 or 0xff) bytes at the end of binary file.<br/>This may cause some garbage data left after a flash operation. This option was enabled by default in earlier releases. | v1.6.1 |
| --reset | st-flash | Trigger a reset after flashing. The default uses the hardware reset through `NRST` pin.<br/>A software reset (via `AIRCR`; since v1.5.1) is used, if the hardware reset failed (`NRST` pin not connected). | v1.0.0 |
| --connect-under-reset | st-info<br/>st-flash<br/>st-util | Connect under reset. Option makes it possible to connect to the device before code execution. This is useful<br/>when the target contains code that lets the device go to sleep, disables debug pins or other special code. | v1.6.1 |
| --hot-plug | st-info<br/>st-flash<br/>st-util | Connect to the target without reset. | v1.6.2 |
| --probe | st-info | Display hardware information about the connected programmer and target MCU. | v1.2.0 |
The latter is also used by the official ST-LINK utility tool from STMicroelectronics as described in the document: [`UM0892 - User manual STM32 ST-LINK utility software description`](https://www.st.com/resource/en/user_manual/cd00262073-stm32-stlink-utility-software-description-stmicroelectronics.pdf).
The `stlink` toolset also provides a GUI which is an optional feature. It is only installed if a gtk3 toolset has been detected during package installation or compilation from source. It is not available for Windows. If you prefer to have an user interface on the latter system, please use the official `ST-LINK Utility` instead.
which is world writable (this is from the `MODE:="0666"` below). I have several files in my `/etc/udev/rules.d` directory. In this particular case, the `49-stlinkv2-1.rules` file contains the following:
Make sure that you have all 3 files from here: https://github.com/stlink-org/stlink/tree/master/etc/udev/rules.d in your `/etc/udev/rules.d` directory. After copying new files or editing existing files in `/etc/udev/ruled.d` you should run the following:
to ensure that the rules actually take effect. Using the trigger command means that you shouldn't need to unplug and replug the device, but you might want to try that for good measure as well.
If the VID:PID of your device doesn't match those in any of the 3 files, then you may need to create a custom rule file to match your VID:PID.
However it appears that not all counterfeited parts cause problems during operation, but some are known to not even being able to execute a basic "blinky" example binary. Further there can be problems that may not even show up or affect you directly, but somewhen later in time (or maybe never).
This demonstrates there is no guarantee for a proper working chip with equal functionality compared to the original.
Please keep this in mind and be sceptical when facing problems with this type of boards.
Check your hardware and try to identify what you have in front of you before assuming a bug in the `stlink` toolset.
Please let us know, if you come across any further websites or tutorials that help to identify STM32 fake chips so we can list them here to help others.
1. No target is connected --> In this case `st-info --probe` displays `chip id 0x0748` with STLINK/V2 and `chip id 0x03e8` with STLINK-V3.
2. The chip is connected but has gone into an undefined state of operation where the SWD pins are unresponsive. --> Try to use `--connect-under-reset` while pressing the reset button on the target board.
3. A firmware-issue prevents the programmer from normal operation. --> Ensure that your programmer runs the latest firmware version and consider to upgrade any older version by using the official firmware upgrade tool provided by STMicroelectronics.
-`unknown chip id! 0xe0042000` --> The memory register holding the information on the chip ID could not be read. The following problems may lead to this case:
1. This problem is caused by the SWDIO and SWCLK being configured for other purpose (GPIO, etc) other than Serial Wire configuration or Jtag --> A possible solution to this is to short the `BOOT0` pin with `VDD` (1) and to reset the chip / board by the execuing `st-flash erase` in order to return the MCU back to normal operation. Afterwards `BOOT0` should be set back to `GND` (0).
2. There is a hardware defect in the connection between the MCU and the used programmer (solder points, cables, connectors).
### d) Understanding hardware and software reset functionality for `st-flash` and reset-related device recovery
Typically a reset signal is sent via the reset pin `NRST`. Using `st-flash` for flashing results in the following behaviour: