Bootloader limitations
UM2271
DocID030906 Rev 2
8 Bootloader
limitations
Boot from system Flash memory results in executing bootloader code stored in the system
Flash memory protected against writing and erasing. This allows in-system programming
(ISP), that is, flashing the STM32 user Flash memory. It also allows writing data into RAM.
The data come in via one of communication interfaces such as USART, SPI, I2C bus, USB
or CAN.
Bootloader version is identified by reading the bootloader ID at the address 0x1FFF6FFE.
Its value is 0x91 for bootloader V9.1 and 0x92 for V9.2.
The STM32L4R9AII6 part soldered on the 32L4R9IDISCOVERY main board is marked with
a date code corresponding to its date of manufacturing. STM32L4R9AII6 parts with a date
code prior or equal to week 37 of 2017 are fitted with bootloader V9.1 affected by the
limitations to be worked around, as described hereunder. Parts with the date code starting
from week 38 of 2017 contain bootloader V9.2 in which the limitations no longer exist.
To locate the visual date code information on the STM32L4R9II6 package, refer to its
datasheet (DS12023) available at
www.st.com
, section Package Information. Date code
related portion of the package marking takes Y WW format, where Y is the last digit of the
year and WW is the week. For example, a part manufactured in week 38 of 2017 bares the
date code 7 38.
There is also another mean to identify the need for workaround: before opening the blister of
the Discovery Kit, just check the back side of the blister. At the bottom left side, if the
reference number is equal or higher than 32L4R9IDISCO/ 02-0, it means the bootloader
version is V9.2 and there is no need to apply workaround. Any other inferior number like 01-
0 will need the workaround.
Bootloader ID for the bootloader V9.1 is 0x91.
The following limitation exists in the bootloader V9.1:
Some user Flash memory data get corrupted when written via SPI interface
Description:
During bootloader SPI Write Flash operation, some random 64-bits (2 double-words) may
be left blank at 0xFF
Workarounds:
WA1: add a delay between sending Write command and its ACK request. Its duration
should be the duration of the 256-Byte Flash write time.
WA2: read back after each write operation (256 bytes or at end of user code flashing) and in
case of error start write again.
WA3: Using bootloader, load a patch code in RAM to write in Flash memory through same
Write Memory write protocol as bootloader (code provided by ST). The patch code is
available for download from
www.st.com
website with a readme.txt file containing usage
instructions.
