mirror of
https://github.com/rfivet/stm32bringup.git
synced 2024-12-21 00:06:22 -05:00
142 lines
4.5 KiB
HTML
142 lines
4.5 KiB
HTML
|
<!DOCTYPE html>
|
|||
|
|
<html lang="en">
|
|||
|
|
<head>
|
|||
|
|
<meta charset="UTF-8">
|
|||
|
|
<title>2.4 stm32flash</title>
|
|||
|
|
<link type="text/css" rel="stylesheet" href="style.css">
|
|||
|
|
</head>
|
|||
|
|
<body>
|
|||
|
|
<h1>2.4 stm32flash</h1>
|
|||
|
|
|
|||
|
|
So far I have been flashing boards via UART or SWD interface using STM32
|
|||
|
|
Cube Programmer. An open source alternative to flash via UART is
|
|||
|
|
<b>stm32flash</b>.
|
|||
|
|
|
|||
|
|
<h2>Linux Build and Install</h2>
|
|||
|
|
|
|||
|
|
<b>stm32flash</b> project is hosted on
|
|||
|
|
<a href="https://sourceforge.net/projects/stm32flash/">SourceForge</a>
|
|||
|
|
and the git repository is mirrored on
|
|||
|
|
<a href="https://gitlab.com/stm32flash/stm32flash">gitlab</a>.
|
|||
|
|
<p>
|
|||
|
|
I clone the repository from <b>Sourceforge</b> in my <b>Projects</b> folder.
|
|||
|
|
|
|||
|
|
<pre>
|
|||
|
|
$ cd ~/Projects
|
|||
|
|
$ git clone https://git.code.sf.net/p/stm32flash/code stm32flash-code
|
|||
|
|
Cloning into 'stm32flash-code'...
|
|||
|
|
remote: Enumerating objects: 1357, done.
|
|||
|
|
remote: Counting objects: 100% (1357/1357), done.
|
|||
|
|
remote: Compressing objects: 100% (682/682), done.
|
|||
|
|
remote: Total 1357 (delta 912), reused 996 (delta 671)
|
|||
|
|
Receiving objects: 100% (1357/1357), 1.04 MiB | 74.00 KiB/s, done.
|
|||
|
|
Resolving deltas: 100% (912/912), done.
|
|||
|
|
</pre>
|
|||
|
|
|
|||
|
|
Build on Linux doesn’t show any warnings.
|
|||
|
|
|
|||
|
|
<pre>
|
|||
|
|
$ cd stm32flash-code
|
|||
|
|
$ make
|
|||
|
|
cc -Wall -g -c -o dev_table.o dev_table.c
|
|||
|
|
cc -Wall -g -c -o i2c.o i2c.c
|
|||
|
|
cc -Wall -g -c -o init.o init.c
|
|||
|
|
cc -Wall -g -c -o main.o main.c
|
|||
|
|
cc -Wall -g -c -o port.o port.c
|
|||
|
|
cc -Wall -g -c -o serial_common.o serial_common.c
|
|||
|
|
cc -Wall -g -c -o serial_platform.o serial_platform.c
|
|||
|
|
cc -Wall -g -c -o stm32.o stm32.c
|
|||
|
|
cc -Wall -g -c -o utils.o utils.c
|
|||
|
|
cd parsers && make parsers.a
|
|||
|
|
make[1]: Entering directory '~/Projects/stm32flash-code/parsers'
|
|||
|
|
cc -Wall -g -c -o binary.o binary.c
|
|||
|
|
cc -Wall -g -c -o hex.o hex.c
|
|||
|
|
ar rc parsers.a binary.o hex.o
|
|||
|
|
make[1]: Leaving directory '~/Projects/stm32flash-code/parsers'
|
|||
|
|
cc -o stm32flash dev_table.o i2c.o init.o main.o port.o serial_common.o serial_
|
|||
|
|
platform.o stm32.o utils.o parsers/parsers.a
|
|||
|
|
</pre>
|
|||
|
|
|
|||
|
|
I test the newly compiled command first by calling it without argument
|
|||
|
|
<code>./stm32flah</code> then with the serial port where the USB to UART
|
|||
|
|
adapter is plugged in.
|
|||
|
|
<p>
|
|||
|
|
<code>./stm32flash</code> gives a detailed help of the command.
|
|||
|
|
<p>
|
|||
|
|
Calling it with the serial port argument where the board is plugged in
|
|||
|
|
and set in bootloader mode gives a description of the chipset detected.
|
|||
|
|
|
|||
|
|
<pre>
|
|||
|
|
$ ./stm32flash /dev/ttyUSB0
|
|||
|
|
stm32flash 0.7
|
|||
|
|
|
|||
|
|
http://stm32flash.sourceforge.net/
|
|||
|
|
|
|||
|
|
Interface serial_posix: 57600 8E1
|
|||
|
|
Version : 0x31
|
|||
|
|
Option 1 : 0x00
|
|||
|
|
Option 2 : 0x00
|
|||
|
|
Device ID : 0x0444 (STM32F03xx4/6)
|
|||
|
|
- RAM : Up to 4KiB (2048b reserved by bootloader)
|
|||
|
|
- Flash : Up to 32KiB (size first sector: 4x1024)
|
|||
|
|
- Option RAM : 16b
|
|||
|
|
- System RAM : 3KiB
|
|||
|
|
</pre>
|
|||
|
|
|
|||
|
|
I install the command by moving the executable to my local bin directory.
|
|||
|
|
|
|||
|
|
<pre>$ mv stm32flash ~/bin</pre>
|
|||
|
|
|
|||
|
|
If everything goes well, I will later <code>strip</code> and compress (with
|
|||
|
|
<code>upx</code>) the executable.
|
|||
|
|
|
|||
|
|
<h2>Regression Testing</h2>
|
|||
|
|
|
|||
|
|
As my board has been already flashed using STM32 Cube Programmer, I can
|
|||
|
|
perform a simple regression test.
|
|||
|
|
<ul>
|
|||
|
|
<li> Read the content of the chipset memory as previously flashed.
|
|||
|
|
|
|||
|
|
<li> Flash the same executable using Linux version of stm32flash.
|
|||
|
|
|
|||
|
|
<li> Read back the newly programmed chipset memory.
|
|||
|
|
|
|||
|
|
<li> Compare the two read-outs.
|
|||
|
|
</ul>
|
|||
|
|
Reading 1 KB with stm32flash.
|
|||
|
|
|
|||
|
|
<pre>$ stm32flash -r read.bin -S 0x08000000:1024 /dev/ttyUSB0</pre>
|
|||
|
|
|
|||
|
|
Writing the executable in hex format.
|
|||
|
|
|
|||
|
|
<pre>$ stm32flash -w f030f4.hex /dev/ttyUSB0</pre>
|
|||
|
|
|
|||
|
|
Comparing the memory read-out using <code>od</code>, there is no difference.
|
|||
|
|
|
|||
|
|
<h2>Build and Install on Windows</h2>
|
|||
|
|
|
|||
|
|
There is a Windows binary that can be downloaded from <b>stm32flash</b> project
|
|||
|
|
page on <b>SourceForge</b>. But I did clone and build using both <b>Cygwin</b>
|
|||
|
|
and <b>MSYS2 64bit</b> environments on Windows.
|
|||
|
|
<p>
|
|||
|
|
The build phase gave more warnings than the Linux version, this is
|
|||
|
|
mostly due to stricter warnings in the GCC compiler version.
|
|||
|
|
<p>
|
|||
|
|
Usage of <b>stm32flash</b> only differs in the name of the serial device, in my
|
|||
|
|
case <b>COM4</b> instead of <b>/dev/ttyUSB0</b>.
|
|||
|
|
|
|||
|
|
<h2>Checkpoint</h2>
|
|||
|
|
|
|||
|
|
There is several other Windows applications available on ST.com for
|
|||
|
|
flashing STM32 chipsets: STM32 ST-Link Utility, STM32 Flash Loader
|
|||
|
|
Demonstrator, ST Visual Programmer STM32. They have been marked as <b>NRND</b>
|
|||
|
|
(Not Recommended for New Design), which means they won’t support latest
|
|||
|
|
chipsets as they are replaced by STM32 Cube Programmer.
|
|||
|
|
<p>
|
|||
|
|
<a href="25_prototype.html">Next</a>, I will write an application which make
|
|||
|
|
better use of transmission than <b>hello</b>.
|
|||
|
|
|
|||
|
|
<hr>© 2020-2024 Renaud Fivet
|
|||
|
|
</body>
|
|||
|
|
</html>
|