The bootloader is stored in the internal boot ROM memory (system memory) of STM32
devices. It is programmed by ST during production. Its main task is to download the
application program to the internal Flash memory through one of the available serial
peripherals (USART, CAN, USB, etc.). A communication protocol is defined for each serial
interface, with a compatible command set and sequences.
This document applies to the products listed in Ta b le 1 . They will be referred to STM32
throughout the document.
Table 1.Application products
TypePart number or product series
STM32F051x6, STM32F051x8
STM32 F1 Mainstream
Microcontroller
STM32 F2 Hi-performance
STM32F40xx and STM32F41xx
STM32L151xx, STM32F152xx, and
STM32F162xx
The main features of the bootloader are the following:
●It uses an embedded serial interface to download the code with a predefined
communication protocol
●It transfers and updates the Flash memory code, the data, and the vector table sections
This application note presents the general concept of the bootloader. It describes the
supported peripherals and hardware requirements to be considered when using the
bootloader of any STM32 device currently in production. However the specifications of the
low-level communication protocol for each supported serial peripheral are documented in
separate documents. For specifications of the USART protocol used in the bootloader
please refer to AN3155. For the specification of CAN protocol used in the bootloader please
refer to AN3154. For the specification of DFU (USB Device) protocol used in the bootloader
please refer to AN3156.
All the documents mentioned below are available from http://www.st.com:
●Datasheets
–Low, medium and high-density STM32F101xx and STM32F103xx datasheets
–Low, medium and high-density STM32F100xx and STM32F102xx datasheets
–STM32F105xx/107xx connectivity line datasheet
–XL-density STM32F101xx and STM32F103xx datasheets
–STM32L151xx and STM32F152xx datasheet
–STM32F162xx datasheet
–STM32F205xx STM32F207xx and STM32F215xx STM32F217xx datasheets
–STM32F405xx STM32F407xx and STM32F415xx STM32F417xx datasheets
–STM32F051x6 and STM32F051x8 devices datasheets
●Reference manuals
–STM32F101xx, STM32F102xx, STM32F103xx and STM32F105xx/107xx
reference manual (RM0008)
–Low, medium and high-density STM32F100xx value line reference manual
(RM0041)
–STM32L151xx, STM32L152xx, and STM32L162xx advanced ARM-based 32-bit
MCUs reference manual (RM0038)
–STM32F205xx, STM32F207xx, STM32F215xx and STM32F217xx advanced
ARM-based 32-bit MCUs reference manual (RM00033)
–STM32F405xx, STM32F407xx, STM32F415xx and STM32F417xx advanced
ARM-based 32-bit MCUs reference manual (RM00090)
–STM32F051xx advanced ARM-based 32-bit
●Flash programming manuals
–STM32F101xx, STM32F102xx, STM32F103xx and STM32F105xx/107xx Flash
programming manual (PM0042)
–Low, medium and high-density STM32F100xx value line Flash programming
manual (PM0063)
–XL-density STM32F101xx and STM32F103xx Flash programming manual
(PM0068)
–STM32L151xx, STM32L152xx, and STM32L162xx Flash programming manual
(PM0062)
–STM32F205xx, STM32F207xx, STM32F215xx and STM32F217xx Flash
programming manual (PM0059)
–STM32F405xx, STM32F407xx, STM32F415xx and STM32F417xx Flash
programming manual (PM0081)
8/88Doc ID 13801 Rev 14
AN2606Glossary
2 Glossary
Low-density devices are STM32F101xx, STM32F102xx and STM32F103xx
microcontrollers where the Flash memory density ranges between 16 and 32 Kbytes.
Medium-density devices are STM32F101xx, STM32F102xx and STM32F103xx
microcontrollers where the Flash memory density ranges between 64 and 128 Kbytes.
High-density devices are STM32F101xx and STM32F103xx microcontrollers where the
Flash memory density ranges between 256 and 512 Kbytes.
Connectivity line devices are STM32F105xx and STM32F107xx microcontrollers.
Low-density value line devices are STM32F100xx microcontrollers where the Flash
memory density ranges between 16 and 32 Kbytes.
Medium-density value line devices are STM32F100xx microcontrollers where the Flash
memory density ranges between 64 and 128 Kbytes.
High-density value line devices are STM32F100xx microcontrollers where the Flash
memory density ranges between 256 and 5128 Kbytes.
XL-density devices are STM32F101xx and STM32F103xx microcontrollers where the
Flash memory density ranges between 768 Kbytes and 1 Mbyte.
Medium-density ultralow power devices are STM32L151xx and STM32L152xx
microcontrollers where the program memory density ranges between 64 and 128 Kbytes.
High-density ultralow power devices are STM32L151xx, STM32L152xx and
STM32L162xx microcontrollers where the program memory density size is 384 Kbytes
STM32F2xxx devices are STM32F215xx, STM32F205xx, STM32F207xx and
SMT32F217xx microcontrollers with a Flash memory density ranging from 128 to
1024 Kbytes.
STM32F4xxx devices are STM32F415xx, STM32F405xx, STM32F407xx and
SMT32F417xx microcontrollers with a Flash memory density ranging from 512 to
1024 Kbytes.
STM32F051xx devices are STM32F051x6, STM32F051x8 microcontrollers where the
Flash memory density ranges between 32 and 64 Kbytes.
Doc ID 13801 Rev 149/88
General bootloader descriptionAN2606
3 General bootloader description
3.1 Bootloader activation
The bootloader is automatically activated by configuring the BOOT0 and BOOT1 pins in the
specific “System memory” configuration (see Ta b l e 2) and then by applying a reset.
Depending on the used pin configuration, the Flash memory, system memory or SRAM is
selected as the boot space, as shown in Ta bl e 2 below.
In some products, BOOT1 is not an I/O but a bit in the option byte area. This is the case for
the STM32F05x devices where BOOT1 is configured through nBoot1 bit in the option bytes.
●When nBoot1 bit is set to 1, it corresponds to BOOT1 reset to 0 in Tab le 2
●When nBoot1 bit is reset to 0, it corresponds to BOOT1 set to 1 n Tab l e 2.
Table 2.Boot pin configuration
Boot mode selection pins
Boot modeAliasing
BOOT1BOOT0
X0User Flash memory User Flash memory is selected as the boot space
01System memorySystem memory is selected as the boot space
11Embedded SRAMEmbedded SRAM is selected as the boot space
Ta bl e 2 shows that the STM32 microcontrollers enter System memory boot mode if the
BOOT pins are configured as follows:
●BOOT0 = 1
●BOOT1 = 0
The values on the BOOT pins are latched on the fourth rising edge of SYSCLK after a reset.
3.2 Exiting System memory boot mode
System memory boot mode must be exited in order to start execution of the application
program. This can be done by applying a hardware reset. During reset, the BOOT pins/bits
(BOOT0 and BOOT1) must be set at the proper levels to select the desired boot mode (see
Ta bl e 2 ). Following the reset, the CPU starts code execution from the boot memory located
at the bottom of the memory address space starting from 0x0000 0000.
10/88Doc ID 13801 Rev 14
AN2606General bootloader description
3.3 Bootloader identification
Depending on the STM32 device used, the bootloader may support one or more embedded
serial peripherals used to download the code to the internal Flash memory. The bootloader
identifier (ID) provides information about the supported serial peripherals.
For a given STM32 device, the bootloader is identified by means of the:
1.Bootloader (protocol) version: version of the serial peripheral (USART, CAN, USB,
etc.) communication protocol used in the bootloader. This version can be retrieved
using the bootloader Get Version command.
2. Bootloader identifier (ID): version of the STM32 device bootloader, coded on one byte
in the 0xXY format, where:
–X specifies the embedded serial peripheral(s) used by the device bootloader:
X = 1: only one USART is used
X = 2: two USARTs are used
X = 3: two USARTs, one CAN and DFU are used
X = 4: two USARTs and DFU are used
–Y specifies the device bootloader version
Let us take the example of a bootloader ID equal to 0x10. This means that it is the
first version of the device bootloader that uses only one USART.
The bootloader ID is programmed in the last two bytes of the device system
memory and can be read by using the bootloader “Read memory” command or by
direct access to the system memory via JTAG/SWD.
The table below provides identification information about the bootloader embedded in
STM32 devices.
1. For connectivity line devices, the USART bootloader returns V2.0 instead of V2.2 for the protocol version.
For more details please refer to the "STM32F105xx and STM32F107xx revision Z" errata sheet available
from http://www.st.com.
USART1/USART3/CAN2/DF
U (USB Device FS)
USART1/USART3/CAN2/DF
U (USB Device FS)
V3.30x1FFF77DE
V3.10x1FFF77DE
USART1/USART2V2.10x1FFF7FA6USART (V3.1)
USART (V3.1)/
CAN (V2.0)/
DFU (V2.2)
USART (V3.1)/
CAN (V2.0)/
DFU (V2.2)
12/88Doc ID 13801 Rev 14
AN2606STM32F100xx, STM32F101xx, STM32F102xx, STM32F103xx, medium-density and high-
4 STM32F100xx, STM32F101xx, STM32F102xx,
STM32F103xx, medium-density and
high-density value line bootloader
Throughout this section STM32F10xxx will be used to refer to low-density, medium-density,
high-density STM32F101xx and STM32F103xx devices, to low- and medium-density
STM32F102xx devices, to low-, medium-, and high-density STM32F100x, and to medium
and high-density value line devices.
4.1 Bootloader configuration
The bootloader embedded in STM32F10xxx devices supports only one interface: the
USART1.
The following table shows the required STM32F10xxx hardware resources used by the
bootloader in System memory boot mode.
Table 4.STM32F10xxx configuration in System memory boot mode
Feature/PeripheralStateComment
Clock sourceHSI enabled The system clock is equal to 24 MHz using the PLL
USART1_RX pinInputPA10 pin: USART1 receives
USART1_TX pin
SysTick timerEnabledUsed to automatically detect the serial baud rate from the host.
USART1Enabled
RAM-
System memory-
IWDG-
Output
push-pull
PA9 pin: USART1 transmits
Once initialized the USART1 configuration is: 8-bits, even parity
and 1 Stop bit
512 bytes starting from address 0x2000 0000 are used by the
bootloader firmware
2 Kbytes starting from address 0x1FFF F000, contain the
bootloader firmware
The independent watchdog (IWDG) prescaler is configured to its
maximum value and is periodically refreshed to prevent
watchdog reset (in case the hardware IWDG option was
previously enabled by the user)
The system clock is derived from the embedded internal high-speed RC, no external quartz
is required for the bootloader code.
After downloading the application binary, if you choose to execute the Go command, the
peripheral registers used by the bootloader (shown in the above table) are not initialized to
their default reset values before jumping to the user application. They should be
reconfigured in the user application if they are used. So, if the IWDG is being used in the
application, the IWDG prescaler value has to be adapted to meet the requirements of the
application (since the prescaler was set to its maximum value by the bootloader).
Doc ID 13801 Rev 1413/88
STM32F100xx, STM32F101xx, STM32F102xx, STM32F103xx, medium-density and high-density
The hardware required to put the STM32 into System memory boot mode consists of any
circuitry, switch or jumper, capable of holding the BOOT0 pin high and the BOOT1 pin low
during reset.
To connect to the STM32 during System memory boot mode, an RS232 serial interface
(example, ST3232 RS232 transceiver) has to be directly linked to the USART1_RX (PA10)
and USART1_TX (PA9) pins.
Note:USART1_CK, USART1_CTS and USART1_RTS pins are not used, therefore user can use
these pins for other peripherals or GPIOs.
For more details about hardware recommendations, refer to application note AN2586:
“STM32 hardware development: getting started”, available from the STMicroelectronics
website: http://www.st.com.
4.3 Bootloader selection
Figure 1.Bootloader for STM32F10xxx with USART1
'%4CMD
14/88Doc ID 13801 Rev 14
OMMAND
RECEIVED
'/CMD
AN2606STM32F100xx, STM32F101xx, STM32F102xx, STM32F103xx, medium-density and high-
Once System memory boot mode is entered and the microcontroller has been configured as
described above, the bootloader code begins to scan the USART1_RX line pin, waiting to
receive the 0x7F data frame: one start bit, 0x7F data bits, even parity bit and one stop bit.
The duration of this data frame is measured using the Systick timer. The count value of the
timer is then used to calculate the corresponding baud rate factor with respect to the current
system clock.
Next, the code initializes the serial interface accordingly. Using this calculated baud rate, an
acknowledge byte (0x79) is returned to the host, which signals that the STM32F10xxx is
ready to receive user commands.
4.4 Bootloader version
Ta bl e 5 lists the bootloader versions of the STM32F10xxx devices.
Table 5. STM32F10xxx bootloader versions
Bootloader version numberDescription
V2.0Initial bootloader version.
– Updated Go Command to initialize the main stack pointer
– Updated Go command to return NACK when jump address is in
V2.1
V2.2
the Option byte area or System memory area
– Updated Get ID command to return the device ID on two bytes
– Update the bootloader version to V2.1
– Updated Read Memory, Write Memory and Go commands to
deny access with a NACK response to the first 0x200 bytes of
RAM memory used by the bootloader
– Updated Readout Unprotect command to initialize the whole
RAM content to 0x0 before ROP disable operation
Doc ID 13801 Rev 1415/88
STM32F105xx and STM32F107xx device bootloaderAN2606
5 STM32F105xx and STM32F107xx device bootloader
5.1 Bootloader configuration
The bootloader embedded in the STM32F105xx and STM32F107xx devices supports four
serial peripherals: USART1, USART2, CAN2, and DFU (USB). This means that four serial
peripherals are supported: USART1, USART2, CAN2 and DFU (USB).
The following table shows the hardware resources required by STM32F105xx and
STM32F107xx devices used by the bootloader in System memory boot mode.
Table 6.STM32F105xx/107xx configuration in System memory boot mode
BootloaderFeature/PeripheralStateComment
Common to
all
bootloaders
RCC
HSI enabled
HSE enabled
-
The system clock frequency is 24 MHz using the PLL.
This is used only for USART1 and USART2
bootloaders and during CAN2, USB detection for
CAN and DFU bootloaders (Once CAN or DFU
bootloader is selected, the clock source will be
derived from external crystal).
The external clock is mandatory only for DFU and
CAN bootloaders and it must provide one of the
following frequencies: 8 MHz, 14.7456 MHz or
25 MHz.
For CAN Bootloader, the PLL is used only to generate
48 MHz when 14.7456 MHz is used as HSE.
For DFU Bootloader, the PLL is used to generate a
48 MHz system clock from all supported external
clock frequencies.
The clock security system (CSS) interrupt is enabled
for the CAN and DFU bootloaders. Any failure (or
removal) of the external clock will generate system
reset.
The independent watchdog (IWDG) prescaler is
configured to its maximum value and is periodically
USART1_RX (PA10), USART2_RX (PD6), OTG_FS_DM (PA11) and OTG_FS_DP (PA12) pins
must be kept at a high or low level during the detection phase.
USB OTG FSEnabledUSB OTG FS configured in Forced Device mode
OTG_FS_VBUS pin
OTG_FS_DM pinPA11: USB Send-Receive data line
OTG_FS_DP pinPA12: USB Send-Receive data line
InterruptsEnabled
Input or alternate
function, automatically
controlled by the USB
OTG FS controller
Used to automatically detect the serial baud rate from
the host for USARTx bootloader.
Once initialized the USART2 configuration is: 8-bits,
even parity and 1 Stop bit. The USART2 uses its
remapped pins.
Once initialized the CAN2 configuration is: Baudrate
125 kbps, 11-bit identifier.
Note: CAN1 is clocked during the CAN bootloader
execution because in STM32F105xx and
STM32F107xx devices, CAN1 manages the
communication between CAN2 and SRAM.
PA9: Power supply voltage line
USB_OTG_FS interrupt vector is enabled and used
for USB DFU communication.
USART1_RX (PA10), USART2_RX (PD6) and CAN2_RX (PB5) pins must be kept at a high or low
level during the detection phase.
The system clock is derived from the embedded internal high-speed RC for USARTx
bootloader. This internal clock is used also for DFU and CAN bootloaders but only for the
selection phase. An external clock (8 MHz, 14.7456 MHz or 25 MHz.) is required for DFU
and CAN bootloader execution after the selection phase.
After downloading the application binary, if you choose to execute the Go command, all
peripheral registers used by the bootloader (shown in the above table) will be initialized to
their default reset values before jumping to the user application.
If the user application uses the IWDG, the IWDG prescaler value has to be adapted to meet
the requirements of the application (since the prescaler was set to its maximum value by the
bootloader).
Doc ID 13801 Rev 1417/88
STM32F105xx and STM32F107xx device bootloaderAN2606
5.2 Bootloader hardware requirements
The hardware required to put the STM32F105xx and STM32F107xx into System memory
boot mode consists of any circuitry, switch or jumper, capable of holding the BOOT0 pin high
and the BOOT1 pin low during reset.
To connect to the STM32F105xx and STM32F107xx during System memory boot mode, the
following conditions have to be verified:
●The RX pins of the unused peripherals in this bootloader have to be kept at a known
(low or high) level, and should not be left floating during the detection phase as
described below:
–If USART1 is used to connect to the bootloader: the USART2_RX (PD6),
CAN2_RX (PB5), OTG_FS_DM (PA11) and OTG_FS_DP (PA12) pins have to be
kept at a high or low level and must not be left floating during the detection phase.
–If USART2 is used to connect to the bootloader: the USART1_RX (PA10),
CAN2_RX (PB5), OTG_FS_DM (PA11) and OTG_FS_DP (PA12) pins have to be
kept at a high or low level and must not be left floating during the detection phase.
–If CAN2 is used to connect to the bootloader: the USART1_RX (PA10),
USART2_RX (PD6), OTG_FS_DM (PA11) and OTG_FS_DP (PA12) pins have to
be kept at a high or low level and must not be left floating during the detection
phase.
–If DFU is used to connect to the bootloader: the USART1_RX (PA10),
USART2_RX (PD6) and CAN2_RX (PB5) pins have to be kept at a high or low
level and must not be left floating during the detection phase.
●Connection to the peripheral to be performed through:
–an RS232 serial interface (example, ST3232 RS232 transceiver) has to be directly
connected to the USART1_RX (PA10) and USART1_TX (PA9) pins when
USART1 is used, or to the USART2_RX (PD6) and USART2_TX (PD5) pins when
USART2 is used
–a CAN interface (CAN transceiver) has to be directly connected to the CAN2_RX
(PB5) and CAN2_TX (PB6) pins
–a certified USB cable has to be connected to the microcontroller (optionally an
ESD protection circuitry can be used)
The USART1_CK, USART1_CTS and USART1_RTS pins are not used, therefore the
application can use these pins for other peripherals or GPIOs. The same note is applicable
for USART2.
Once the USB Device is enabled, all its related pins are dedicated to USB communication
only, and cannot be used for other application purposes.
The user can control the BOOT0 and Reset pins from a PC serial applet using the RS232
serial interface which controls BOOT0 through the CTS line and Reset through the DCD
line. The user must use a full null modem cable. The necessary hardware to implement for
this control exists in the STM3210C-EVAL board. For more details about this, refer to
document: “STM3210C-EVAL board user manual”, available from the STMicroelectronics
website: http://www.st.com.
18/88Doc ID 13801 Rev 14
AN2606STM32F105xx and STM32F107xx device bootloader
5.3 Bootloader selection
The STM32F105xx and STM32F107xx embedded bootloader supports four peripherals
interfaces: USART1, USART2, CAN2 and DFU (USB). Any one of these peripheral
interfaces can be used to communicate with the bootloader and download the application
code to the internal Flash.
The embedded bootloader firmware is able to auto-detect the peripheral interface to be
used. In an infinite loop, it detects any communication on the supported bootloader
interfaces.
Note:The RX pins of the peripherals not used in this bootloader must be kept at a known
(low or high) level and should not be left floating during the detection phase as
described below. Refer to Section 5.2: Bootloader hardware requirements for more
information.
To use the USART bootloader on USART1 or USART2, connect the serial cable to the
desired interface. Once the bootloader detects the data byte 0x7F on this interface, the
bootloader firmware executes the auto-baud rate sequence and then enters a loop, waiting
for any USART bootloader command.
To use the CAN2 interface, connect the CAN cable to CAN2. Once the bootloader detects a
frame on the CAN2_RX pin (PB5), the bootloader firmware enters a CAN loop and starts to
check the external clock frequency value, if the HSE is 8 MHz, 14.7456 MHz or 25 MHz
CAN bootloader firmware enters an infinite loop and waits until it receives a message,
otherwise a system reset is generated.
If a USB cable is plugged into the microcontroller’s USB interface at any time during the
bootloader firmware selection sequence, the bootloader then enters the DFU bootloader
loop waiting for any DFU bootloader command.
To use the USART or the CAN bootloader, it is mandatory that no USB cable is connected to
the USB peripheral during the selection phase. Once the USART or CAN bootloader is
selected, the user can plug a USB cable without impacting the selected bootloader
execution except commands which generate a system reset.
Once one interface is selected for the bootloader, all other interfaces are disabled.
The figure below shows the bootloader detection mechanism. More details are provided in
the sections corresponding to each peripheral bootloader.
Doc ID 13801 Rev 1419/88
STM32F105xx and STM32F107xx device bootloaderAN2606
Figure 2.Bootloader selection for STM32F105xx and STM32F107xx devices
System reset
No
No
Generate system
reset
System init (clock, GPIOs, IWDG,
SysTick)
Configure CAN2
Configure USB
USB cable
detected
No
0x7F received on
USART1
No
0x7F received on
USART2
No
Frame detected on
CAN2_RX pin
Ye s
HSE = 8 MHz,
14.7456 MHz or
25 MHz
Ye s
Execute
BL_CAN_Loop for
CAN2
Ye s
Ye s
Ye s
Configure USART2
BL_USART_Loop for
Configure USART1
BL_USART_Loop for
Execute
USART2
Generate system
reset
Execute
USART1
No
HSE = 8 MHz,
14.7456 MHz or
25 MHz
Ye s
Reconfigure system
clock to 48 MHz and
USB clock to 48 MHz
Execute DFU boot-
loader using USB
interrupts
ai17514
20/88Doc ID 13801 Rev 14
AN2606STM32F105xx and STM32F107xx device bootloader
5.4 Bootloader version
The table below lists the bootloader versions and the changes between all versions of the
STM32F105xx and STM32F107xx devices.
Table 7.STM32F105xx and STM32F107xx bootloader versions
Bootloader version
number
V1.0Initial bootloader version.
V2.0
– Bootloader detection mechanism updated to fix the issue when GPIOs of
unused peripherals in this bootloader are connected to low level or left
floating during the detection phase.
For more details please refer to Section 5.4.2.
– Vector table set to 0x1FFF B000 instead of 0x0000 0000
– Go command updated (for all bootloaders): USART1, USART2, CAN2,
GPIOA, GPIOB, GPIOD and SysTick peripheral registers are set to their
default reset values
– DFU bootloader: USB pending interrupt cleared before executing the Leave
DFU command
– DFU subprotocol version changed from V1.0 to V1.2
– Bootloader version updated to V2.0
Description
– Fixed PA9 excessive consumption described in Section 5.4.4.
V2.1
V2.2
– Get-Version command (defined in AN3155) corrected. It returns 0x22
instead of 0x20 in bootloader V2.0. Refer to Section 5.4.3 for more details.
– Bootloader version updated to V2.1
– Fixed DFU option bytes descriptor (set to ‘e’ instead of ‘g’ because it is
read/write and not erasable).
– Fixed DFU polling timings for Flash Read/Write/Erase operations.
– Robustness enhancements for DFU bootloader interface.
– Updated Bootloader version to V2.2.
5.4.1 How to identify STM32F105xx/107xx bootloader versions
Bootloader V1.0 is implemented on devices which date code is below 937 (refer to
STM32F105xx and STM32F107xx datasheet for where to find the date code on the device
marking). Bootloader V2.0 and V2.1 are implemented on devices with a date code higher or
equal to 937.
There are two ways to distinguish between bootloader versions:
●When using the USART bootloader, the Get-Version command defined in AN2606 and
AN3155 has been corrected in V2.1 version. It returns 0x22 instead of 0x20 as in
bootloader V2.0.
●The values of the vector table at the beginning of the bootloader code are different. The
user software (or via JTAG/SWD) reads 0x1FFFE945 at address 0x1FFFB004 for
Doc ID 13801 Rev 1421/88
STM32F105xx and STM32F107xx device bootloaderAN2606
bootloader V2.0 0x1FFFE9A1 for bootloader V2.1, and 0x1FFFE9C1 for bootloader
V2.2.
●The DFU version is the following:
–V2.1 in Bootloader V2.1
–V2.2 in Bootloader V2.2.
It can be read through the bcdDevice field of the DFU Device Descriptor.
5.4.2 Bootloader unavailability on STM32F105xx/STM32F107xx devices
with a date code below 937
Description
The bootloader cannot be used if the USART1_RX (PA10), USART2_RX (PD6, remapped),
CAN2_Rx (PB5, remapped), OTG_FS_DM (PA11), and/or OTG_FS_DP (PA12) pin(s) are
held low or left floating during the bootloader activation phase.
The bootloader cannot be connected through CAN2 (remapped), DFU (OTG FS in Device
mode), USART1 or USART2 (remapped).
On 64-pin packages, the USART2_RX signal remapped PD6 pin is not available and it is
internally grounded. In this case, the bootloader cannot be used at all.
Workaround
●For 64-pin packages
None. The bootloader cannot be used.
●For 100-pin packages
Depending on the used peripheral, the pins for the unused peripherals have to be kept
at a high level during the bootloader activation phase as described below:
–If USART1 is used to connect to the bootloader, PD6 and PB5 have to be kept at a
high level.
–If USART2 is used to connect to the bootloader, PA10, PB5, PA11 and PA12 have
to be kept at a high level.
–If CAN2 is used to connect to the bootloader, PA10, PD6, PA11 and PA12 have to
be kept at a high level.
–If DFU is used to connect to the bootloader, PA10, PB5 and PD6 have to be kept at
a high level.
Note:This limitation applies only to STM32F105xx and STM32F107xx devices with a date code
below 937. STM32F105xx and STM32F107xx devices with a date code higher or equal to
937 are not impacted. See STM32F105xx and STM32F107xx datasheet for where to find
the date code on the device marking.
5.4.3 USART bootloader Get-Version command returns 0x20
instead of 0x22
Description
In USART mode, the Get-Version command (defined in AN3155) returns 0x20 instead of
0x20.
22/88Doc ID 13801 Rev 14
AN2606STM32F105xx and STM32F107xx device bootloader
This limitation is present on bootloader versions V1.0 and V2.0, while it is fixed in bootloader
version 2.1.
Workaround
None.
5.4.4 PA9 excessive power consumption when USB cable is plugged
in bootloader V2.0
Description
When connecting an USB cable after booting from System-Memory mode, PA9 pin
(connected to V
push-pull and forced to 0 since the USART peripheral is not yet clocked. As a consequence,
a current higher than 25 mA is drained by PA9 I/O and may affect the I/O pad reliability.
This limitation is fixed in bootloader version 2.1 by configuring PA9 as alternate function
push-pull when a correct 0x7F is received on RX pin and the USART is clocked. Otherwise,
PA9 is configured as alternate input floating.
Workaround
None.
=5 V) is also shared with USART TX pin which is configured as alternate
BUS
Doc ID 13801 Rev 1423/88
STM32F101xx and STM32F103xx XL-density device bootloaderAN2606
6 STM32F101xx and STM32F103xx XL-density device
bootloader
Throughout this section STM32F10xxx XL-density is used to refer to XL-density
STM32F101xx and STM32F103xx devices.
6.1 Dual bank boot feature
For STM32F101xx and STM32F103xx XL-density devices (these devices have two Flash
memory banks: Bank 1 and Bank 2), an additional boot mechanism is available which allows
booting from Bank 2 or Bank 1 (depending on the BFB2 bit status (bit 19 in the user option
bytes @ 0x1FFFF800)).
1.When the BFB2 bit is reset, and the boot pins are configured to boot from the Flash
memory (BOOT0 = 0 and BOOT1 = x) then, after reset, the device boots from the
System memory and executes the embedded bootloader code which implements the
dual bank Boot mode:
a) First, the code checks Bank 2. If it contains a valid code (see Note: below), it
jumps to application located in Bank 2 and leaves the Bootloader.
b) If the Bank 2 code is not valid, it checks Bank 1 code. If it is valid (see “note”
below), it jumps to the application located in Bank 1.
c) If both Bank 2 and Bank 1 do not contain valid code (see “note” below), the normal
Bootloader operations are executed as described in the following sections (no
jump to Flash banks is executed). Refer to Figure 3: Bootloader selection for
STM32F10xxx XL-density devices for more details.
2. When the bit BFB2 is set (default state), the dual bank boot mechanism is not
performed.
Note:The code is considered as valid when the first data (at the bank start address, which should
be the stack pointer) points to a valid address into the internal SRAM memory (stack top
address). If the first address points to any other location (out of the internal SRAM) the code
is considered not valid.
A dual bank Boot mode example (FLASH\Dual_Boot) is provided within the STM32F10x
Standard Peripheral Library available on http://www.st.com.
24/88Doc ID 13801 Rev 14
AN2606STM32F101xx and STM32F103xx XL-density device bootloader
For the STM32F101xx and STM32F103xx XL-density devices, the Flash memory, system
memory or SRAM is selected as the boot space, as shown in Tab le 8 below.
Table 8.Boot pin and BFB2 bit configuration
Boot mode
BFB2
bit
selection pins
BOOT1BOOT0
Boot modeAliasing
X0User Flash memory
1
0
01System memorySystem memory is selected as the boot space
11Embedded SRAM
X0System memory
01System memory
11Embedded SRAM
User Flash memory is selected as the boot
space
Embedded SRAM is selected as the boot
space
System memory is selected as the boot space
then dual bank mechanism is executed
System memory is selected as the boot space
then dual bank mechanism is executed
Embedded SRAM is selected as the boot
space
Ta bl e 8 shows that the XL-density devices enter System memory boot mode in two cases:
1.If the BOOT pins are configured as follows: BOOT0 = 1 and BOOT1 = 0
2. Or if:
a) the BFB2 bit is reset and
b) boot pins are configured as follows: BOOT0 = 0 and BOOT1 = x
Note:When conditions a, b, and c below are fulfilled, it is equivalent to configuring boot pins for
system memory boot (BOOT0 = 1 and BOOT1 = 0). In this case normal Bootloader
operations are executed.
a) BFB2 bit is reset
b) Both banks don’t contain valid code
c) Boot pins configured as follows: BOOT0 = 0 and BOOT1 = x
When the BFB2 bit is cleared, and Bank 2 and/or Bank 1 contain valid user application
code, the Dual Bank Boot is always performed (bootloader always jumps to the user code
and never continues normal operations).
Consequently, if you have cleared the BFB2 bit (to boot from Bank 2) then, to be able to
execute the Bootloader code, you have to:
- either, set the BFB2 bit to 1
- or, program the content of address 0x0808 0000 (base address of Bank2) and 0x0800
0000 (base address of Bank1) to 0x0
Doc ID 13801 Rev 1425/88
STM32F101xx and STM32F103xx XL-density device bootloaderAN2606
6.2 Bootloader configuration
The bootloader embedded in STM32F10xxx XL-density supports two serial interfaces:
USART1 and USART2.
The following table shows the required hardware resources of STM32F10xxx XL-density
devices used by the bootloader in System memory boot mode.
Table 9.STM32F10xxx XL-density configuration in System memory boot mode
Feature/peripheralStateComment
Clock sourceHSI enabledThe system clock is equal to 24 MHz using the PLL
SysTick timerEnabledUsed to automatically detect the serial baud rate from the host
Output pushpull
Output pushpull
PA9 pin: USART1 transmits
PD5 pin: USART2 transmits (remapped pins)
USART1Enabled
USART2Enabled
RAM-
System memory-
IWDG-
Once initialized the USART1/USART2 configuration is: 8-bits,
even parity and 1 Stop bit.
2 Kbytes starting from address 0x2000 0000 are used by the
bootloader firmware
6 Kbytes starting from address 0x1FFF E000, contain the
bootloader firmware
The independent watchdog (IWDG) prescaler is configured to
its maximum value and is periodically refreshed to prevent
watchdog reset (in case the hardware IWDG option was
previously enabled by the user)
The system clock is derived from the embedded internal high-speed RC, no external quartz
is required for the bootloader code.
After downloading the application binary, if you choose to execute the Go command, all
peripheral registers used by the bootloader (shown in Tab le 9 ) are initialized to their default
reset values before jumping to the user application.
If the user application uses the IWDG, the IWDG prescaler value has to be adapted to meet
the requirements of the application (since the prescaler was set to its maximum value by the
bootloader).
26/88Doc ID 13801 Rev 14
AN2606STM32F101xx and STM32F103xx XL-density device bootloader
6.3 Bootloader hardware requirements
The hardware required to put the STM32F10xx XL-density devices into System memory
boot mode consists of any circuitry, switch or jumper, capable of holding the BOOT0 pin high
and the BOOT1 pin low during reset.
Note:As explained in Section 6.1: Dual bank boot feature, the System memory boot mode can
also be executed by software when the BFB2 bit is reset, both banks start addresses are
erased, and boot pins are configured to boot from Flash memory.
To connect to the STM32F10xx XL-density devices during System memory boot mode, the
following conditions have to be verified:
●The RX pin of the peripherals unused in this bootloader have to be kept at a known (low
or high) level, and should not be left floating during the detection phase as described
below:
–If the USART1 is used to connect to the bootloader: the USART2_RX (PD6) pin
has to be kept at a high or low level and must not be left floating during the
detection phase.
–If the USART2 is used to connect to the bootloader: the USART1_RX (PA10) pin
has to be kept at a high or low level and must not be left floating during the
detection phase.
●When the BFB2 bit is cleared, and Bank 2 and/or Bank 1 contain a valid user
application code, the Dual Bank Boot is always performed (bootloader always jumps to
the user code and never continues normal operations). Consequently, if you have
cleared the BFB2 bit (to boot from Bank 2), then to be able to execute the Bootloader
code, you have to:
–either, set the BFB2 bit to 1
–or, program the content of address 0x0808 0000 (base address of Bank2)and
0x0800 0000 (base address of Bank1) to 0x0
●Connection to the peripheral to be performed through:
–an RS232 serial interface (example, ST3232 RS232 transceiver) has to be directly
connected to the USART1_RX (PA10) and USART1_TX (PA9) pins when
USART1 is used, or to the USART2_RX (PD6) and USART2_TX (PD5) pins when
USART2 is used
The USART1_CK, USART1_CTS and USART1_RTS pins are not used, therefore the
application can use these pins for other peripherals or GPIOs. This is also applicable for
USART2.
Doc ID 13801 Rev 1427/88
Loading...
+ 61 hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.