EMBEDDED SYSTEMS: INTEGRATED DEVELOPMENT ENVIRONMENT
2 Embedded IDE
3 Types of file generated on cross compilation
4 DISASSEMBLER/ DECOMIPILER
6 FirmWare Debugging
After reading this chapter you will understand:
Types of file involved
Firmware Debugging and Emulator
This chapter explains the IDE used for embedded systems. It then explains the different types of files that are generated on cross compilation. Then it gives an account of utility tools like Disassembler/
Decomipiler, Simulator and then FirmWare Debugging.
2 EMBEDDED IDE
Integrated Development Environment with respect to embedded system IDE stands for an Integrated Environment for developing and debugging the target processor specific embedded software.
IDE is a software package which contains:
Text Editor(Source Code Editor)
Linker and debugger.
Some IDEs may provide an interface to an emulator or device programmer.
IDEs are used in embedded firmware development.
IDEs may be of two types:
Command Line Base
Turbo C++ IDE is an example for a generic IDE with a Command Line Interface.
Microsoft Visual Studio is an example of GUI base IDE.
Others examples are NetBeans, Eclipse.
3 TYPES OF FILE GENERATED ON CROSS COMPILATION
Following are some of the files generated upon cross compilation:
List file .lst
Hex file .hex
Preprocessor output file
Map file .map
Obj file .obj
Listing file is generated during the cross-compilation process.
It contains an information about the cross compilation process like cross compiler details, formatted source text(‘C’ code), assembly code generated from the source file, symbol tables, errors and warnings detected during the cross-compilation process.
The list file contain the following sections:
It indicates the compiler version name, source file name, Date, Page No.
Example: C51 COMPILER V8.02 SAMPLE 05/23/2006 11:12:58 PAGE 1
C51 COMPILER V8.02, COMPILATION OF MODULE SAMPLE OBJECT MODULE PLACED IN sample.obj
COMPILER INVOKED BY: C:\Keil\C51\BIN\C51.EXE sample.c BROWSE DEBUG OBJECTTEXTEND CODE
It contains source code along with line numbers
Line level Source
1 //Sample.c for printing Hello World!
//Written by xyz
//Body part starts
//Body part end
//Header part ends
It contains the asembly code generated by compiler for even given ‘C’ code.
ASSEMBLY LISTING OF GENERATED OBJECT CODE;
;SOURCE LINE #5
;SOURCE LINE #6
0002 7A00 R MOV R2,#HIGH?SC_0
It contains symbolic information about the various symbols present in the cross compiled source file.
Eg: NAME, TYPE, SFR, SIZE.
The module information provides the size of initialized and un-initialized memory areas defined by the source file.
Module Information Static Overlayable
Code Size 9 -------------
Constant size 14 -------------
Bit size ------- -------------
END OF MODULE INFORMATION
Warnings and Errors
Warnings and Errors section of list file records the errors encountered or any statement that may create issues in application(Warnings), during cross compilation.
• ie:- C51 COMPILATION COMPLETE, 0WARNING(S), 0 ERROR(S).
Preprocessor Output File
It contains preprocessor output for preprocessor instructions used in the source file.
This file is used for verifying the operation of Macros and preprocessor directive.
Object File(.OBJ File)
Cross-compiling each source module converts the Embedded C/Assembly instructions and other directives present in the module to an object(.OBJ file)
Also called as Linker List file. Map file contains information about the link/locate process and is composed of a number of sections described below:
Each MAP file contains a header which indicates the linker version number, date, time and page number.
Represents the entire command line that was used for invoking the linker.
It contains details about the target CPU and its memory model which includes information on internal data memory, external data memory, paged data memory, etc.
IV. Input Modules
It includes the names of all the object files, library files and other files that are included in the linking process.
t lists the starting address, length, relocation type and name of each segment in the program
VI. Symbol Table
It contains the name, value and type for all symbols from different input modules.
VII. Inter Module Cross Reference
It includes the section name, memory type and module names in which it is defined and all modules where it is accessed.
MODULE NAMES ?CCCASE…………………CODE;……………………?
C?CCASE PRINTF ?C?CLDOPTR……………CODE;…………….…..?C?
CLDOPTR PRINTF ?C?CSTPTR………………CODE;………………….?C
VIII. Program Size
It contains the size of various memory areas, constants and code space for the entire application Ex. Program Size: data=80.1 xdata=0 code 2000
IX. Warnings and Errors
It contains the warnings and errors that are generated while linking a program. It is used in debugging link errors
HEX FILE (.hex file)
It is a binary executable file created from the source code.
The file created by linker/locater is converted into processor understandable binary code.
The tool used for converting and object file into a hex file is known as object to Hex converter.
Hex file have specific format and it varies for different processor and controller. Two commonly used hex file format are:
5. Both Intel and Motorola hex file format represent data in the form of ASCII codes.
4 DISASSEMBLER/ DECOMIPILER
A Disassembler/ Decomipiler is a reverse engineering tool.
Reverse Engineering is used in embedded system to find out the secret behind the working of a proprietary product.
The process of converting machine codes to assembly code is called disassembling.
A DECOMIPILER is a utility program for translating machine codes into corresponding high level language instruction.
A decompiler performs the reverse operation of a compiler/cross-compiler.
Simulators are used for embedded firmware debugging.
Simulator simulates the target hardware, while the code execution can be inspected.
Simulators have the following characteristics which make them very much favorable:
Purely software based
No need of target system (hardware)
Support only for basic operations
Cannot Support or lack real time behavior
1. Simple and straight forward.
Simulators are a software utility with assumptions about the underlying hardware. So it only requires concentrating on debugging of the code, hence straight forward.
2. No Hardware
• Simulators are purely software oriented.
• The IDE simulates the target CPU. The user needs to know only about the target specific details like memory map of various devices.
• Since no hardware is required the code can be written and tested even before the hardware prototype is ready thus saving development time
3. Simulation options
Simulators provide various simulation options like I/O peripherals or CRO or Logic analyzers.
Simulators I/O support can be used to edit values for I/O registers.
Simulation of abnormal conditions
Using simulator the code can be tested for any desired value.
This helps to study the code behavior in abnormal conditions without actually testing it on the hardware
Lack of real time behavior
A simulator assumes the ideal condition for code execution.
Hence the developer may not be able to debug the code under all possible combinations of input.
The results obtained in simulation may deviate from actual results on target hardware.
Lack of real timeliness
The I/O condition in hardware is unpredictable. So the output of simulation is usually under ideal condition and hence lacks timeliness.
6 FIRMWARE DEBUGGING
Debugging in embedded application is the process of diagnosing the firmware execution, monitoring the target processor’s registers and memory while the firmware is running and checking the signals on various buses of hardware.
Debugging is classified into Hardware Debugging and Firmware Debugging.
Hardware Debugging deals with debugging the various aspects of hardware involved in the embedded system.
The various tools used for hard ware debugging are Multimeter, CRO, Logic Analyzers and Function Generators.
Firmware Debugging involves inspecting the code, its execution flow, changes to different registers on code execution.
It is done to find out the bugs or errors in code which produces unexpected behavior in the system.
There is a wide variety of firmware debugging techniques available that have advanced from basic to advanced.
Some to the tools used are Simulators and Emulators.
The terms simulators and emulators are very confusing but their basic functionality is the same i.e. to debug the code. There is a difference in which this is achieved by both the tools.
A simulator is a utility program that duplicates the target CPU and simulates the features and instructions supported by target CPU whereas an Emulator is a self contained hardware device which emulates the target CPU.
The Emulator hardware contains the necessary emulation logic and is connected to the debugging application that runs on the host PC.
The Simulator ‘simulates’ while the Emulator ‘emulates’