MOHAMMED ZIA AHMED KHAN

MECH-B 1604-17-736-070

PES - ASSIGNMENT 5

13. Describe the goals of a typical testing process on the host machine and
explain the basic technique for testing embedded software on the
development host system.
A) Goals of a typical testing process are:
• Find bugs early in the development process
• Exercise all of the code
• Develop repeatable, reusable tests
• Leave an audit trail of test results

1. Find the bugs early in the development process:

This saves time and money. Early testing gives an idea of how many bugs you have and
then how much trouble you are in.
But the target system is available early in the process, or the hardware may be buggy
and unstable because hardware engineers are still working on it.

2. Exercise all of the code:

Exercise all exceptional cases, even though, we hope that they will never happen,
exercise them and get to know how it works.
But It is impossible to exercise all the code in the target.
For example, a laser printer may have code to deal with the situation that arises when
the user presses one of the buttons just as a paper jams, but in real-time to test this
case. We have to make paper to jam and then press the button within a millisecond, this
is not very easy to do.

3. Develop reusable, repeatable tests:

It is frustrating to see the bug once but not able to find it. To make it happen again, we
need to repeatable tests.
But it is difficult to create repeatable tests at the target environment.
Example: In a bar code scanner, while scanning it will show the previous scan results
every time, the bug will be difficult to find and fix.

4. Leave an audit trail of test results:

Like telegraph ‘seems to work’ in the network environment as what it sends and
receives is not easy to know, but it is valuable to store what it is sending and receiving.
But it is difficult to keep track of what results we got always because embedded systems
do not have a disk drive.

1
 MOHAMMED ZIA AHMED KHAN
MECH-B 1604-17-736-070

PES - ASSIGNMENT 5

14(a) What are the objections, limitations, and shortcomings of testing

embedded system code on the host system?
A) OBJECTIONS, LIMITATIONS, AND SHORTCOMINGS:
Engineers raise several objections on testing code on the host instead of directly on target.

1. Embedded-system code is very hardware-dependent. At the host side, it interacts only with
the microprocessor and has no direct contact with the hardware.
2. Building a test scaffold more trouble than it is worth.
3. To use this technique, you must have a version of RTOS that runs on your host.
4. Can’t test several important software characteristics on a host like:
a. The software’s interaction with hardware: If software writes data intended for UART
to the wrong address you won’t detect it without the target.
b. Response and throughput: if code run in a different environment (different C
compiler, microprocessor etc.) these parameters will change.
c. Shared-data problem: difficult to detect these on a host.
d. Portability problems: The host and target may have many differences. This can cause
new problems to arise on target.

14(b) What are the capabilities, advantages, and disadvantages of an

Instruction set simulator?
A) An instruction set simulator or simulator is a software tool that runs on your host
and simulates the behavior of the microprocessor and memory in your target system.

The simulator knows the target microprocessor’s architecture and instruction set. As
it reads the instruction that makes up your program from the (simulated) memory, it keeps
track of the values in the (simulated) RAM and in each of the simulated µp registers to mimic
the behavior of the real target hardware.

The user interfaces on most simulators are similar to that of a debugger, allowing
you to run your program, set breakpoints, examine and change data in memory and
registers, single-step through the program, and so on.

Advantages of Simulators
1. Determining response and throughput.
2. Testing assembly-language code.
3. Resolving portability issues.
4. Testing code dealing with peripherals built into the µp.

Disadvantages of simulators
1. Shared data bugs

2
 MOHAMMED ZIA AHMED KHAN
MECH-B 1604-17-736-070

PES - ASSIGNMENT 5
2. Other hardware

15(a) Explain debugging techniques used for designing embedded systems.

A) Embedded systems Debugging is done by:

I. Testing on a host machine

• The hardware and hardware-dependent code have been replaced with test
scaffold software on the right side.
• The scaffold software provides the same entry points as does the hardware-
dependent code on the target system, and it calls the same functions in the
hardware-independent code.
• The scaffold software takes its instructions from the keyboard or a file; it
produces output onto the display or into the log file.
• Conclusion: Using this technique you can design a clean interface between
hardware-independent software and the rest of the code.

II. Using laboratory tools

• Target Hardware Debugging
• Even though the firmware is bug-free and everything is intact in the board, your
embedded product need not function as per the expected behavior in the first
attempt for various hardware-related reasons – like dry soldering of

3
 MOHAMMED ZIA AHMED KHAN
MECH-B 1604-17-736-070

PES - ASSIGNMENT 5
components, missing connections in the PCB, misplaced components, signal
corruption due to noise, etc.
• The only way to sort out these issues and figure out the real problem creator is
debugging the target board.
• The various common hardware laboratory tools used in this debugging process
are:
o Magnifying glass (lens) is a powerful visual inspection tool. The surface
of the target board can be examined thoroughly for dry soldering of
components, missing components, improper placement of components,
improper soldering, track (PCB connection) damage, short of tracks, etc.
o Multimeter – is the primary debugging tool for physical contact based
hardware debugging and almost all developers start debugging the
hardware with it. In embedded hardware debugging, it is mainly used
for checking the circuit continuity between different points on the
board, measuring the supply voltage, checking the signal value, polarity,
etc.
o Digital CRO – is used for waveform capturing and analysis,
measurement of signal strength, etc. By connecting the point under
observation on the target board to the channels of the oscilloscope, the
waveforms can be captured and analyzed for expected behavior. CRO is
a good tool in analyzing interference noise in power. Monitoring the
crystal oscillator signal from the target board is a typical example of the
usage of CRO for waveform capturing and analysis in target board
debugging. Digital CROs are best suited for target board debugging
applications.
o Logic Analyzer – is another tool that captures signals and graphs them
on its screen. They are similar to oscilloscopes, but they differ in several
fundamental ways.
 A logic analyzer can track many signals simultaneously.
 A logic analyzer can track many signals simultaneously.

4
 MOHAMMED ZIA AHMED KHAN
MECH-B 1604-17-736-070

PES - ASSIGNMENT 5

15(b) Explain the operating modes of operation of logic state Analyzer.

A) Logic analyzers can operate in two modes:
• State Mode
• Timing Mode

Logic analyzer in timing mode:

LAs in timing mode can tell you how long things take to occur, show you the signal
patterns, and find out whether certain events occur. Some situations where logical analyzers
are working in Timing mode. If certain events ever occur.

o Example: In bar code scanner software ever turns the radio on, we can
attach a logic analyzer to the signals that control the power to the radio. We
can measure how long it takes for software to respond. We can see the
software puts out appropriate signal patterns to control the hardware.

Logical Analyzer in State Mode:

In the timing mode, logic analyzers are self clocked. That is, it captures data without
reference to any events on the circuit. In the state mode, they capture data when some
particular event occurs, called a clock occurs in the system.

In this mode the logical analyzer sees what instructions the microprocessor fetched
and what data is read from and written to its memory and I/O devices.

5
 MOHAMMED ZIA AHMED KHAN
MECH-B 1604-17-736-070

PES - ASSIGNMENT 5
To see what instructions the microprocessor fetched, you connect logical analyzer
probes to address and data signals of the system and RE signal on the ROM.

Whenever RE signal raises then logical analyzer capture the address and data
signals. The captured data is called a trace.

The data is valid when the RE signal rises. State mode analyzers present a text
display as a state of signals in a row as shown in the below figure.

Typical logic analyzer state mode display.

The logical analyzer in state mode extremely useful for the software engineer,

o Trigger the logical analyzer, if the processor never fetch if there is no memory.
o Trigger the logical analyzer, if the processor writes an invalid value to a particular
address in RAM.
o Trigger the logical analyzer, if the processor fetches the first instruction of ISR and
executed.
o If we have a bug that rarely happens, leave the processor and analyzer running
overnight and check results in the morning.
o There is a filter to limit what is captured.

Logical analyzers have shortcomings:

o Even though analyzers tell what processor did, we cannot stop, break the
processor, even if it did wrong.
o For the analyzer the processor's registers are invisible, only we know the
contents of memory in which the processors can read or write.
o If the program crashes, we cannot examine anything in the system.
o We cannot find if the processor executes out of cache.
o Even if the program crashes, the emulator can still let us see the contents of
memory and registers.
o Most emulators capture the trace like analyzers in the state mode.
o Many emulators have a feature called overlay memory, one or more blocks
of memory inside the emulator, the emulated microprocessor can use
instead of the target machine.

6
 MOHAMMED ZIA AHMED KHAN
MECH-B 1604-17-736-070

PES - ASSIGNMENT 5

15(c) What is an in-circuit emulator? Describe its role in debugging with a neat
diagram.
A)

An In-circuit emulator (ICE) is a debugging tool that allows you to access a target MCU for in-
depth debugging. A genuine ICE requires you to remove the microcontroller and to insert the ICE in
its place, most commonly using an adapter. In-circuit emulation is rather rare in these days of high-
performance, relatively low-cost processors because ICE needs to be invisible to the system, which is
difficult to do with extremely fast, memory-intensive chips. ICE is the best tool for finding difficult
bugs and can provide invaluable insight.

ICE consists of a hardware board with accompanying software for the host computer. The
ICE is physically connected between the host computer and the target MCU. The debugger on the
host establishes a connection to the MCU via the ICE. ICE allows a developer to see data and signals
that are internal to the MCU, and to step through the source code (e.g., C/C++ on the host) or set
breakpoints; the immediate ramifications of executed software are observed during run time.

Since the debugging is done via hardware, not software, the MCU’s performance is left
intact for the most part, and ICE does not compromise MCU resources. This type of debugging is also
referred to as source-level or run-time debugging, except ICE is as close to the real scenario as
possible, as it’s not a simulation but a substitution of the target MCU with an emulation, or
accurate mirror, of the target MCU in the ICE itself. The behavior of the MCU will be more
accurately reflected in ICE, and in real-time.

The disadvantage of ICE debugging

o The ICE hardware must be physically connected to the MCU. As chips get smaller,
adapters can help in connecting tiny surface-mounted chips to the ICE.
o ICE devices come with a learning curve, especially if there will be complex debugging
functions, for example, flagging when a register holds a specific value after a
conditional branch is taken, etc.