1. ARM Intro –
Uncovering the mystery
Roy Messinger©
www.HWDebugger.com

2. © Roy Messinger
www.hwdebugger.com
 ARM Controller
ARM Overview
ARM Cortex Family
ARM in design Projects
Getting down to the bits & bytes.
Use case: bootloader & remote update with NXP Kinetis
Note: A great entry course for ARM is here: https://bit.ly/2Ke5K7B

3. © Roy Messinger
www.hwdebugger.com
What are embedded systems?
 As its name suggests, Embedded means something that is
attached to another thing.
 Computer hardware system having software embedded in it.
 An embedded system is a microcontroller or microprocessor
based system which is designed to perform a specific task
(fire alarm).

4. What is ARM?
ARM = Advanced RISC Machines.
RISC = Reduced Instruction Set Computer (compared to CISC as x86). A computer based on a
processor or processors designed to perform a limited set of operations extremely quickly
 ARM is a CPU architecture (Address bus is 32bit wide, like Intel x86) designed by a UK
based company.
 The company itself does not make chips, it licenses its designs to chip makers → very low
price. Just like Android OS.
 Low power consumption (compared to Intel processors, for example)

5. © Roy Messinger
www.hwdebugger.com
ARM Overview
4 main development
fields:

6. © Roy Messinger
www.hwdebugger.com
ARM Overview
The 5 key markets are:

7. © Roy Messinger
www.hwdebugger.com
ARM Overview
 Used in most of the mobile phone industry (IPhone,
IPad, Kindle, Android phones).
 Design using C/C++ language.
 At least 90 processors are shipped every second.
ARM based
SD
Controller
NAND Flash

8. © Roy Messinger
www.hwdebugger.com
ARM Cortex-M Overview
 Cortex-M has separate data and instruction/control buses,
hence it is a Harvard architecture (compared to Von
Neumann architecture).
 In a Von Neumann the data (RAM) and instruction (ROM) buses
are the same. So it takes two sequential fetches (command
and then data) to do most operations.
 In Harvard architecture data and instruction buses are
physically separate memory areas.
 ARM cores uses the Modified Harvard Architecture. The data
and instruction buses are separate (Harvard), but they use a
single memory space (Von Neumann).

9. © Roy Messinger
www.hwdebugger.com
ARM Cortex-M Overview
 All instructions are 32-bits long, compared to older 8 bit data MCU’s.
 ARM is a load / store architecture
 via registers => RISC
 Load or store multiple registers in a single instruction. You must load
values into registers in order to operate upon them.
 No instructions directly operate on values in memory.

10. © Roy Messinger
www.hwdebugger.com
ARM Cortex M0 Computation Performance

11. © Roy Messinger
www.hwdebugger.com
Under The Hood

12. © Roy Messinger
www.hwdebugger.com
ARM CPU Instruction Set registers
Taken from
http://infocenter.arm.com
All the core registers are 32bit wide.
R13(SP) used to track stack memory.
R14(LR) stores the return
information for subroutines, function
calls, and exceptions
R15(PC) contains the current
program address (the current
instruction to be executed).

13. © Roy Messinger
www.hwdebugger.com
ARM Cortex-M Instruction Set Architecture

14. © Roy Messinger
www.hwdebugger.com
ARM Cortex M4 Instruction set

15. © Roy Messinger
www.hwdebugger.com
MicroProcessor Vs. MicroController
 MicroProcessor: IC which has only the CPU inside (like Intel CPU’s). An
implementation of CPU.
 MicroController: CPU + RAM + other peripherals. Relationship of input
and output is defined, and specific task is executed: Keyboard, mouse,
etc.
 So, is ARM a MicroController or a MicroProcessor?
Neither. ARM is a CPU architecture.

16. © Roy Messinger
www.hwdebugger.com
Real time Vs. Bare metal
 These are 2 methods for working in Embedded systems.
 Bare metal means running software directly on hardware whereas RTOS
means running the app on top of an operating system.
 A real time system deals with guarantees, not with promise. Like an air
bag in a car.
 Sometimes RTOS is an overkill; Too much hassle for low demand system.

17. © Roy Messinger
www.hwdebugger.com
Real time Vs. Bare metal

18. © Roy Messinger
www.hwdebugger.com
Embedded Software
There are various embedded design softwares. I’ll name a few:
 KDS – Kinetis Design Studio, by NXP semiconductors. It’s a free
distributed software (using Eclipse IDE).
 IAR Systems
 KEIL

19. © Roy Messinger
www.hwdebugger.com
Interesting insights

20. © Roy Messinger
www.hwdebugger.com
special / Interesting insights – Endless loop
Endless loop inside Main function
 Using endless loop the application never stop
running!
 Using: for(;;) or while(1)
 If no while/for loop exists – system would
have crashed (BSOD).
Hard Fault handler

21. © Roy Messinger
www.hwdebugger.com
special / Interesting insights - Volatile
 Volatile keyword: “An object that has volatile-qualified type may be
modified in ways unknown to the implementation or have other unknown
side effects.”
 Code that works fine-until you turn optimization on – Weird…
 Code that works fine-as long as interrupts are disabled – Weird…
It changes due to compiler optimizations.
Ok, then let’s turn off the optimizations! -- not recommended.
volatile variable –> don’t do complier optimization for that variable!
uint32 status = 0;
while (status == 0)
{
/*Let us assume that status isn't being changed
in this while loop or may be in our whole program*/
/*So long as status (which could be reflecting
status of some IO port) is ZERO, do something*/
}
Compiler ‘thinks’:
• status isn’t been changed by while loop →
• no need to access status variable (loop) →
• Compiler converts this loop to while(1) →
• machine code to read status isn’t needed.

22. © Roy Messinger
www.hwdebugger.com
special / Interesting insights – C Vs. C++
 In the past, code was written fully in assembly language. Not friendly,
complicated.
 Later on ,moving to C language. This is the familiar ‘Embedded’ language.
 There are various opinions regarding developing in C++ or C in Embedded systems.
 Traditionally, the C language is being used. Nevertheless, C++ and other object
oriented languages are slowly entering the real-time systems (C# also).
 A lot of myths exist regarding the use of C++ in embedded systems

23. © Roy Messinger
www.hwdebugger.com
 It is a technique for implementing instruction-level parallelism within a
single processor.
 It allows faster CPU throughput at a given clock rate, but may
increase latency.
 Older CPU’s used N-stage pipeline (N=3/4/5 in older MCU’s/architectures)
special / Interesting insights – Instruction pipeline
A 3-stage dynamic pipeline:

24. © Roy Messinger
www.hwdebugger.com
special / Interesting insights – NOP command
 Using assembler instruction within C/C++ code:
 For example, using NOP:
enables the user to add delay (instruction cycle), or debug breakpoints
in the code.
 This was true back in the old days (if CPU clock was 90MHz, and
instruction cycle is 3 stage pipeline, NOP is 33nS delay).
 In ARM it’s not straight forward, and it’s better using a dedicated delay
function (given by manufacturer).
__asm{
..
}

25. © Roy Messinger
www.hwdebugger.com
CMSIS Library

26. © Roy Messinger
www.hwdebugger.com
CMSIS library
 Cortex Microcontroller System Interface Standard.
 It provides a common approach to interface to peripherals, real-time
operating systems, and middleware components.
 It is a group of files with functions & defines for making programming in
Cortex M family uniform.
 If one can program in one Cortex, one should be able to migrate to
different Cortex MCU independent of the compiler & manufacture.

27. © Roy Messinger
www.hwdebugger.com
CMSIS library
BT, UART, etc.
interface to the
cortex CPU
Clocks, interrupts

28. © Roy Messinger
www.hwdebugger.com
CMSIS Peripheral Access Layer
 In the startup folder, there are various files.
 The .S file is the assembly CMSIS file.
 Other 2 files are NXP files based on .S CMSIS file.
• Inside CMSIS folder there’s a MK64F12.h header
file.
• It is a header file which contains above 10,000
lines and holds the CMSIS core_cm4.h file and
the system_{cpu}.h file definitions.
• It is a specific file which helps the user set the
various registers of the CPU.

29. © Roy Messinger
www.hwdebugger.com
CMSIS Peripheral Access Layer - example
 For example, the user wants to set a bit in a register
named MODEM.
 The ‘ugly’ way would be to write the wanted value to
the exact address (“0x4006B000”).
 A much nicer and friendly way would be to use the CPU
h file (MK64F12.h) and use the various address
definitions for the various registers.

30. © Roy Messinger
www.hwdebugger.com
CMSIS Peripheral Access Layer - example
 In main code the user want to set a bit in MODEM register:
Peripheral UART1
base pointer
(0x4006B000)
UART Modem
Register, offset:
0xD

31. © Roy Messinger
www.hwdebugger.com
KDS SDK – Kinetis Design Studio SW Development Kit
 Software Development Kit that provides comprehensive software
support for Kinetis devices.
 The KSDK includes a Hardware Abstraction Layer (HAL) for each
peripheral .
 Example applications are provided to demonstrate driver and HAL
usage.
 These are very useful source files for 1st timers and great entry point.
 There are 2 releases of KSDK: v2.0 and v1.2.

32. © Roy Messinger
www.hwdebugger.com
Development process

33. © Roy Messinger
www.hwdebugger.com
An ARM Microcontroller example
 For the course example I’ve chosen ARM uController by NXP (K64
family). MK64FN1M0VLL12.
 It is an ARM Cortex-M4 (newest Cortex M series. Cost sensitive, interrupt
driven environment).
 It has 120MHz CPU frequency, 1MB internal flash, 256KB RAM (SRAM).
 It has A/D converters (16bit accuracy), D/A converter, DMA support,
USB, Ethernet, UART, dozens of I/O’s.
 The IDE chosen is the free Eclipse based KDS (GCC compiler)

34. © Roy Messinger
www.hwdebugger.com
Kinetis K64 MCU Family Block Diagram
 K64f MCU has various
registers to control its
functionality.
 That is aside the ARM
Cortex M core
registers.
 K64 has a detailed
manual for all registers
used and their
functionality.

35. © Roy Messinger
www.hwdebugger.com
Kinetis K64 Reference Manual

36. © Roy Messinger
www.hwdebugger.com
ARM GNU Toolchain & Linker
 In computing, a linker or link editor is a computer utility program that takes
one or more object files generated by a compiler and combines them into a
single executable file, library file, or another 'object' file.
 In Embedded, using the Unix based ARM GNU toolchain, the linker (ld)
creates an ELF or BIN file.

37. © Roy Messinger
www.hwdebugger.com
ARM GNU Toolchain
 KDS uses Arm Embedded GNU toolchain for Arm Cortex-M (can be installed
separately).
 Using the arm-none-eabi-gcc command the compiler is invoked:
eabi = Embedded Application Binary Interface (outputs the object (.o)
files).
 Linker: GNU ld runs the linker, which creates a bin file.
 A linker script may be passed to GNU ld to exercise greater control over
the linking process.
 The linker script is ARM chip dependent.

38. © Roy Messinger
www.hwdebugger.com
KDS – Kinetis Design Studio

39. © Roy Messinger
www.hwdebugger.com
 When linker assembles all object
files it does not know where to
place code & data.
 The linker file instructs the
linker the initial address of which
the flash memory starts.
 The memory segment is used to
divide the memory into
segments.
 We can direct the linker to place
specific output sections into that
memory region (using `>region' )
Linker ld file

40. © Roy Messinger
www.hwdebugger.com
Linker ld file
• The m_text section holds the source code and constant data, as is
(pure text). It is the ROM section.
• The K64 MCU has a total of 256KB SRAM, divided into 2 regions
(upper & lower). These are the RAM section.
• Lower (m_data for CODE bus) is 64KB size Upper (m_data_2 for
SYSTEM bus) is 192KB size.
• ld by default place everything in m_data section.
In KB
• We can place sections in ROM, RAM or
external RAM.

41. © Roy Messinger
www.hwdebugger.com
Flashing ARM CPU
 There are various companies to choose
from:
 Segger and P&E Micro are the famous
ones.
 FRDM K64 board has an embedded flasher
component and flashing is conducted via
USB cable.

42. © Roy Messinger
www.hwdebugger.com
Semi-Hosting
 SemiHosting is a mechanism that enables code running on an ARM target
to communicate and use the IO facilities on a host computer that is
running a debugger.
 One can use this mechanism to enable functions in the C library, such as
printf() and scanf(), to use the screen and keyboard of the host.
 Very useful tool which is supported by all ARM architectures.

43. © Roy Messinger
www.hwdebugger.com
‘text’ Vs. ‘data’ Vs. ‘bss’
 After compilation, the KDS (and any other compiler for that matter) shows the following:
• ‘text’ : is my code, vector table plus constants.
It what ends up in FLASH memory:
const int table[] = {5,0,1,5,6,7,9,10};
• ‘data’ : is used for initialized data:
After adding this, ‘data’ portion will increase by 4.
• myVar is not constant, so it will end up in RAM, But the
initialization is constant and will live in FLASH.
int32_t myVar = 0x12345678;
• ‘bss’ : contains all the uninitalized data:
• myGlobal is un-init, so ‘bss’ portion will increase by 4.
• ‘bss’ is saved in RAM. bss = “Better Save Space”
int32_t myGlobal;
Total file size = text + data + b
ROM ROM,
RAM
RAM

44. © Roy Messinger
www.hwdebugger.com
Defining I/O’s
 Before start writing the code we need to define the various
I/O’s.
 The user can do it by writing the code from scratch, or using
NXP GUI, KEx Tools.
 This is a graphic tool which converts the user I/O’s
constraints into a source code (pin_mux.c & pin_mux.h files).

45. © Roy Messinger
www.hwdebugger.com
KEx Tools v2.0 - Defining I/O’s

46. © Roy Messinger
www.hwdebugger.com
KEx Tools v2.0 – clock configuration
 K64 can be configured
to work with internal
clock and external
clock.
 The internal reference
clocks are 4 MHz IRC
(the "fast" one), or the
32 kHz IRC (the "slow"
one)
 With Kex Tool the user
can define the various
clocks inside the CPU.
 This GUI is exported to
clock_config.c &
clock_config.h files.

47. © Roy Messinger
www.hwdebugger.com
Use Case:
Remote Update and Bootloader
with NXP Kinetis

48. © Roy Messinger
www.hwdebugger.com
What is a bootloader?
 The bootloader is a program that starts whenever a device is powered
on to activate the right operating system.
 It is a piece of code that runs before any operating system is running.
 Since it is usually the first software to run after power-up or reset, it is
highly processor and board specific.

49. © Roy Messinger
www.hwdebugger.com
KBOOT
 The basic remote update feature of NXP is called: KBOOT.
 KBOOT is the standard bootloader for all Kinetis devices.
 It enables quick and easy programming and updating applications in the
field with confidence.
 The source code is given as is in full, and as such, can be configured.

50. © Roy Messinger
www.hwdebugger.com
KBOOT Flow Chart
 The KBOOT source files implement the
following flow chart.
 It is totally configurable.
 Application can run without KBOOT,
obviously, but the downside is the lack of
remote update (upgrade in the field).
 In a regular flow, after 5 seconds the
KBOOT jumps to application if valid &
exist at address 0xa000 at flash.
Yes
No

51. © Roy Messinger
www.hwdebugger.com
KBOOT Bootloader variations
 Kinetis Bootloader can reside in ROM, RAM (FlashLoader) and
flash (flash-resident).
 There are various types of Bootloaders which the user can
choose from:
 Kinetis FlashLoader: a one time bootloader. After you update the application
code, the bootloader will disappear. It is a flash-resident bootloader used for
field updates.
 ROM-based bootloader: reusable bootloader. Always in the flash after
uploading application code.

52. © Roy Messinger
www.hwdebugger.com
Freedom Bootloader
One time
bootloade
r Always in
the flash
• For Remote Update functionality this
is the correct source code to choose.
• The source code must be adapted to your custom board (pinout & clock), as it’s
defined for FRDM-K64 board.
• freedom_loader will stay in flash address 0x00, the application code is defined from
0xa000.
• Linker file should be changed, so app code shall run from 0xa000.

53. © Roy Messinger
www.hwdebugger.com
Remote Update Flow Chart
 For regular flow, the KBOOT
jumps to application and stays
there.
 2 versions should exist:
Bootloader version & Application
version.
 For updating the application, the
user must jump to bootloader,
stay there, and update the
application area in the flash
(address 0xa000).
 Windows application used for
flashing is called: blhost and is
given in full (sources includes).

54. © Roy Messinger
www.hwdebugger.com
Remote Update
 The interrupt vector table is placed at the start of
Flash memory (address 0x0) followed by the
application code.
 The BL config are contains specific info regarding the
behavior of the BL.
 The address 0xA000 is defined in
bootloader_config.h:
Flash Address Mapping

55. © Roy Messinger
www.hwdebugger.com
Remote Update
 When BL sees valid application in 0xa00 – it jumps
there.
 We need to send application to BL and stay there!
 How? Adding a ‘mailbox’ (flag) in predefined address
in flash, then altering it according to our needs.
Flash Address Mapping
Mailbox: “0xFACA”0x30020

56. © Roy Messinger
www.hwdebugger.com
Remote Update
 Erase the flash → write application → write
0xCAFA to mailbox (flash) → power off.
 From BL code:
 Mailbox is written from Application.
 The user in the application writes to the
mailbox (‘STAY_IN_BL’). This is written to the
RAM, not the FLASH. Why?
 When Mailbox was written to flash – huge bin
file (500MB).
Linker file:

57. © Roy Messinger
www.hwdebugger.com
Where to start from:
Buying the cheap-but-sophisticated FRDM K64F board;
Ali Express FRDM K64 board: bit.ly/2rsrO3U
Getting started guide is here: bit.ly/2Fl2svs
McuOnEclipse guide to FRDM K64F: bit.ly/2HWksk5
Forums and tutor websites:
 https://mcuoneclipse.com/ by Erich Styger
 https://community.nxp.com/community/kinetis
 Great webinars: bit.ly/2KKLOaW
 www.Udemy.com, specifically a great course:
 https://www.udemy.com/embedded-system-
programming-on-arm-cortex-m3m4/
C++ in embedded systems: https://bit.ly/2JZJMT6
Bss vs. Data Vs. Text : https://bit.ly/2rsVa2R
Volatile Keyword: https://ubm.io/2scSBSY
KBOOT Manual: https://bit.ly/2GUCrCa
Relocating code using Linker file: https://bit.ly/2LB5nmu
How to adapt KDS application for KBOOT: https://bit.ly/2INjDKZ
code using Linker file: https://bit.ly/2LB5nmu
LD Linker script syntax tutorial: https://bit.ly/2wnWLvF
How to install KSDK 2.0: https://bit.ly/2seuZND
Getting started with KSDK: https://bit.ly/2GUdKWA
Writing a program with KSDK: https://bit.ly/2IPey4O
Semihosting with Eclipse: https://bit.ly/2kstpn8
Another Semihosting with Eclipse: https://bit.ly/2xmu4zK
Segger Forum: https://bit.ly/2IQzYyw