TESTING ON YOUR HOST MACHINE:

In this topic we will discuss some methods for testing and debugging Embeddedsystem software so that it will really work when you deliver it to customers. Most
experienced engineers said that lots of bugs in the code will not accepted and require
more time and money to reduce that bugs that is a product with fewer bugs is to write
software with fewer bugs in the first place. The techniques for keeping bugs out of your
embedded-system software are much the same as for keeping them out of your
application software. However, they are more important for two reasons. First, testing
and debugging embedded systems is a difficult and time-consuming problem, even more
so than testing and debugging applications. The fewer bugs, the less aggravation. Second,
the world is extremely intolerant of buggy embedded systems. Consumers seem willing
to buy applications for personal computers that lock up occasionally, presenting either a
stiff, uninformative message or a cute bomb icon. No one accepts cash registers that crash
in the middle of checking out customers, telephone switching equipment that
occasionally connects you to the wrong person, medical instruments that stop working
during surgery, or printers that stop printing for no apparent reason.

Two systems with different CPUs or microcontroller and hardware architecture.

One system is host, generally PC or laptop or workstation.
Other system is target, actual hardware to be used for embedded system under

development.
Testing and debugging is done at each stage and at final stage testing is done

when modules are put together.

At initial stages testing is done on host machine.
Host machine is used to test hardware independent codes.
Host is also used to run simulators.
Code has two parts: hardware independent and hardware dependent codes.

Scaffold code provides the same entry points as the HW independent code.

HWdependent code can be debugged on HW only.

For example, port and devices will have fixed addresses on hardware.

Target is used to test hardware independent codes.

Target is also used to run monitors.
Interrupt routines are major part of the system in this Calling interrupt routines

needs to be done from scaffold. It is not difficult to maintain interrupt services.

Split code of the ISR in two: HWdependent and HWindependent.
Place the HWindependent code in a separate function and Test this code
extensively.

Example: character processing on the serial line

Testing steps at host machine:
1. Initial tests:
Test each module or segment at initial stage itself and on host itself.
2. Test data:
All possible combination of data are designed and taken as test data.
3. Exception condition tests:
Consider all possible exceptions for the test.
4. Test-1:
Test hardware independent code.
5. Test-2:
Test scaffold software, is used for all the input and output devices which have the
start code and port and device addresses at the hardware examples keyboard,
LCD etc.
6. Test interrupt service routines hardware independent part:
Those sections of interrupt service routines are called, which are hardware
independent and tested.
7. Test interrupt service routines hardware dependent part:
Those sections of interrupt service routines are called, which are hardware
dependent and tested.
8. Timer tests:
Hardware dependent code has timing functions and uses a timing devices, timer
related routines such as clock tick set, counts get, counts put, and delay are
tested.
9. Assert macro tests:
We insert the codes in the program that check whether a condition or parameter
actually turns true or false. If it turns false, the program stops, we can use the
assert macro at different critical places in the application program.

The target system is a troublesome testing environment. Consider the goals of the
typical testing process:
Find the bugs early in the development process:
Testing early gives you some idea of how many bugs you have and therefore how
much trouble in program but the target system very often is not available early in the
process, or the hardware may be buggy and unstable.
Exercise all of the code:
This includes all of the exceptional cases, even though you hope that they will
never happen but it varies from difficult to impossible to exercise all the code in the

target, because in an embedded system, a fair amount of code invariably deals with
unlikely situations.
Develop reusable, repeatable tests:
It is extraordinarily frustrating to see a bug once but then not be able to find it
because it refuses to happen
Leave an "audit trail" of test results:
In Telegraph "seems to work" in the network environment is not nearly as
valuable as knowing and storing exactly what data it sends out in response to received
data. But since most embedded systems do not have a disk drive or other permanent
storage medium, it is often difficult to keep track of what results we got.
From this we know that don't test on the target any more than you have to. The
alternative is to test as much of your code as you possibly can on your development host.
Figure1 shows the basic method for testing embedded software on the development host.

Figure 1: Test system

The left-hand side of the figure shows the target system. The right-hand side shows how
the tests will be conducted on the host. The hardware-independent code on the two sides
of the figure is compiled from the same source; the hardware and the hardware-dependent
code on the left has been replaced with test scaffold software on the right. This 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 instruction from the keyboard or from a file; it produces output
onto the display or into a log file
Calling Interrupt Routines:
The most embedded systems do things because interrupts occur and the interrupt
routines are executed. Therefore, to make the system do anything in the test environment,

the test scaffold must execute the interrupt routines. This turns out not to be difficult:
interrupt routines tend to divide into two parts: one that deals with the hardware and one
that deals with the rest of the system. For test purposes you structure your interrupt
routines so that the hardware-dependent part calls the hardware- independent part. We
write this latter part in C, and the test scaffold can simply call it.
Calling the Timer Interrupt Routine:
One interrupt routine your test scaffold should call is the timer interrupt routine.
In most embedded-system software the passage of time and the timer interrupt routine
initiate at least some of the activity. You could have the passage of time in your host
system call the timer interrupt routine automatically, so that time goes by in your test
system without the test scaffold's participation. This, however, is usually a mistake. It
causes your test scaffold to lose control of the timer interrupt routine. The timer interrupt
routine will sometimes execute just before or just after other things that your test scaffold
software is doing, causing intermittent bugs. In short, you will import into your host test
environment some of the aggravating problems that bedevil the target test environment.
Script Files and Output Files:
You could write a test scaffold that calls the various interrupt routines in a certain
sequence and with certain data, but you can get a lot of testing done more easily by
writing a test scaffold that reads a script from the keyboard or from a file and then makes
calls as directed by the script. A script file parser need not be a major project; script files
can be very simple.
EXAMPLE:
There are numerous similar examples. When the hardware-independent code in
the cordless bar-code scanner sends a frame on the radio, the test scaffold captures it and
then automatically calls the interrupt routine to indicate that the frame has been sent.
When hardware-independent code sets a short timer say 200 microseconds-the
test scaffold might call the timer interrupt routine right away, rather than forcing you to
tell the test scaffold to do it every time. Whenever the system produces output that the
test scaffold captures, you may be able to make your testing life easier by having the test
scaffold software respond automatically. Another technique to consider if your project
includes multiple systems that must communicate with each other is to set up a test
scaffold that contains multiple instances of the hardware-independent code and that acts
as the communications medium among them. For the cordless bar-code scanner, for
example, the test scaffold would have multiple instances of the hardware-independent

code for the scanner and multiple instances of the hardware-independent code for the
cash register. To each instance of the hardware-independent code the test scaffold appears
to be the radio hardware, and it sends and receives data just as the real radio will on the
target hardware.

Figure 2: Test Scaffold for the Bar-code Scanner Software

In Figure 2 bar-code scanner A sends a data frame, which the test scaffold
captures. Since the test scaffold also captures information whenever any of the instances
of the hardware-independent code calls a function to control its radio, the test scaffold
knows which instances have turned their radios on and at what frequencies. The test
scaffold calls the receive-frame interrupt routine in each of the other instances that has its
radio turned on and tuned to the same frequency as the radio that transmitted the data.
Targets that have their radios off or tuned to a different frequency do not receive the
frame. Furthermore, you can program the test scaffold to simulate interference that
prevents one or more stations from receiving the data. In this way the test scaffold can
test that the various pieces of software communicate properly with each other.