embedded embsystem sem 2 abhinav anand.pptx

Embedded system

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.

7. 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.

8. Kernels

9. 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.

10. 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.

11. 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.

12. 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.

13. 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.

14. 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.

15. 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).

16. 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.

17. 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.

18. 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.

19. Thank you.