This presentation is Part 2 of 3 illustrating ARM® Cortex™ M boot sequence. Hands on illustration uses EFM®32 Zero Gecko starter kit based on Cortex M0+ core from Silicon Labs.
Simplicity Studio IDE from Silicon Labs was used to create a sample project (Bundled with Simplicity Studio), set breakpoints and inspect various entry points and other points of interest to get a introductory look at Cortex boot sequence
1. ARM® Cortex™ M Bootup & CMSIS -
Part 2 / 3
Raahul Anand Raghavan, Lead Systems Architect,
Glyton Solutions
!1
2. Agenda
• Before We Proceed!
• System Init & Boot Sequence
• ISR / Vector Table
• What happens on a RESET ?
• Typical Cortex M boot up sequence
• CMSIS Core - System Init & Boot Perspective
• EFM® 32 ARM® Cortex M0+ Starter Kit
• Simplicity Studio IDE
• Hands On!
• Project & Folder structure
• Linker description
• EFM®32 CMSIS Start-Up , System Configuration & Application functionality
• Setting Breakpoints & Inspecting entry
• Whats in Part 3 ?
!2
3. Before We Proceed!
• This is part 2 of a 3 part presentation which would practically introduce
ARM® Cortex M boot up / system initialization & CMSIS interface
• Presentation is introductory and in depth coverage of topics is out of the
scope
• Involves Cortex M0 based EVM and a suitable IDE
• Code snapshots illustrated here are adopted from sample projects
packaged along with Simplicity Studio IDE by Silicon Labs
• Official Documentation from ARM®, Silicon Labs will override information
provided here. Treat official TRM’s as complete guides on Subject Matter
• ARM® Cortex™ M trademark - ARM Ltd
• EFM®32, Silicon Labs SDK etc are registered trademarks
!3
5. What happens on a RESET ?
• Power on
• MCU brought out of reset
• ISR vector table placed @ 0x00
• MCU Core registers
• MSP loaded with address from 0x00
• PC loaded with reset_handler address from 0x04
• reset_handler
• Call SystemInit()
• Copy code from flash to RAM (EFM®32)
• Jump to __start / _mainCRTStartup for handling C runtime initialization
• Once CRT is setup, Jump to main(), application code entry point
!5
6. User ApplicationCRTCMSIS
Typical ARM® Cortex M Boot up Sequence
!6
• Typical boot up sequence pans across 3 stages
• CMSIS Start up code
• CRT Setup
• User application code (Uses Various CMSIS Interfaces to access MCU functionalities)
Reset_Handler
_start!
_mainCRTStartup!
main()!
SystemInit()
Copy Code from Flash to
RAM
exit!
(no return)
8. EFM® 32 ARM® Cortex M0+ Starter Kit
!8
• Zero Gecko MCU from Silicon Labs, based on 32 Bit ARM® Cortex M0+
Architecture
• 32KB Flash - On chip
• 4KB RAM - On Chip
• On Board J-Link JTAG emulator
• Supports USB debugging and downloads to on chip flash
• Supports ARM® Standard 20 PIN DEBUG header which can be
configured in 3 different ways (IN/OUT/MCU)
• AEM (Advanced Energy monitoring) for precise voltage and current
consumption
• Support several on chip peripherals and low energy (energy efficient)
interfaces
9. Simplicity Studio IDE
!9
• Free IDE from Silicon Labs
• Comes loaded with a variety of tools for Cortex M (Not Limited to)
based MCU implementation from Silicon Labs
• Build and Binary file generation using GNU ARM toolchain
• Download binaries to flash using J-Link debugger (On Board in
this case)
• Debug Support (Core Register Watch, Breakpoints, single
stepping etc)
• Device Energy monitoring
• Refer to official documentation from Silicon Labs for complete
info
10. Sample Project in Simplicity Studio & Folder Structure
• EFM® 32 specific port of both
• startup_<device>.s > startup_gcc_efm32zg.s
• system_<device>.c > system_efm32zg.c
• Driver implementation
• Display and logic for retargeting IO (Redirect prinf() to Display)
• Capacitive touch & Utilities required
• EFM® 32 On Chip controllers & Peripherals
• Clock Management Unit (CMU),ADC,RTC,USART
• GPIO Configuration
• Build Artifacts folders for active build configuration
• Linker definition (*.ld)
• map file, hex and binaries
• Application Logic & Implementation
• main() entry point
• Invokes calls to CHIP_init() and other CMSIS interfaces as required
!10
11. Linker Description - 1 (STK3200_touch.ld)
!11
/* Linker script for Silicon Labs EFM32ZG devices */
/* */
/* This file is subject to the license terms as defined in ARM's */
/* CMSIS END USER LICENSE AGREEMENT.pdf, governing the use of */
/* Example Code. */
/* */
/* Silicon Laboratories, Inc. 2014 */
MEMORY
{
FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 32768
RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 4096
}
!
ENTRY(Reset_Handler)
!SECTIONS
{
.text :
{
KEEP(*(.isr_vector))
*(.text*)
! KEEP(*(.init))
KEEP(*(.fini))
! /* .ctors */
*crtbegin.o(.ctors)
*crtbegin?.o(.ctors)
*(EXCLUDE_FILE(*crtend?.o *crtend.o) .ctors)
*(SORT(.ctors.*))
*(.ctors)
! /* .dtors */
*crtbegin.o(.dtors)
*crtbegin?.o(.dtors)
*(EXCLUDE_FILE(*crtend?.o *crtend.o) .dtors)
*(SORT(.dtors.*))
*(.dtors)
! *(.rodata*)
! KEEP(*(.eh_frame*))
} > FLASH
• Defines Origin (Start Address and length)
for both FLASH & RAM
• Defines FLASH packaging
• isr_vector symbol is at the start
• KEEP directive ensures the specific
section is placed and will not be
removed even if there is no reference
• E N T RY ( R e s e t _ H a n d l e r ) d e fi n e s
reset_handler as entry point in the
image
13. Linker Description - 3 (STK3200_touch.ld)
!13
.heap :
{
__end__ = .;
end = __end__;
_end = __end__;
*(.heap*)
__HeapLimit = .;
} > RAM
!
/* .stack_dummy section doesn't contains any symbols. It is only
* used for linker to calculate size of stack sections, and assign
* values to stack symbols later */
.stack_dummy :
{
*(.stack)
} > RAM
!
/* Set stack top to end of RAM, and stack limit move down by
* size of stack_dummy section */
__StackTop = ORIGIN(RAM) + LENGTH(RAM);
__StackLimit = __StackTop - SIZEOF(.stack_dummy);
PROVIDE(__stack = __StackTop);
!
/* Check if data + heap + stack exceeds RAM limit */
ASSERT(__StackLimit >= __HeapLimit, "region RAM overflowed with stack")
!
/* Check if FLASH usage exceeds FLASH size */
ASSERT( LENGTH(FLASH) >= (__etext + SIZEOF(.data)), "FLASH memory overflowed !")
}
Defines RAM sections
STACK definition.
Remember STACK grows down!!
ASSERTION’s to ensure there is no overflow
while adding sections to both FLASH & RAM
At the time of linking and image generation
in case if the size of sections to be placed
either in RAM or FLASH exceeds the size of
RAM or FLASH, then it gets asserted by
Linker
14. EFM®32 CMSIS Start-Up Code - 1
!14
Vector Table definition!
which is placed !
@ address starting !
from 0x00!
Refer pervious slides!
on Linker description
CMSIS Core files !
implementation.!
Based on standard!
Templates!
startup_<device>.s!
system_<device>.c
startup_gcc_efm32zg.s!
basically implements!
vector table , reset handler!
which in turn does !
systeminit
15. EFM®32 CMSIS Start-Up Code - 2
!15
SystemInit - Can be used to initialize
any specific system initialization as
soon as reset handler starts execution
This section performs FLASH to RAM
copy. __data_start__ & __data_end__
are defined in linker definition.Refer to
previous slides on LD
Once copy is done (FLASH>RAM) ,
jump to CRT entry point _start which in
turn will setup application stack, heap,
etc and then call applications main()
entry point
Remember sequence of steps when
MCU comes out of RESET
Load MSP with address in 0x00!
PC starts execution from address
placed in 0x04 (reset_handler) !
(Refer linker description file)
Reset_Handler starts execution
16. EFM®32 CMSIS System Configuration Code
!16
system_efm32zg.c implements!
CMSIS interfaces for majority !
clock configuration. As we had!
seen in the previous slide!
SystemInit(void) gets called from!
Reset_handler!
!
!
Interfaces defined here deal !
with a variety of other clock !
related functionality which can be !
invoked after entering main() also in!
a bare metal scenario when there is no!
embedded OS involved
17. EFM®32 Application Entry Point
!17
main() - Typical C Application entry
which implements application logic
CHIP_Init() performs any additional
MCU specific initialization!
!
DISPLAY_Init(), RETARGET_(),
CAPSENSE_Init() etc implement various
driver level interfaces which in turn call
CMSIS interfaces as required
18. Setting Breakpoints and Inspecting Entry Points - 1
!18
• Connect EFM® 32 kit to IDE!
• We can set PC = 0x0!
• In the Debug window, we can see that
0x0 is mapped to __isr_vector() just
as expected!
• So address 0x04 contains the actual
a d d r e s s o f r e s e t h a n d l e r
implementation!
• Remember, __isr_vector holds
addresses and not actual function
implementation
19. Setting Breakpoints and Inspecting Entry Points - 2
!19
• S e t a b r e a k p o i n t i n
Reset_Handler!
• Inspect PC and we can see
that PC = 0x2E50 and not
0x04!
• T h e a b o v e c o n fi r m s
__isr_vector contains
address and not actual
implementation!
• We can also confirm this /
c r o s s c h e c k w i t h
STK3200_touch.map file
generated