Towards TargetLevel Testing and Debugging Tools for Embedded Software

1
Towards Target-Level Testing and Debugging Tools
for Embedded Software

• Presenter John Lo
• Date 9/28/06

2
Presentation Outline

• Summary of paper
• Weaknesses of the approach
• Strengths of the approach
• Relevance to embedded software

3
Summary of paper

• Software Testing
• Embedded Testing

4
Software Testing

• Testing Concurrent Systems
• Unmanageable set of legal exec. Sequences
• Subsequent exec. with same input may yield
  different output
• Non-intrusive Testing
• A separate processor executes the testing system
  and communicates with the target

5
Embedded Testing

• Current state of embedded testing
• Software is forced to conform to custom hardware
• Hardware could be problematic
• Fixing errors in (H/S) integration increase cost
• Current solutions - Hardware Solution
• Bus monitor, ROM monitors, and in-circuit
  emulators

6
Embedded Testing Hardware Solution cont.

• Bus monitor
• Gain visibility by observing data and
  instructions trans. Across the system bus
• ROM monitor
• Debugger code placed into the ROM on target board
• Break pt, transfer control to debugging code
• In-circuit emulator
• Connects to host using Ethernet connection
• Simulates the processor

7
Embedded Testing

• Current solutions - Software Solution
• Goal-reduce tremendous costs of testing on the
  target
• Based on several factors including
• level of criticality of software module
• Test platform availability
• Test Classification

8
Weaknesses of the approach

• Hardware Solution
• have minimal effectiveness for software
  development
• Only low level machine data are collected
• Developer needs to create mapping between
  low-level system events and the entities defined
  in the program

9
Problem with embedded Testing

• Late arrival of hardware impacts cost of an error
  since certain errors are only reveled during H/S
  integration testing
• Limited functionality on a target machine and
  does not support tools only machine
  instructions and physical addresses
• Errors revealed late in development lifecycle
• Test selection not based on theoretical test
  criteria

10
Strengths of the approach

• Increasing Target Functionality
• Model Debugging System
• To allow mapping of machine level information to
  source level constructs (e.g. ASIS)
• Illustration of a debugging system

11
Architectural Additions

• Goal-partition hardware design to allow
  architectural parallelism
• Hardware Partitioning of Memory
• Each process have its own protected address space
  no accessible by other processes
• Allow/restrict memory based on criteria

12
Architectural Additions-cont.

• Computational Facilities for Debugger
• Debugger partitioned into an internal debugger
  (run on target) and external debugger (host)
• Debugger runs as a regular process on the
  processor
• Design the whole system take into account this
  process
• Debugger execute the internal debugger code
• allows software to dictate the information sent
  by the processor
• Debugging code loaded into processor at boot
  time, transmitting and receiving messages to and
  from the external debugger

13
Architectural Additions-cont..

• Hardware Break Points
• Problem Software breakpoint require a
  computation every time and halt execution are
  unacceptable for RTS
• The state of the processor consists of all its
  internal registers, including any pipeline info.
  and cache memory must be saved automatically
• Architectural Support for Abstractions
• Goal processor emit fewer, more meaningful
  messages than low-level instructions

14
Architectural Additions-cont

• Dedicated Bus
• Aware of high level program elements
• Allow internal debugger to catch up with the
  current processor state
• Allow bi-directional communication

15
Run-Time System Additions

• Processes
• Changing task state ability not offered by
  embedded debugger
• Developer must be able to view and modify each
  entry queue to determine the concurrent sate of
  the system
• Schedule Control
• Interrupt Management
• Allow developer to bind interrupt handling
  routings to reveal timing errors
• Memory Management
• To allow dynamic memory allocation and management
  to incorporate future systems
• Exception/Fault Handling

16
Relevance to embedded software

• Embedded systems encounters problems during H/S
  integrations and approaches are presented in the
  paper to help deal with the high cost associated
  with target-level testing.

17
Article Reference

• Harry Koehnermann, and Timothy Lindquist Towards
  Target-Level and Debugging Tools for Embedded
  Software. ACM 0-89791-621 -2/93/0009--0288 1.50,
  1993

18
Q A