Age | Commit message (Collapse) | Author |
|
Values taken from Table 209 (in Section 92 "Device-dependent bootloader
parameters").
Reorder two table entries to maintain same order as in the document.
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
It was only used locally so make it a local.
In any case, this version, reported by the GVR command, should be the
same as the bootloader version reported by the GET command. Print
a warning if they ever happen to not be the same.
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
Based on RM0490 rev 3. Most of the information was found in Section 2
and 3.
https://sourceforge.net/p/stm32flash/code/merge-requests/23/
|
|
Unlike all other ranges in the table, the option byte range is inclusive.
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
These dual-bank devices have two ranges of option bytes, and we
previously listed the start of the first and the end of the second.
Since we use the range (only) to display the number of option bytes,
this can get very wrong for some dual-bank devices where the two ranges
are far apart. So for consistency ignore the second range, as long as
our table only support one range.
https://sourceforge.net/p/stm32flash/tickets/92/
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
These locations are not RAM.
https://sourceforge.net/p/stm32flash/tickets/92/
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
RM0478 rev 5:
Table 3. Flash memory - Single bank organization
(untested)
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
RM0438 rev 7:
Table 30. Flash module - 512 KB dual bank organization (64 bits read width)
Section 6.3.1: "option bytes [...] not mapped to any memory address"
(untested)
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
RM0432 rev 9:
Table 5. Memory mapping versus boot mode/physical remap
footnote: "1 Mbyte for STM32L4P5xx and STM32L4Q5xx devices"
Table 8. Flash module - 1 Mbyte dual-bank organization, DB1M = 1
(64 bits read width)
Note the options bytes are split between 0x1FF00000-0x1FF0000F for
bank 1 and in 0x1FF01000-0x1FF0100F for bank 2, and we only list the
first in our table.
(untested)
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
RM0471 rev 7:
Table 3. Flash memory - Single bank organization
(untested)
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
RM0456 rev 3:
Table 44. Flash module 2-Mbyte dual bank organization
Section 7.3.1:
"option bytes [...] not mapped to any memory address"
(untested)
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
RM0455 rev 6: (STM32H7A3/7B3 and STM32H7B0 Value line)
Table 12. Flash memory organization (STM32H7A3xI/7B3xI devices)
Section 4.3.4:
"The embedded Flash non-volatile memory is composed of:
- For STM32H7B3xx and STM32H7A3xI devices: a 2-Mbyte main memory block,
organized as two banks of 1 Mbyte each.
- For STM32H7A3xG devices: a 1-Mbyte main memory block, organized as two
banks of 512 Kbyte each."
"Each bank is in turn divided in up to 128 sectors of 8 Kbytes each"
(untested)
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
RM0468 rev 3: (STM32H723/733, STM32H725/735 and STM32H730 Value line)
Table 15. Flash memory organization (STM32H723/733 and STM32H725/735 devices)
Section 4.5.2: "Any 128-Kbyte Flash sector can be independently
write-protected or unprotected"
(untested)
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
https://sourceforge.net/p/stm32flash/tickets/151/
Data sources:
* RM0453 Rev 4 Table 11
* AN2606 Rev 55 Table 159
|
|
Somebody needs to look up the datasheets and fill in the missing numbers.
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
https://sourceforge.net/p/stm32flash/tickets/146/
|
|
https://sourceforge.net/p/stm32flash/tickets/150/
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
At least on macOS this can happen if the baud rate is not supported on
the serial port. Unfortunately we cannot tell more specifically what
went wrong in this case.
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
https://sourceforge.net/p/stm32flash/tickets/141/
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
If the baud rate is specified as zero with -b 0, stm32flash will not do
any configuration at all of the port. This can be useful for tunnelling
over various transports, or for e.g. separately setting up baud rates in
platform-specific ways that stm32flash doesn't handle.
Example:
stty -F /dev/ttyUSB0 raw parenb -parodd -cstopb cs8 115200 time 5 min 0 \
line 0 -brkint -icrnl -imaxbel -opost -onlcr -isig -icanon -iexten \
-echo -echok -echoctl -echoke
stm32flash -b 0 /dev/ttyUSB0
Example UDP transport with socat:
hostA$ socat /dev/ttyUSB0,nonblock,rawer UDP-LISTEN:3334
hostB$ socat UDP:hostA:3334 PTY,link=/tmp/ttyremote,rawer
hostB$ stm32flash -b 0 /tmp/ttyremote
This has only been tested on Linux.
https://sourceforge.net/p/stm32flash/code/merge-requests/15/
https://sourceforge.net/p/stm32flash/tickets/94/
https://sourceforge.net/p/stm32flash/tickets/105/
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
Fixup of commit 666dde2e
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
Test case:
echo "Short data chunk" | stm32flash /dev/ttyUSB0 -S 0x20008000 -w -
stm32flash -c /dev/ttyUSB0 -S 0x20008000:0x20 -r - | hd
https://sourceforge.net/p/stm32flash/tickets/129/
|
|
Also fixes unnecessary padding when start at offset != 0
https://sourceforge.net/p/stm32flash/tickets/121/
|
|
AN2606 rev 49 table 152 says 0x20002100-0x20008000, but testing shows it
only should be from 0x20003100. This is the 32KB in SRAM1, without the
8KB in SRAM2.
The STM32L412xx and STM32L422xx datasheets confirm 128KB flash.
https://sourceforge.net/p/stm32flash/tickets/114/
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
As per AN2606 the USART bootloader (ID V13.1) on STM32L412xx/422xx
devices "replies with two ACK bytes (0x79) instead of only one".
Thanks to Andy Little for reporting, initial patch, and testing.
https://sourceforge.net/p/stm32flash/tickets/114/
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
Also error out earlier in this case. This won't change anything in
practice according to my tests, because the flag setting would also fail
if the speed setting failed. However, the error messages can now help
distinguish different failure modes.
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
We were just returning an unknown error which is not very helpful to the
user. This will help for some cases.
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
It could be a lot more straightforward in the BSD case but with
our current baud handling code this is what we get for cheap.
https://sourceforge.net/p/stm32flash/tickets/127/
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
For Windows also fill in all baud rates defined in WinBase.h.
For Posix platforms the higher rates will available if defined in the
system headers, which is the case for Linux.
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
From the beginning the actual flush was commented out and not adapted to
the Windows API since at the time there was no apparent need to flush.
Especially since the GPIO sequences were added flushing can be needed,
for instance after resetting into the bootloader from a talkative
application.
Thanks to Jan Belohoubek for reporting, fix, and testing.
https://sourceforge.net/p/stm32flash/tickets/132/
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
Oops, I got this wrong while amending commit b079cd09.
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
For I2C the protocol is slighly different than for USART,
requiring a checksum after the number of pages.
https://sourceforge.net/p/stm32flash/tickets/98/
Signed-off-by: Yann Sionneau <ysionneau@kalray.eu>
[Tormod: Add port flag, no wait, amend messages]
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
Add values from RM0440 rev 6 sections 2.4 and 4.3.1 and 5.4.1
(untested)
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
(The previous commit actually added STM32G0B0/B1/C1xx)
Filled in values from RM0444 Rev 5 table 4 (untested)
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
Based on RM0444 Rev5 (chapter 3) and AN2606 Rev 49 (chapter 70, table 152).
|
|
We only miss 11 devices from AN2606 rev 49 (July 2021). Fill in the list
with the information from Table 152 in the hope that missing device
parameters and testing will be contributed.
AN2606 has conflicting information for instance for STM32WB30xx in
Table 148 (20 KB for bootloader) and Table 152 (16 KB), and for
STM32WB10xx Table 146 (16 KB) vs Table 152 (20 KB).
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
The effect of the -S parameters is old, but that the
file content size (for binary files) is used was only
recently introduced.
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
This allows setting a length but an empty address.
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
Also if a write length is known from the file size.
Commit 5dbb767 "Do not erase more than file contents indicate"
caused a regression if no start address was given, in which
case the start address was set to be 0.
Also improve handling of the case where the user specifies
start address 0.
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
The posix or w32 files should ideally be picked
by a conditional but this has to do for now.
Also ship all documentation files and Android
build files in the generated dist tarball.
Also allow to ship our handmade makefiles in the
tarball made by the autogenerated makefiles.
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|