Embedded Systems: Integrated Development Environment

EMBEDDED SYSTEMS: INTEGRATED DEVELOPMENT ENVIRONMENT

Chapter Structure

Objectives

1 Introduction

2 Embedded IDE

3 Types of file generated on cross compilation

4 DISASSEMBLER/ DECOMIPILER

5 SIMULATOR

6 FirmWare Debugging

OBJECTIVES

After reading this chapter you will understand:

Embedded IDE

Types of file involved

Disassembler/ Decomipiler

Simulator

Firmware Debugging and Emulator

1 INTRODUCTION

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)

 Cross Compiler(For Cross platform development and complier for the same platform development)

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.

GUI Base

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

List File(.lst):-

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:

Page Header

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

2.Command Line

 It represents the entire command line that was used for invoking the compiler.

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

LISTINCLUDE SYMBOLS

3.Source Code

It contains source code along with line numbers

Line level Source

1 //Sample.c for printing Hello World!

//Written by xyz

#include<stdio.h>

//Body part starts

//Body part end

void main()

{

printf(“Hello World”);

}

//Header part ends

Assembly listing

It contains the asembly code generated by compiler for even given ‘C’ code.

ASSEMBLY LISTING OF GENERATED OBJECT CODE;

FUNCTION main(BEGIN)

;SOURCE LINE #5

;SOURCE LINE #6

0000 7BFF

MOV R3,#0FFH

0002 7A00 R MOV R2,#HIGH?SC_0

Symbol listing

It contains symbolic information about the various symbols present in the cross compiled source file.

Eg: NAME, TYPE, SFR, SIZE.

•

Module Information

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)

Map File(.MAP)

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:

Page Header

Each MAP file contains a header which indicates the linker version number, date, time and page number.

Command Line

Represents the entire command line that was used for invoking the linker.

CPU Details

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.

Memory Map

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.

Ex.

NAME…………………….USAGE……………………..

MODULE NAMES ?CCCASE…………………CODE;……………………?

C?CCASE PRINTF ?C?CLDOPTR……………CODE;…………….…..?C?

CLDOPTR PRINTF ?C?CSTPTR………………CODE;………………….?C

?CSTPTR PRINTF

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:

Intel Hex

Motorola Hex.

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.

 A DISASSEMBLER is a utility program which converts machine codes into target processor specific assembly code/instruction.

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.

5 SIMULATOR

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

Advantages

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

Disadvantages

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.

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’