TrueSTUDIO Success

Working with bootloaders on Cortex-M devices

 What is a bootloader?
General definition:

“A boot loader is a computer program that loads the main operating system or runtime environment for
the computer after completion of the self-tests.” - Wikipedia

In microcontroller land (ARM Cortex-M0/M3/M4/M7):

“A bootloader enriches the capabilities of the microcontroller and makes it a self-programmable device”

This is our definition!

2016-04-20 2
 Why use a bootloader?
Enables a device/product to upgrade itself in the field.

• Firmware is rarely bug free! – Need a method to upgrade a product’s

firmware when defects are found.

• New requirements – Need a method to upgrade a product’s firmware due

to new functionality.

A product recall might not be a feasible option!

2016-04-20 3
 Coverage
This document will cover the area of bootloaders from the perspective of
Atollic TrueSTUDIO on ARM Cortex-M devices.

• Constructing and building the bootloader.

• Constructing and building the main application.

• Interaction between the bootloader and the main application.

• Use cases for debugging the above.

2016-04-20 4
 Coverage
It will not cover the actual self-update feature (downloading and flash
reprogramming of the main application)

Many methods exists and are highly application specific!

• Update via USB, USART, CAN, SPI, ...

• Device capabilities.
• Device vendor support libraries.
• Etc.

2016-04-20 5
 Example hardware & code
STM32-F4-Discovery kit
from STMicroelectronics

Download the example projects with ready-made

code from TrueSTORE (inside TrueSTUDIO).

• File  New  Download new example project

from TrueSTORE  STMicroelectronics 
STM32F4-Discovery 
• STM32F4_Discovery_Bootloader_APP
• STM32F4_Discovery_Bootloader_BL

BL = Bootloader. APP = Application. Both must be

downloaded.

2016-04-20 6
 Memory map
• Bootloader and application separated in flash
(Important! Separated by flash pages!)

Our example:

• First 3 16K flash pages allocated to the bootloader.

• 0x08000000 - 0x0800C000
• Reset vector located at 0x08000000

• Rest of the flash allocated to the application Free space

• 0x0800C000 -

Application

0x080C000

Bootloader
0x08000000

2016-04-20 7
 Constructing the bootloader
• Start with a project template generated by the project wizard.
(STM32F4-Discovery board, code in flash memory.)

• Linker configuration file (stm32f4_flash.ld) will, by default, place the

code at the start of flash at 0x08000000. This is what we want!

2016-04-20 8
 Constructing the bootloader
To avoid confusing the debugger when debugging the bootloader and the
application in the same debug session:

• Use different symbolic names for critical functions

• Simplifies breakpoint handling etc.

For instance the entry point for the bootloader will be the Reset_Handler
function by default. You probably have another version with the same name in the
application also!

• Rename Reset_Handler to Boot_Reset_Handler and update all references

(7 in startup_stm32F40xx.s and 1 in stm32f4_flash.ld)!
• Rename main() to boot_main() and update all references!

2016-04-20 9
 A basic boot_main()
• Performs a firmware update if requested (not implemented in this example!).

• Sets up the environment for the application:

• Locates and sets the application stack pointer address. (Stored at first entry in
application vector table.)

• Locates the application entry point. (Stored at second entry in application vector
table.)

• Configures the vector table offset register. (Exceptions/IRQ now finds its
handlers here!)

• Starts the application.

2016-04-20 10
 A basic boot_main()

2016-04-20 11
 Constructing the application
• Start with a project template generated by the project wizard.
(STM32F4-Discovery board, code in flash memory.)

• Linker configuration file (stm32f4_flash.ld) will, by default, place the code at

the start of flash at 0x08000000  0x0800C000. We need to change this! You
may also want to reduce LENGTH of FLASH 1024K- 3x16K = 976K

2016-04-20 12
 Constructing the application
NOTE!

In this example we have chosen to let the bootloader set up the basic
environment (stack pointer, vector table, etc.) for the application.

Lookout for any application code that might circumvent this behavior!

For instance the “SystemInit” in this example:

#ifdef VECT_TAB_SRAM

SCB->VTOR = SRAM_BASE | VECT_TAB_OFFSET; /* Vector Table Relocation in

Internal SRAM */

#else

SCB->VTOR = FLASH_BASE | VECT_TAB_OFFSET; /* Vector Table Relocation in

Internal FLASH */

#endif

2016-04-20 13
 Constructing the application
Always a good idea to verify!

2016-04-20 14
 Putting it all together
Use cases during development

• Debugging the bootloader

• Debugging the application

• Debugging the bootloader & application

• Application programmed by debugger

• Application programmed by bootloader

2016-04-20 15
 Debugging the bootloader
• Create a debug configuration, Download_and_debug_Bootloader, for the
Bootloader project.

• Edit the debug startup script and instruct the debugger to set a breakpoint at
boot_main. (or Boot_Reset_Handler if debugging prior boot_main)

• Start the debugger!

2016-04-20 16
 Debugging the bootloader

2016-04-20 17
 Debugging the bootloader
No source level debugging after branching off to the application (appEntry())

More on that later!

2016-04-20 18
 Debugging the application
• Create a debug configuration, Download_and_debug_Application, for the
Application project.

• The vector table offset register, stack pointer and program counter are setup
just to be on the safe side! Might already be done by debugger or application
startup code!

• Start the debugger!

2016-04-20 19
 Debugging the application

2016-04-20 20
 Debugging the application and
bootloader
In order to do source-level debugging through both the bootloader and the
application project “at the same time” some configuration is needed.

The debugger needs to have information regarding both of the ELF files!

2016-04-20 21
 Debugging the application and
bootloader - use case 1
Both the bootloader and application binary are to be programmed during a
debug launch. Source-level debugging should work after the “jump”.

2016-04-20 22
 Debugging the application and
bootloader – use case 1
Create a third debug configuration connected to the Bootloader project.

2016-04-20 23
 Debugging the application and
bootloader – use case 1
Edit the debugger startup script and instruct the debugger to perform the
following:

• Program the bootloader binary.

• Program the application binary.

• Since the application binary in this case was programmed last we need to re-
add the symbolic information for the bootloader binary.

The debugger is now aware of both the binaries!

• Reset target.
• Set breakpoint at bootloader entry and start execution.

2016-04-20 24
 Debugging the application and
bootloader – use case 1

2016-04-20 25
 Debugging the application and
bootloader - use case 2
Only the bootloader is to be programmed during a debug launch. The application
is programmed by the bootloader (IAP). Source-level debugging should work
after the “jump”.

2016-04-20 26
 Debugging the application and
bootloader – use case 2
Create a fourth debug configuration connected to the Bootloader project. Use the
“Download_and_debug Bootloader” configuration as template.

2016-04-20 27
 Debugging the application and
bootloader – use case 2
Edit the debugger startup script with the following change:

• Add symbolic/debug information from the corresponding application’s ELF file.

2016-04-20 28
 More information:

www.atollic.com

EUROPE & WORLDWIDE USA & AMERICAS

Atollic AB Atollic Inc.
Science Park 241 Boston Post Road West
Gjuterigatan 7 Marlborough, Massachusetts 01752
SE-553 18 Jönköping +1 (617) 674-2655
Sweden
+46 36 19 60 50 [email protected]

[email protected]