Advanced debugging on ARM Cortex devices such as STM32, Kinetis, LPC, etc.
3 likes1,814 views
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)
More Related Content
What's hot (20)
Similar to Advanced debugging on ARM Cortex devices such as STM32, Kinetis, LPC, etc. (20)
Recently uploaded (20)
Advanced debugging on ARM Cortex devices such as STM32, Kinetis, LPC, etc.
- 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
- 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.