Towards target-level testing and debugging tools for embedded software

There are currently huge costs associated with the validation of embedded applications. This paper first presents a discussion of embedded testing research andpractice. Execution visibility and control must come om the underlying system, which should ofJer interjbces to testing and debugging tools in the same numner it offers them to a compiler. Finally we propose txtenswns to the underlying system, which consists of adiiitions to both the architecture and run-time system that will help reulize target-level tools.

Introduction Software validation involves many activities that take. Continue with Facebook. Sign up with Google. Log in with Microsoft. Bookmark this article. You can see your Bookmarks on your DeepDyve Library. Sign Up Log In. Copy and paste the desired citation format or use the link below to download a file formatted for EndNote.

All DeepDyve websites use cookies to improve your online experience. They were placed on your computer when you launched this website. AB - The current process for testing and debugging embedded software is ineffective at revealing errors.

Harry Koehnemann, Timothy Lindquist. Overview Fingerprint. Abstract The current process for testing and debugging embedded software is ineffective at revealing errors. Access to Document Link to publication in Scopus. Fingerprint Dive into the research topics of 'Towards target-level testing and debugging tools for embedded software'.

Together they form a unique fingerprint. This is the first step away from software-only simulation, allowing a certain amount of hardware debug. This approach is taken by integrating the capability of a simulator with a communication module that acts as the target processor. Stimulus is provided to the simulation directly from the processor's digital input pins, which allows the simulator to set binary values on the output pins.

However, such tools run at the speed of a simulator, so they can't set and clear output pins fast enough to implement timing-critical features like a software UART. In-circuit simulators provide a communication channel between the host development system and the hardware, with something like a UART in the hardware to provide the communication.

The host can then issue commands to the processor to get it to perform debug functions such as setting or reading memory contents. Some code execution control is also possible. This multiplexed execution of code under development and communication of debug information with a cross-development host is usually referred to as a run-time monitor. Software breakpoints can be built in at compile time.

Other features, such as hooking into a periodic timer interrupt to copy data of interest from the target to the host, can also be included when building the executable. Since these techniques don't require writing to program memory at run time, they can be used with burn-and-learn debug using one-time-programmable devices. The routines required to transfer debug data to the host or to download a new executable—the monitor code itself—occupy a certain amount of program memory on the target device.

They also use data memory and bandwidth in addition to the UART or other communication device. However, most of this overhead occurs when code execution is not in progress.

Use of a software run-time monitor is a great step forward from simulation in isolation from the target hardware. Adding just a few simple support features in the silicon of the target processor can turn the monitor into a system that provides all the basic features of an emulator. The system becomes more than a software monitor when custom silicon features are added to the target processor.

In the past, some systems have used external RAM program memory to support this feature. Now reprogrammable flash memory has made in-circuit debuggers ICDs practical for single-chip embedded microcontrollers. The designer can develop and debug source code by watching variables, single-stepping, and setting breakpoints.

Running the device at full speed enables testing hardware in real time. Male and pin DIP headers are provided to plug into a target circuit board.

The demo board provides and pin DIP sockets that will accept either a microcontroller device or the ICD header. Immediate prototype development and evaluation are feasible even if hardware isn't yet available. The complete hardware development system, along with the host software, provides a powerful run-time development tool at a very reasonable price. The debug kernel is downloaded along with the target firmware via the ICSP interface.

A nonmaskable interrupt vectors execution to the kernel under three conditions: when the program counter equals a preselected hardware breakpoint address, after a single step, or when a halt command is received from MPLAB. As with all interrupts, this pushes the return address onto the stack.

On reset, the breakpoint register is set equal to the reset vector, so the kernel is entered immediately when the device comes out of any reset. The ICD module issues a reset to the target microcontroller immediately after a download.