The document discusses host-based debugging, emphasizing the challenges posed by architectural differences such as word size and byte order when debugging C/C++ and assembly applications. It elaborates on remote debugging, kernels, ROM emulators, logic analyzers, and 'bulletproof run control' to ensure consistent and reliable testing results. Each tool and technique is essential for identifying and resolving issues in embedded systems and enhances overall software quality.

1. Host based debugging - Remote debuggers
and Kernel
ROM emulator
Logic analyzer
Bullet proof run control
By
Abhinav Anand
S2,Msc Electronics

2. Host based debugging
• If you write your applications in C or C++, you should be able to debug
an algorithm on the host.
• Even if you write in assembly you can execute the code on your
desktop system using an Instruction Set Simulator (ISS) until you need
to test the real-time interaction of the code and the target system s
special hardware.

3. Aside from the availability of real working peripherals, the greatest
source of problems for host-based debugging derives from two
architectural characteristics:
• Word size and,
• Byte order

4. Word Size
• If your embedded processor has a 16-bit wide architecture and your
host-based compiler is expecting a 32-bit data path, you can have
problems.
• Numbers bigger than the targeted range will cause bugs that you ll
never see on the PC.

5. Byte Order
• Debuggers for embedded systems address this limitation by
distributing the debugger; a portion of the debugger resides on the
host computer, and a portion resides in the target system.
• The two elements of the debugger communicate with each other
over a communications channel, such as a serial port or Ethernet
port.

6. Remote debuggers and Kernels
Remote debuggers
If you debug a routine running on your workstation, you are performing
local debugging. If you debug a routine running on a system accessible
through a network connection, you are performing remote debugging.
• With remote debugging, you can run the routine on one system and
control it from your workstation.
• To be able to debug remotely, you need access to the remote
machine where the database and routine you are debugging resides.

8. Why Use Remote Debugging?
• The routine you are debugging might be running on another system
and might behave differently on that system than on your own. You
can use the remote debug feature to debug this routine on the
(other) remote system from your local system.
• The routine you are debugging might have been compiled for a
platform where the debugger UI will not run. You can use the remote
debugging feature to take advantage of the debugger UI on your local
machine while debugging the routine running on the remote
machine.

9. Kernels

10. • The portion of the debugger that resides in the target is called the
target agent or the debug kernel.
• Kernel debugging is a task normally performed by systems engineers
writing kernel programs.
• A kernel program is one that is built as part of the kernel and that
references kernel data structures.

11. • Kernel programs can be difficult to debug because you normally
cannot control kernel execution.
• To make debugging kernel programs more convenient, the Digital
UNIX system provides the kdebug debugger.

12. ROM Emulator
The ROM emulator contains the following system elements.
• Cabling device(s) to match the target system mechanical footprint of
the target system ROM devices
• Fast RAM to substitute for the ROM in the target system.
• Local control processor.
• Communications port(s) to the host.
• Additional features, such as trace memory and flash programming
algorithms.

13. • ROM emulator allows you the luxury of quickly downloading new
object code images to run in your target system.
• A ROM emulator is really RAM, so you ll have no problem setting
breakpoints in memory.

15. Logic analyzer
• A logic analyzer is an electronic instrument that captures and displays
multiple signals from a digital system or digital circuit.
• Logic analyzers have advanced triggering capabilities, and are useful
when a user needs to see the timing relationships between many
signals in a digital system.

16. • Logic analyzers can uncover hardware defects that are not found in
simulation.
• Logic Analyzers are also very useful when it comes to analyze serial
protocols, like I2C, SPI or UART, as they allow to capture long logic
sequences.

18. Bullet proof run control
• "Bulletproof run control" refers to the process of creating and
executing test runs that are highly controlled and designed to
produce consistent and reliable results.
• The goal of bulletproof run control is to minimize the likelihood of
false positives (i.e., tests that incorrectly report a failure) and false
negatives (i.e., tests that fail to identify a real issue).

19. Bulletproof run control typically involves the
following steps:
• Defining a clear test plan with well-defined objectives, test cases, and
expected results.
• Establishing a controlled testing environment.
• Creating a set of test data that is representative of real-world usage
scenarios.

20. • Running the tests repeatedly to ensure consistency and repeatability,
and documenting the results of each test run.
• Analyzing the results to identify any issues or inconsistencies, and
making any necessary adjustments to the testing process or test
cases.

21. By following these steps and implementing a rigorous, controlled
testing process, organizations can increase the accuracy and reliability
of their software testing, leading to higher-quality software products
and a more positive user experience.

22. Thank you.