Learn more on advanced debugging of ARM Cortex devices, including how to analyse crashed system after a hard fault exception, SWV real-time event and data tracing, analysing execution history using ETM instruction tracing, dual-core debugging, kernel aware RTOS debugging, and more. Also, learn how to introducing bugs in the first place with static source code analysis (such as MISRA-C), code complexity analysis, and source code review meetings (peer review)

1. Advanced debugging on ARM Cortex
devices like STM32, Kinetis, LPC, etc.

2. Agenda
• Advanced debugging
• How to analyze a crashed system
• System analysis with SVW real-time event- and data tracing
• Recording execution history with ETM instruction tracing
• How to debug a dual-core system
• Debugging RTOS-based applications
• Alternative approach: Avoid introducing bugs
• Coding standards
• Code complexity management
• Peer reviews

3. How to analyze a crashed
ARM Cortex system
Understanding system crashes caused by ARM Cortex hard fault
exceptions, for example due to division by zero, pointer errors, illegal
addresses, illegal instructions or other problems.

4. Cortex-M hard fault categories
• Bus faults
• Access to invalid memory regions
• Byte access to “word only” registers
• Memory management faults
• Access that violate the MPU setup
• Execute code from non-executable memory regions
• Usage faults
• Undefined instructions
• Unaligned memory access
• Divide by zero
• Accidentally switch to ARM mode (if CPU is thumb only!)
• Hard faults
• Caused by bus, memory management and usage faults if their
respective handler is not enabled

5. 1. Enable interrupt handlers
• Bus, memory management and usage
faults needs to be enabled.
• Otherwise they are escalated into a
hard fault.
• Enabled in the System Handler
Control and State Register

6. 2. Fault reason display
Memory management fault status
register
Bus fault status register
Usage fault status register
For example, division by
zero is flagged in this bit

7. 3. Analyzing hard fault location
• Halt in fault handler
• Find fault type in SFR-Viewer
• Locate stacked PC using SP +24
• Locate the code
SP+24

8. The Cortex-M hard fault analyzer
A tool automated solution
– The Atollic TrueSTUDIO debugger can show where and why the CPU crashed automatically
– No need to manually perform the steps described on previous pages
– MUCH more convenient than the manual approach

9. System analyzis and real/time
event and data tracing
Understand how Serial Wire Viewer (SWV/SWO/ITM) can be used to
analyze system behavior

10. Serial wire viewer real-time tracing
• Not always feasible to stop the CPU to examine the state of the
application (using breakpoints) due to timing issues (e.g. motor control).
• Tracing is about getting information out of the chip without halting the
CPU.
• Application and timing logic will be preserved but still possible to examine
what is happening.
• SWV provides low-cost but yet powerful event and data tracing in ARM
Cortex processors.
• SWV is part of the ARM CoreSight debugger architecture, and uses the 1-
pin SWO pin to transfer data from CPU to debugger. ITM also uses the
SWO pin for S/W trace.

11. Debugger capabilities enabled by
SWV/SWO/ITM
• Event trace (log and timeline graph)
• Exception trace (log and timeline graph)
• Data trace and memory access history (log and timeline graph)
• Interrupt statistics graph
• Statistical profiling graph
• Execution time measurement
• printf() output re-directed into debugger console

12. printf() redirection using ITM
• Re-direct printf() output to the IDE
• printf() redirection implemented with a simple
C macro using ITM interface on JTAG cable
• 32 available ITM ports (consoles/channels)
• Different software routines can print to
different ports. For example:
• Application prints to channel 0
• RTOS prints to channel 1
• TCP/IP stack prints to channel 2
• Benefits:
• No need for USB / RS232 or external display
• Up to 32 independent output channels
• ITM can also be used for other tasks, i.e.
generic software instrumented trace

13. printf() redirection using ITM
1. Redirect low level output stub used by
printf (syscalls.c in TrueSTUDIO) to ITM
channel 0 (CMSIS standardized macro)
4. The text printed to the ITM channel 0 is
intercepted by the debugger and printed
in the SWV Console View
2. Enable ITM port 0 in the SWV
configuration GUI
3. Generate some printf output

14. Measure exec time of code blocks
• Measure the execution time of code blocks by sending time-stamped
bytes over the ITM-channel
– Requires target instrumentation
– Implemented with simple C macro
– Sending 1 byte over ITM = 1 CPU cycle
– Time measured by comparing time stamps
in ITM trace log
• Benefits:
– Measure execution time of code
blocks not equal to one C-function
• Parts of a function
• Parts of a system
with many functions

15. Speed optimization with statistical
profiling
• Non-intrusive PC sampling during system
execution
• See how much execution time is spent in
each function
• Based on periodic sampling so not 100%
accurate, but becomes more and more
reliable as execution time increase.
• Benefits:
• Analyze where most execution time is
spent
• Prioritize optimization efforts
• Done without speed penalty (maintains
full real-time behavior since no
instrumentation).

16. Exception & Interrupt tracing
See how interrupts occur in real-time in
your application
• What exception source/peripheral?
• What interrupt handler?
• Time spent in interrupt?
• Any interrupt nesting?
• When do interrupts occur?
Understand interrupt handler performance
• How much execution time is
spent in each interrupt handler?
• Shortest/Average/Longest
runtime?

17. Real-time data monitoring
• Real-time watch of mem./vars. while target is running
at full speed
• See memory/variable value in real-time
• See the complete memory access history
• Double-click on a memory access -> open
code line that made specific memory access
• Real-time data graph
makes it easy to
understand variable
values
• Zoom in / out
• Take screenshots
• Toggle between cycles/time
• Broken patterns found easily

18. Record execution flow using
ETM/ETB instruction tracing
Inspect recorded data to understand what the CPU was doing before a bug
leads to a crash
(Not available in all Cortex devices)

19. ETM trace (record data)
• Instruction tracing collects an enormous amount of data (1s exec time on
Cortex-M4 is ~100MB binary packed, or 5-10GB human readable).
• Trace Triggers are used to start/stop tracing in order to reduce the massive
amount of data collected
• Event triggered start/stop (on PC or memory access)
• “Breakpoint” triggered start/stop

20. ETM trace (analyse data)
Show the recorded execution history on different abstraction
(“zoom”) levels:
• Function trace
• C trace
• Mixed C/Asm trace
• Asm trace

21. How to debug dual-core
processors
(using a Freescale Vybrid Cortex A5/M4
as an example)

22. Special dual-core considerations
• Symmetric dual-core
• Cores of identical type (for example two ARM Cortex A9’s)
• Often used for load balancing of tasks/threads using an O/S. In
such case debugger must have O/S specific dual-core features.
• More often used in “mobile devices” (smartphones/tablets)
• Asymmetric dual-core
• Cores of different type (for example one A5 + one M4)
• The cores run largely independently, even using different
(or no) O/S.
• More often used in “traditional embedded systems”
• “New problems”
• Debugging two cores from the same debugger GUI at the same time
• In Eclipse-based IDE’s:
• A mouse-click swaps between A5 or M4 context.
• Views can be “pinned” to stay visible in “wrong” context
• One JTAG-probe in daisy-chaining mode is sufficient to debug both
cores simultaneously
• Core synchronisation and communication – shared memory, serial
interfaces etc

23. How to debug a dual-core system
• In Eclipse-based IDE’s:
• A mouse-click in the call stack (Debug view) will swap CPU
context
• Debugger views from a CPU context can be pinned (stay in
visible in other CPU’s context) – e.g. to compare
SFR/memory data
• For Freescale Vybrid:
• First boot the A5 and
let it enable the M4
• Then boot the M4
• Once booth are
booted, they execute
independently but
share memory and
peripherals

24. Debug RTOS-based applications

25. Kernel aware debugging
• An RTOS have internal object states you need to study during
debugging
• Tasks, semaphores, mailboxes, timers, etc.
• You need to peek into the RTOS and see how kernel objects
changes when debugging the system
• Your debugger needs to have RTOS views for the kernel objects
in your RTOS

26. An alternative approach:
Avoid introducing bugs
in the first place

27. Reduce bugs by writing better code
Check code for MISRA-C compliance
Reduce the number of bugs by following a best-practice
coding standard developed by industry experts.
Measure and manage code complexity
Measure cyclomatic value of code complexity, and refactor (simplify)
complex functions.
Benefits:
• Complexity level –> Where to rewrite & refactor?
• Low complexity –> Low probability of errors
• Low complexity –> Low cost for maintenance
• Low complexity –> Easy to test

28. Reduce bugs with peer reviews
Source code reviews
Colleagues study each other’s code, trying to find problems and
suggest improvements.
Typically a 3-phase process:
• Individual review phase – study the code
• Team discussion phase – code review meeting
• Individual rework phase – fix problems assigned to me

29. Learn more on ARM Cortex
development and debugging!
ARM development and debugging white paper
More white papers on ARM cortex development
Learn more on ARM Cortex development tools
www.atollic.com
Click to read more:

30. More information:
www.atollic.com
EUROPE & WORLDWIDE
Atollic AB
Science Park
Gjuterigatan 7
SE-553 18 Jönköping
Sweden
+46 36 19 60 50
info@atollic.com
USA & AMERICAS
Atollic Inc
241 Boston Post Road West
1st Floor
Marlborough
Massachusetts 01752
+1 (973) 784-0047
sales.usa@atollic.com
2013.09.23.