INTRODUCTION TO EMBEDDED SYSTEMS | M O D U L E 4 :

Embedded Firmware Design and Development

Module4 : Embedded Firmware Design and Development

Introduction to Embedded Firmware Design

 The embedded firmware is responsible for controlling the various peripherals of the
embedded hardware and generating response in accordance with the functional
requirements.
 Firmware is considered as the master brain of the embedded system.
 Imparting intelligence to an Embedded system is a one time process and it can happen at
any stage.
 It can be immediately after the fabrication of the embedded hardware or at a later
stage.
 For most of the embedded products, the embedded firmware is stored at a permanent
memory (ROM) and they are non-alterable by end users.
 Some of the embedded products used in the Control and Instrumentation domain
are adaptive.
 Designing embedded firmware requires understanding of the particular embedded product
hardware, like various component interfacing, memory map details, I/O port details,
configuration and register details of various hardware chips used and some programming
language.
 Embedded firmware development process starts with the conversion of the firmware
requirements into a program model using modelling tools.
 Once the program model is created, the next step is the implementation of the tasks and
actions by capturing the model using a language which is understandable by the target
processor/controller.

Embedded Firmware Design Approaches

 The firmware design approaches for embedded product is purely dependent on the
complexity of the functions to be performed, the speed of operation required, etc.
 Two basic approaches are used for embedded firmware design:
 Super Loop Based Approach (Conventional Procedural Based Design)
 Embedded Operating System (OS) Based Approach

Super Loop Based Approach

 The Super Loop based firmware development approach is adopted for applications that
are not time critical and where the response time is not so important.
 It is very similar to a conventional procedural programming where the code is executed
task by task.
 The task listed at the top of the program code is executed first and the tasks just below the
top are executed after completing the first task.
 In a multiple task based system, each task is executed in serial in this approach.
 The firmware execution flow for this will be

AJIET | D E P T . O F CSE
 INTRODUCTION TO EMBEDDED SYSTEMS | MODULE 4:
Embedded Firmware Design and Development

 Configure the common parameters and perform initialisation for various hardware
components memory, registers, etc.
 Start the first task and execute it
 Execute the second task
 Execute the next task
:
:
 Execute the last defined task
 Jump back to the first task and follow the same flow
 The order in which the tasks to be executed are fixed and they are hard coded in the code
itself.
 Also the operation is an infinite loop based approach.
 We can visualise the operational sequence listed above in terms of a 'C' program code as

 Almost all tasks in embedded applications are non-ending and are repeated infinitely
throughout the operation.
 This repetition is achieved by using an infinite loop.
 Hence the name 'Super loop based approach’.
 The only way to come out of the loop is either a hardware reset or an interrupt assertion.
 Advantage of Super Loop Based Approach:
 It doesn't require an operating system
 There is no need for scheduling which task is to be executed and assigning priority
to each task.
 The priorities are fixed and the order in which the tasks to be executed are also
fixed.
 Hence the code for performing these tasks will be residing in the code memory
without an operating system image.
 Applications of Super Loop Based Approach:
 This type of design is deployed in low-cost embedded products and products
where response time is not time critical.
 Some embedded products demands this type of approach if some tasks itself are
sequential.

AAA D E P T . O F CSE AJIET

| AJIET
 INTRODUCTION TO EMBEDDED SYSTEMS | M O D U L E 4 :
Embedded Firmware Design and Development

For example, reading/writing data to and from a card using a card reader requires
a sequence of operations like checking the presence of card, authenticating the
operation, reading/writing, etc.
 It should strictly follow a specified sequence and the combination of these series
of tasks constitutes a single task-namely data read/write.
 A typical example of a 'Super loop based’ product is an electronic video game toy
containing keypad and display unit.
 The program running inside the product may be designed in such a way that it
reads the keys to detect whether the user has given any input and if any key press
is detected the graphic display is updated.
 The keyboard scanning and display updating happens at a reasonably high rate.
 Even if the application misses a key press, it won't create any critical issues; rather
it will be treated as a bug in the firmware.
 Drawbacks of Super Loop Based Approach:
 Any failure in any part of a single task will affect the total system.
 If the program hangs up at some point while executing a task, it will remain
there forever and ultimately the product stops functioning.
 Watch Dog Timers (WDTs) can be used to overcome this, but this, in turn,
may cause additional hardware cost and firmware overheads.
 Lack of real timeliness.
 If the number of tasks to be executed within an application increases, the
time at which each task is repeated also increases.
 This brings the probability of missing out some events.

Embedded Operating System (OS) Based Approach

 The Embedded Operating System (OS) based approach contains operating systems, which
can be either a General Purpose Operating System (GPOS) or a Real Time Operating
System (RTOS) to host the user written application firmware.
 The General Purpose OS (GPOS) based design is very similar to a conventional PC based
application development where the device contains an operating system
(Windows/Unix/Linux, etc. for Desktop PCs) and you will be creating and running user
applications on top of it.
 Example of a GPOS used in embedded product development is Microsoft
Windows XP Embedded.
 Examples of Embedded products using Microsoft Windows XP OS are Personal
Digital Assistants (PDAs), Hand held devices/Portable devices and Point of Sale
(POS) terminals.
 Use of GPOS in embedded products merges the demarcation of Embedded Systems and
general computing systems in terms of OS.
 For developing applications on top of the OS, the OS supported APIs are used.
 Similar to the different hardware specific drivers, OS based applications also require
'Driver software' for different hardware present on the board to communicate with them.

AJIET | D E P T . O F CSE
 INTRODUCTION TO EMBEDDED SYSTEMS | MODULE 4:
Embedded Firmware Design and Development

 Real Time Operating System (RTOS) based design approach is employed in embedded
products demanding Real-time response.
 RTOS responds in a timely and predictable manner to events.
 Real Time operating system contains a Real Time kernel responsible for performing pre-
emptive multitasking, scheduler for scheduling tasks, multiple threads, etc.
 A Real Time Operating System (RTOS) allows flexible scheduling of system resources like
the CPU and memory and offers some way to communicate between tasks. 'Windows CE',
'pSOS', 'VxWorks', 'ThreadX', 'MicroC/OS-II’, 'Embedded Linux', 'Symbian’, etc. are
examples of RTOS employed in embedded product development.
 Mobile phones, PDAs (Based on Windows CE/Windows Mobile Platforms), handheld
devices, etc. are examples of 'Embedded Products' based on RTOS.

Embedded Firmware Development Languages

 For embedded firmware development, we can use either

 a target processor/controller specific language (Generally known as Assembly
language or low level language) or
 a target processor/controller independent language (Like C, C++, JAVA, etc.
commonly known as High Level Language) or
 a combination of Assembly and High level Language.

Assembly Language Based Development

 Assembly language is the human readable notation of 'machine language’

 ‘Machine Ianguage' is a processor understandable language.
 Machine language is a binary representation and it consists of 1s and 0s.
 Machine language is made readable by using specific symbols called 'mnemonics’.
 Hence machine language can be considered as an interface between processor and
programmer.
 Assembly language and machine languages are processor/controller dependent and an
assembly program written for one processor/controller family will not work with others.
 Assembly language programming is the task of writing processor specific machine code in
mnemonic form, converting the mnemonics into actual processor instructions (machine
language) and associated data using an assembler.
 Assembly Language program was the most common type of programming adopted in the
beginning of software revolution.
 Even today also almost all low level, system related, programming is carried out using
assembly language.
 In particular, assembly language is often used in writing the low level interaction between
the operating system and the hardware, for instance in device drivers.
 The general format of an assembly language instruction is an Opcode followed by
Operands.
 The Opcode tells the processor/controller what to do and the Operands provide the data
and information required to perform the action specified by the opcode.
AAA D E P T . O F CSE AJIET
| AJIET
 INTRODUCTION TO EMBEDDED SYSTEMS | M O D U L E 4 :
Embedded Firmware Design and Development

 For example: MOV A, #30

 Here MOV is the Opcode and A, #30 is the operands
 The Assembly language program written in assembly code is saved as .asm (Assembly file)
file or an .src (source) file (also. s file).
 Any text editor like ‘Notepad' or 'WordPad' from Microsoft or the text editor provided by
an Integrated Development (IDE) tool can be used for writing the assembly instructions.
 Similar to 'C' and other high level language programming, we can have multiple source files
called modules in assembly language programming.
 Each module is represented by an '.asm' or '.src' file.
 This approach is known as 'Modular Programming’.
 Modular programming is employed when the program is too complex or too big.
 In 'Modular Programming', the entire code is divided into submodules and each
module is made re-usable.
 Modular Programs are usually easy to code, debug and alter.

Source File to Object File Translation

 Translation of assembly code to machine code is performed by assembler.

 The assemblers for different target machines are different.
 A51 Macro Assembler from Keil software is a popular assembler for the 8051
family microcontroller.
 The various steps involved in the conversion of a program written in assembly language
to corresponding binary file/machine language are illustrated in the figure.

 Each source module is written in Assembly and is stored as .src file or .asm file.
 Each file can be assembled separately to examine the syntax errors and incorrect assembly
instructions.
 On successful assembling of each .src/.asm file a corresponding object file is created with
extension '.obj’.

AJIET | D E P T . O F CSE
 INTRODUCTION TO EMBEDDED SYSTEMS | MODULE 4:
Embedded Firmware Design and Development

 The object file does not contain the absolute address of where the generated code
needs to be placed on the program memory and hence it is called a re-locatable
segment.
 It can be placed at any code memory location and it is the responsibility. of the
linker/locater to assign absolute address for this module.

Library File Creation and Usage

 Libraries are specially formatted, ordered program collections of object modules that may
be used by the linker at a later time.
 Library files are generated with extension '. lib’.
 When the linker processes a library, only those object modules in the library that are
necessary to create the program are used.
 Library file is some kind of source code hiding technique.
 For example, 'LIB51' from Keil Software is an example for a library creator and it
is used for creating library files for A51 Assembler/C51 Compiler for 8051 specific
controllers.

Linker and Locator

 Linker and Locater is another software utility responsible for "linking the various object
modules in a multi-module project and assigning absolute address to each module".
 Linker generates an absolute object module by extracting the object modules from the
library, if any, and those obj files created by the assembler, which is generated by
assembling the individual modules of a project.
 It is the responsibility of the linker to link any external dependent variables or functions
declared on various modules and resolve the external dependencies among the modules.
 An absolute object file or module does not contain any re-locatable code or data.
 All code and data reside at fixed memory locations.
 The absolute object file is used for creating hex files for dumping into the code memory
of the processor/controller.
 'BL51' from Keil Software is an example for a Linker & Locater for A51
Assembler/C51 Compiler for 8051 specific controller.

Object to Hex File Converter

 This is the final stage in the conversion of Assembly language (mnemonics) to machine
understandable language (machine code).
 Hex File is the representation of the machine code and the hex file is dumped into the
code memory of the processor/controller.
 The hex file representation varies depending on the target processor/controller make.
 HEX files are ASCII files that contain a hexadecimal representation of target application.

AAA D E P T . O F CSE AJIET

| AJIET
 INTRODUCTION TO EMBEDDED SYSTEMS | M O D U L E 4 :
Embedded Firmware Design and Development

 Hex file is created from the final 'Absolute Object File' using the Object to Hex File
Converter utility.
 'OH51' from Keil software is an example for Object to Hex File Converter utility
for A51 Assembler/C51 Compiler for 8051 specific controller.

Advantages of Assembly Language Base Development

 Efficient Code Memory and Data Memory Usage (Memory Optimisation)

 Since the developer is well versed with the target processor architecture and
memory organisation, optimised code can be written for performing operations.
 This leads to less utilisation of code memory and efficient utilisation of data
memory.
 High Performance
 Optimised code not only improves the code memory usage but also improves the
total system performance.
 Through effective assembly coding, optimum performance can be achieved for a
target application.
 Low Level Hardware Access
 Most of the code for low level programming like accessing external device specific
registers from the operating system kernel, device drivers, and low level interrupt
routines, etc. are making use of direct assembly coding since low level device
specific operation support is not commonly available with most of the high-level
language cross compilers.
 Code Reverse Engineering
 Reverse engineering is the process of understanding the technology behind a
product by extracting the information from a finished product.
 Reverse engineering is performed by 'hawkers' to reveal the technology behind
'Proprietary Products’.
 Though most of the products employ code memory protection, if it may be
possible to break the memory protection and read the code memory, it can easily
be converted into assembly code using a dis-assembler program for the target
machine.

Drawbacks of Assembly Language Based Development

 High Development Time

 Assembly language is much harder to program than high level languages.
 The developer must pay attention to more details and must have thorough
knowledge of the architecture, memory organisation and register details of the
target processor in use.
 Learning the inner details of the processor and its assembly instructions is highly
time consuming and it creates a delay impact in product development.

AJIET | D E P T . O F CSE
 INTRODUCTION TO EMBEDDED SYSTEMS | MODULE 4:
Embedded Firmware Design and Development

Also more lines of assembly code are required for performing an action which can
be done with a single instruction in a high-level language like 'C'.
 Developer Dependency
 Unlike high level languages, there is no common written rule for developing
assembly language based applications.
 In assembly language programming, the developers will have the freedom to
choose the different memory location and registers.
 Also the programming approach varies from developer to developer depending on
his/her taste.
 For example, moving data from a memory location to accumulator can be achieved
through different approaches.
 If the approach done by a developer is not documented properly at the
development stage, he/she may not be able to recollect why this approach is
followed at a later stage or when a new developer is instructed to analyse this code,
he/she also may not be able to understand what is done and why it is done.
 Hence upgrading an assembly program or modifying it on a later stage is very
difficult.
 Non-Portable
 Target applications written in assembly instructions are valid only for that
particular family of processors (e.g. Application written for Intel x86 family of
processors) and cannot be re-used for another target processors/controllers (Say
ARM11 family of processors).
 If the target processor/controller changes, a complete re-writing of the application
using the assembly instructions for the new target processor/controller is required.

High Level Language Based Development

 Any high level language (like C, C++ or Java) with a supported cross compiler for the
target processor can be used for embedded firmware development.
 The most commonly used high level language for embedded firmware application
development is 'C’.
 ‘C’ is well defined, easy to use high level language with extensive cross platform
development tool support.
 Nowadays cross-compilers for C++ is also emerging out and embedded developers are
making use of C++ for embedded application development.
 The various steps involved in high level language based embedded firmware development
is same as that of assembly language based development except that the conversion of
source file written in high level language to object file is done by a cross-compiler.
 In Assembly language based development it is carried out by an assembler.
 The various steps involved in the conversion of a program written in high level language
to corresponding binary file/machine language is illustrated in the figure.

AAA D E P T . O F CSE AJIET

| AJIET
 INTRODUCTION TO EMBEDDED SYSTEMS | M O D U L E 4 :
Embedded Firmware Design and Development

 The program written in any of the high level languages is saved with the corresponding
language extension (.c for C, .cpp for C++ etc).
 Any text editor like ‘Notepad' or 'WordPad' from Microsoft or the text editor provided by
an Integrated Development (IDE) tool can be used for writing the program.
 Most of the high level languages support modular programming approach and hence we
can have multiple source files called modules written in corresponding high level language.
 The source files corresponding to each module is represented by a file with corresponding
language extension.
 Translation of high level source code to executable object code is done by across-compiler.
Each high level language should have a cross-compiler for converting the high level source
code into the target processor machine code.
 C51 Cross-compiler from Keil software is an example for Cross-compiler used for
'C' language for the 8051 family of microcontroller.
 Conversion of each module's source code to corresponding object file is performed by the
cross-compiler.
 Rest of the steps involved in the conversion of high level language to target processor's
machine code are same as that of the steps involved in assembly language based
development.

Advantages of High Level Language Based Development

 Reduced Development Time

 Developer requires less or little knowledge on the internal hardware details and
architecture of the target processor/controller.

AJIET | D E P T . O F CSE
 INTRODUCTION TO EMBEDDED SYSTEMS | MODULE 4:
Embedded Firmware Design and Development

 Bare minimal knowledge of the memory organisation and register details of the
target processor in use and syntax of the high level language are the only pre-
requisites for high level language based firmware development.
 With high level language, each task can be accomplished by lesser number of lines
of code compared to the target processor/controller specific assembly language
based development.
 Developer Independency
 The syntax used by most of the high level languages are universal and a program
written in the high level language can easily be understood by a second person
knowing the syntax of the language.
 High level languages always instruct certain set of rules for writing the code and
commenting the piece of code.
 If the developer strictly adheres to the rules, the firmware will be 100% developer
independent.
 Portability
 Target applications written in high level languages are converted to target
processor/controller understandable format (machine codes) by a cross-compiler.
 An application written in high level language for a particular target processor can
easily be converted to another target processor/controller specific application,
with little or less effort by simply re-compiling/little code modification followed
by recompiling the application for the required target processor/controller,
provided, the cross-compiler has support for the processor/controller selected.
 This makes applications written in high level language highly portable.
 Little effort may be required in the existing code to replace the target processor
specific files with new header files, register definitions with new ones, etc.
 This is the major flexibility offered by high level language based design.

Limitations of High Level Language Based Development

 Poor Optimization by Cross-Compilers

 Some cross-compilers available for high level languages may not be so efficient in
generating optimised target processor specific instructions.
 Target images created by such compilers may be messy and non-optimised in terms
of performance as well as code size.
 The time required to execute a task also increases with the number of instructions.
 Not Suitable for Low Level Hardware
 High level language based code snippets may not be efficient in accessing low level
hardware where hardware access timing is critical (of the order of nano or micro
seconds).
 High Investment Cost
 The investment required for high level language based development tools
(Integrated Development Environment incorporating cross-compiler) is high
compared to Assembly Language based firmware development tools.

AAA D E P T . O F CSE AJIET

| AJIET
 INTRODUCTION TO EMBEDDED SYSTEMS | M O D U L E 4 :
Embedded Firmware Design and Development

Mixing Assembly and High Level Language

 Certain embedded firmware development situations may demand the mixing of high level
language with Assembly and vice versa.
 High level language and assembly languages are usually mixed in three ways:
 Mixing Assembly Language with High Level Language
 Mixing High Level Language with Assembly Language
 Inline Assembly programming

Mixing Assembly Language with High Level Language

 Assembly routines are mixed with 'C' in situations where

 the entire program is written in 'C' and the cross compiler in use do not have a
built in support for implementing certain features like Interrupt Service Routine
functions (ISR) or
 if the programmer wants to take advantage of the speed and optimised code
offered by machine code generated by hand written assembly rather than cross
compiler generated machine code.
 When accessing certain low level hardware, the timing specifications may be very critical
and a cross compiler generated binary may not be able to offer the required time
specifications accurately.
 Writing the hardware/peripheral access routine in processor/controller specific
Assembly language and invoking it from 'C' is the most advised method to handle
such situations.
 Mixing 'C' and Assembly is little complicated.
 The programmer must be aware of how parameters are passed from the 'C' routine
to Assembly and values are returned from assembly routine to 'C' and how
'Assembly routine' is invoked from the 'C' code.
 Passing parameter to the assembly routine and returning values from the assembly routine
to the caller 'C' function and the method of invoking the assembly routine from 'C' code
is cross-compiler dependent.

Mixing High Level Language with Assembly Language

 Mixing the code written in a high level language like 'C' and Assembly language is useful
in the following scenarios:
 The source code is already available in Assembly language and a routine written in
a high level language like 'C' needs to be included to the existing code.
 The entire source code is planned in Assembly code for various reasons like
optimised code, optimal performance, efficient code memory utilisation and
proven expertise in handling the Assembly, etc. But some portions of the code may
be very difficult and tedious to code in Assembly. For example, 16-bit
multiplication and division in 8051 Assembly Language.
AJIET | D E P T . O F CSE
 INTRODUCTION TO EMBEDDED SYSTEMS | MODULE 4:
Embedded Firmware Design and Development

 To include built in library functions written in 'C' language provided by the cross
compiler. For example, Built in Graphics library functions and String operations
supported by 'C’.
 Most often the functions written in 'C' use parameter passing to the function and returns
value/s to the calling functions.
 Parameters are passed to the function and values are returned from the function using
CPU registers, stack memory and fixed memory.
 Its implementation is cross compiler dependent and it varies across cross compilers.

Inline Assembly Programming

 Inline assembly is a technique for inserting target processor/controller specific Assembly

instructions at any location of a source code written in high level language 'C’.
 This avoids the delay in calling an assembly routine from a 'C' code.
 Special keywords are used to indicate that the start and end of Assembly instructions.
 The keywords are cross-compiler specific.
 C51 uses the keywords #pragma asm and #pragma endasm to indicate a block of
code written in assembly.
Ex: Keil C51 cross compiler for 8051 controller
1. Write a simple function in C that passes parameters and returns values the way you want
your assembly routine to.
2. Use the SRC directive (#PRAGMA SRC at the top of the file) so that the C compiler
generates an .SRC file instead of an .OBJ fi le.
3. Compile the C file. Since the SRC directive is specified, the .SRC file is generated.
The .SRC file contains the assembly code generated for the C code you wrote.
4. Rename the .SRC file to .A51 file.
5. Edit the .A51 file and insert the assembly code you want to execute in the body of the
assembly function shell included in the .A51 file.
As an example consider the following sample code (Extracted from Keil C51 documentation)

AAA D E P T . O F CSE AJIET

| AJIET
 INTRODUCTION TO EMBEDDED SYSTEMS | M O D U L E 4 :
Embedded Firmware Design and Development

The special compiler directive SRC generates the Assembly code corresponding to the ‘C’ function
and each lines of the source code is converted to the corresponding Assembly instruction. You can
easily identify the Assembly code generated for each line of the source code since it is implicitly
mentioned in the generated .SRC file. By inspecting this code segments you can find out which
registers are used for holding the variables of the ‘C’ function and you can modify the source code
by adding the assembly routine you want.

AJIET | D E P T . O F CSE
 INTRODUCTION TO EMBEDDED SYSTEMS | MODULE 4:
Embedded Firmware Design and Development

The Embedded System Development Environment

Fig: The Embedded System Development Environment

 As illustrated in the fi gure, the development environment consists of a Development Computer
(PC) or Host, which acts as the heart of the development environment, Integrated Development
Environment (IDE) Tool for embedded firmware development and debugging, Electronic
Design Automation (EDA) Tool for Embedded Hardware design, An emulator hardware for
debugging the target board, Signal sources (like Function generator) for simulating the inputs to
the target board, Target hardware debugging tools (Digital CRO, Multimeter, Logic Analyser,
etc.) and the target hardware.
 The Integrated Development Environment (IDE) and Electronic Design Automation (EDA)
tools are selected based on the target hardware development requirement and they are supplied
as Installable files in CDs/Online downloads by vendors. These tools need to be installed on the
host PC used for development activities.
 These tools can be either freeware or licensed copy or evaluation versions. Licensed versions of
the tools are fully featured and fully functional whereas trial versions fall into two categories,
tools with limited features, and full featured copies with limited period of usage.

AAA D E P T . O F CSE AJIET

| AJIET
 INTRODUCTION TO EMBEDDED SYSTEMS | M O D U L E 4 :
Embedded Firmware Design and Development

THE INTEGRATED DEVELOPMENT ENVIRONMENT (IDE)

 In embedded system development context, Integrated Development Environment ( IDE) stands
for an integrated environment for developing and debugging the target processor specific
embedded firmware. IDE is a software package which bundles a ‘Text Editor (Source Code
Editor)’,‘Cross-compiler (for cross platform development and compiler for same platform
development)’, ‘Linker’ and a ‘Debugger’.

 Some IDEs may provide interface to target board emulators, Target processor’s/controller’s
Flash memory programmer, etc. and incorporate other software development utilities like
‘Version Control Tool’, ‘Help File for the Development Language’, etc. IDEs can be either
command line based or GUI based.

 IDEs used in embedded firmware development are slightly different from the generic IDEs used
for high level language based development for desktop applications. In Embedded Applications,
the IDE is either supplied by the target processor/controller manufacturer or by third party
vendors or as Open Source.

 MPLAB is an IDE tool supplied by microchip for developing embedded fi rmware using their
PIC family of microcontrollers.

The Keil μVision IDE for 8051

 Keil µVision5 is a licensed IDE tool from Keil Software (www.keil.com), an ARM company,
for 8051 family microcontroller based embedded firmware development.
 To start with the IDE (after installing the demo tool) execute the program Uv4.exe (or the short
cut ‘Keil µVision5’ from desktop or ‘All Programs’ tab from ‘Start Menu’ – For Host machine
with Microsoft® Windows Operating System).
Debugging with Keil μVision5 IDE
 Debugging firmware is the process of monitoring the program flow, various registers and
memory contents while the firmware is executed.
 You can debug the firmware in two methods. The first method is by using breakpoints and
simulator (a software tool which simulates the functionalities of the target processor). The
second method is hardware level debugging.
Simulating Peripherals and Interrupts with Keil μVision5 IDE
 Embedded systems are designed to interact with real world and the actions performed by them
may depend on the inputs from various sensors connected to the processor/controller of the
embedded system.
 By a mere software simulation of the firmware, we can only inspect the memory, register
contents, etc. of the processor and cannot infer anything on the real-time performance of the
system since the inputs provided by the sensors are real-time and dynamic.

TYPES OF FILES GENERATED ON CROSS-COMPILATION

 Cross-compilation is the process of converting a source code written in high level language (like
‘Embedded C’) to a target processor/ controller understandable machine code (e.g. ARM
processor or 8051 microcontroller specific machine code).
 The conversion of the code is done by software running on a processor/controller (e.g. x86
processor based PC) which is different from the target processor. The software performing this
operation is referred as the ‘Cross-compiler’.

AJIET | D E P T . O F CSE
 INTRODUCTION TO EMBEDDED SYSTEMS | MODULE 4:
Embedded Firmware Design and Development

 In a single word cross-compilation is the process of cross platform software/fi rmware

development. Cross assembling is similar to cross-compiling; the only difference is that the code
written in a target processor/controller specific
 Assembly code is converted into its corresponding machine code. The application converting
Assembly instruction to target processor/controller specific machine code is known as cross-
assembler.
 Cross-compilation/cross-assembling is carried out in different steps and the process generates
various types of intermediate files. Almost all compilers provide the option to select whatever
intermediate files needs to be retained after cross-compilation.
 The various files generated during the crosscompilation/cross-assembling process are:
List File (.lst), Hex File (.hex), Pre-processor Output file, Map File (File extension linker
dependent), Object File (.obj)

List File (.LST File)

 Listing file is generated during the cross-compilation process and it contains an abundance of
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 type of information contained in the list file is cross-compiler specific.

Preprocessor Output File

 The preprocessor output file generated during cross-compilation contains the preprocessor
output for the preprocessor instructions used in the source file.
 Preprocessor output file is used for verifying the operation of macros and conditional
preprocessor directives.
 The preprocessor output file is a valid C source file. File extension of preprocessor output file is
cross compiler dependent.

Object File (.OBJ File)

 Cross-compiling/assembling each source module (written in C/Assembly) converts the various

Embedded C/Assembly instructions and other directives present in the module to an object
(.OBJ) fi le.
 The format (internal representation) of the .OBJ file is cross compiler dependent
 The list of some of the details stored in an object file is given below.
1. Reserved memory for global variables.
2. Public symbol (variable and function) names.
3. External symbol (variable and function) references.
4. Library files with which to link.
5. Debugging information to help synchronise source lines with object code.

Map File (.MAP)

 The object files so created are re-locatable codes, meaning their location in the code memory is
not fixed. It is the responsibility of a linker to link all these object files.
 The locater is responsible for locating absolute address to each module in the code memory.
Linking and locating of re-locatable object files will also generate a list file called ‘linker list

AAA D E P T . O F CSE AJIET

| AJIET
 INTRODUCTION TO EMBEDDED SYSTEMS | M O D U L E 4 :
Embedded Firmware Design and Development

file’ or ‘map file’.

 Map file contains information about the link/locate process and is composed of a number of
sections.

HEX File (.HEX)

 Hex file is the binary executable file created from the source code. The absolute object file
created by the linker/locater is converted into processor understandable binary code.
 The utility used for converting an object file to a hex file is known as Object to Hex file
converter. Hex files embed the machine code in a particular format.
 The format of Hex file varies across the family of processors/controllers.
 Intel HEX and Motorola HEX are the two commonly used hex file formats in embedded
applications.

DISASSEMBLER/DECOMPILER

 Disassembler is a utility program which converts machine codes into target processor specifi c
Assembly codes/instructions. The process of converting machine codes into Assembly code is
known as ‘Disassembling’.
 In operation, disassembling is complementary to assembling/crossassembling.
 Decompiler is the utility program for translating machine codes into corresponding high level
language instructions.
 Decompiler performs the reverse operation of compiler/cross-compiler.
 The disassemblers/decompilers for different family of processors/controllers are different.
 Disassemblers/Decompilers are available as either freeware tools readily available for free
 download from internet or as commercial tools.
 It is not possible for a disassembler/decompiler to generate an exact replica of the original
assembly code/high level source code in terms of the symbolic constants and comments used.
However disassemblers/decompilers generate a source code which is somewhat matching to the
original source code from which the binary code is generated.

SIMULATORS, EMULATORS AND DEBUGGING

 Simulators and emulators are two important tools used in embedded system development. Both
the terms sound alike and are little confusing.
 Simulator is a software tool used for simulating the various conditions for checking the
functionality of the application firmware.
 The Integrated Development Environment (IDE) itself will be providing simulator support and
they help in debugging the firmware for checking its required functionality.
 In certain scenarios, simulator refers to a soft model (GUI model) of the embedded product
 Soft phone is an example for such a simulator. Emulator is hardware device which emulates the
functionalities of the target device and allows real time debugging of the embedded firmware in
a hardware environment.
 For example, if the product under development is a handheld device, to test the functionalities of
the various menu and user interfaces, a soft form model of the product with all UI as given in the
end product can be developed in software.

AJIET | D E P T . O F CSE
 INTRODUCTION TO EMBEDDED SYSTEMS | MODULE 4:
Embedded Firmware Design and Development

Simulators simulate the target hardware and the firmware execution can be inspected using
simulators.
The features of simulator based debugging are listed below.

1. Purely software based

2. Doesn’t require a real target system
3. Very primitive (Lack of featured I/O support. Everything is a simulated one)
4. Lack of Real-time behaviour

Advantages of Simulator Based Debugging

Simulator based debugging techniques are simple and straightforward. The major advantages of
simulator based firmware debugging techniques are explained below.
 No Need for Original Target Board- Simulator based debugging technique is purely software
oriented. IDE’s software support simulates the CPU of the target board. User only needs to
know about the memory map of various devices within the target board and the firmware should
be written on the basis of it. Since the real hardware is not required, firmware development can
start well in advance immediately after the device interface and memory maps are finalised. This
saves development time.
 Simulate I/O Peripherals-Simulator provides the option to simulate various I/O peripherals.
Using simulator’s I/O support you can edit the values for I/O registers and can be used as the
input/output value in the firmware execution. Hence it eliminates the need for connecting I/O
devices for debugging the firmware.
 Simulates Abnormal Conditions- With simulator’s simulation support you can input any
desired value for any parameter during debugging the firmware and can observe the control fl
ow of firmware. It really helps the developer in simulating abnormal operational environment
for firmware and helps the firmware developer to study the behaviour of the firmware under
abnormal input conditions.

Limitations of Simulator based Debugging

Though simulation based firmware debugging technique is very helpful in embedded applications,
they possess certain limitations and we cannot fully rely upon the simulator-based firmware
debugging. Some of the limitations of simulator-based debugging are explained below.
 Deviation from Real Behaviour- Simulation-based firmware debugging is always carried out
in a development environment where the developer may not be able to debug the firmware under
all possible combinations of input. Under certain operating conditions we may get some
particular result and it need not be the same when the firmware runs in a production
environment.
 Lack of Real Timeliness- The major limitation of simulator based debugging is that it is not
real-time in behaviour. The debugging is developer driven and it is no way capable of creating a
real time behaviour. Moreover in a real application the I/O condition may be varying or
unpredictable. Simulation goes for simulating those conditions for known values.

Emulators and Debuggers

 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 from various buses of the embedded hardware.
 Debugging process in embedded application is broadly classified into two, namely; hardware
debugging and firmware debugging.
 Hardware debugging deals with the monitoring of various bus signals and checking the status
lines of the target hardware.

AAA D E P T . O F CSE AJIET

| AJIET
 INTRODUCTION TO EMBEDDED SYSTEMS | M O D U L E 4 :
Embedded Firmware Design and Development

 Firmware debugging deals with examining the firmware execution, execution fl ow, changes to
various CPU registers and status registers on execution of the firmware to ensure that the
firmware is running as per the design.

Incremental EEPROM Burning Technique

 This is the most primitive type of firmware debugging technique where the code is separated
into different functional code units.
 Instead of burning the entire code into the EEPROM chip at once, the code is burned in
incremental order, where the code corresponding to all functionalities are separately coded,
cross-compiled and burned into the chip one by one.
 The code will incorporate some indication support like lighting up an “LED (every embedded
product contains at least one LED). If not, you should include provision for at least one LED in
the target board at the hardware design time such that it can be used for debugging purpose)” or
activate a “BUZZER (In a system with BUZZER support)” if the code is functioning in the
expected way.
 If the first functionality is found working perfectly on the target board with the corresponding
code burned into the EEPROM, go for burning the code corresponding to the next functionality
and check whether it is working.
 Repeat this process till all functionalities are covered. Please ensure that before entering into one
level up, the previous level has delivered a correct result. If the code corresponding to any
functionality is found not giving the expected result, fix it by modifying the code and then only
go for adding the next functionality for burning into the EEPROM.

Inline Breakpoint Based Firmware Debugging

 Inline breakpoint based debugging is another primitive method of firmware debugging. Within
the firmware where you want to ensure that firmware execution is reaching up to a specified
point, insert an inline debug code immediately after the point.
 The debug code is a printf() function which prints a string given as per the firmware. You can
insert debug codes (printf()) commands at each point where you want to ensure the firmware
execution is covering that point. Cross-compile the source code with the debug codes embedded
within it. Burn the corresponding hex file into the EEPROM.

Monitor Program Based Firmware Debugging

 Monitor program based firmware debugging is the first adopted invasive method for firmware
debugging. In this approach a monitor program which acts as a supervisor is developed.
 The monitor program controls the downloading of user code into the code memory, inspects
and modifies register/memory locations; allows single stepping of source code, etc. The monitor
program implements the debug functions as per a pre-defined command set from the debug
application interface.
 The monitor program always listens to the serial port of the target device and according to the
command received from the serial interface it performs command specific actions like firmware
downloading, memory inspection/modification, firmware single stepping and sends the debug
information (various register and memory contents) back to the main debug program running on
the development PC, etc.
 The first step in any monitor program development is determining a set of commands for
performing various operations like firmware downloading, memory/
register inspection/modification, single stepping, etc. Once the commands for each operation
is fixed, write the code for performing the actions corresponding to these commands.

AJIET | D E P T . O F CSE
 INTRODUCTION TO EMBEDDED SYSTEMS | MODULE 4:
Embedded Firmware Design and Development

Fig: Monitor Program Based Target Firmware Debug Setup

The monitor program contains the following set of minimal features.

1. Command set interface to establish communication with the debugging application
2. Firmware download option to code memory
3. Examine and modify processor registers and working memory (RAM)
4. Single step program execution
5. Set breakpoints in firmware execution
6. Send debug information to debug application running on host machine

The major drawbacks of monitor based debugging system are

1. The entire memory map is converted into a Von-Neumann model and it is shared between the
monitor ROM, monitor program data memory, monitor program trace buffer, user written fi rmware
and external user memory. For 8051, the original Harvard architecture supports 64K code memory
and 64K external data memory (Total 128K memory map). Going for a monitor based debugging
shrinks the total available memory to 64K Von-Neumann memory and it needs to accommodate all
kinds of memory requirement (Monitor Code, monitor data, trace buffer memory, User code and
External User data memory).
2. The communication link between the debug application running on Development PC and monitor
program residing in the target system is achieved through a serial link and usually the controller’s
Onchip UART is used for establishing this link. Hence one serial port of the target processor
becomes dedicated for the monitor application and it cannot be used for any other device interfacing.
Wastage of a serial port! It is a serious issue in controllers or processors with single UART.
In Circuit Emulator ( ICE) Based Firmware Debugging
 The terms ‘Simulator’ and ‘Emulator’ are little bit confusing and sounds similar. Though their
basic functionality is the same – “Debug the target firmware”, the way in which they achieve
this functionality is totally different.
 As mentioned before, ‘Simulator’ is a software application that precisely duplicates (mimics)
the target CPU and simulates the various features and instructions supported by the target CPU,
whereas an ‘Emulator’ is a self-contained hardware device which emulates the target CPU.
 The emulator hardware contains necessary emulation logic and it is hooked to the debugging
application running on the development PC on one end and connects to the target board through
some interface on the other end. In summary, the simulator ‘simulates’ the target board CPU and
the emulator ‘emulates’ the target board CPU.

AAA D E P T . O F CSE AJIET

| AJIET
 INTRODUCTION TO EMBEDDED SYSTEMS | M O D U L E 4 :
Embedded Firmware Design and Development

Fig:In Circuit Emulator (ICE) Based Target Debugging

 The Emulator POD forms the heart of any emulator system and it contains the following
functional units. Emulation Device Emulation device is a replica of the target CPU which
receives various signals from the target board through a device adaptor connected to the target
board and performs the execution of firmware under the control of debug commands from the
debug application.
 The emulation device can be either a standard chip same as the target processor (e.g. AT89C51)
or a Programmable Logic Device (PLD) configured to function as the target CPU. If a standard
chip is used as the emulation device, the emulation will provide real-time execution behaviour.
At the same time the emulator becomes dedicated to that particular device and cannot be re-used
for the derivatives of the same chip.
 PLD-based emulators can easily be re-configured to use with derivatives of the target CPU
under consideration. By simply loading the configuration fi le of the derivative
processor/controller, the PLD gets re-confi gured and it functions as the derivative device.
 A major drawback of PLD-based emulator is the accuracy of replication of target CPU
functionalities. PLD-based emulator logic is easy to implement for simple target CPUs but for
complex target CPUs it is quite diffi cult.
 Emulation Memory It is the Random Access Memory (RAM) incorporated in the Emulator
device. It acts as a replacement to the target board’s EEPROM where the code is supposed to be
downloaded after each firmware modification. Hence the original EEPROM memory is
emulated by the RAM of emulator. This is known as ‘ROM Emulation’.
 ROM emulation eliminates the hassles of ROM burning and it offers the benefit of infinite
number of reprogrammings (Most of the EEPROM chips available in the market supports only
a few 1000 re-program cycles).
 Emulation memory also acts as a trace buffer in debugging. Trace buffer is a memory pool
holding the instructions executed/registers modified/related data by the processor while
debugging.
The common features of trace buffer memory and trace buffer data viewing are
listed below:
∑ Trace buffer records each bus cycle in frames
∑ Trace data can be viewed in the debugger application as Assembly/Source code
∑ Trace buffering can be done on the basis of a Trace trigger (Event)
∑ Trace buffer can also record signals from target board other than CPU signals (Emulator
dependent)
∑ Trace data is a very useful information in firmware debugging

AJIET | D E P T . O F CSE
 INTRODUCTION TO EMBEDDED SYSTEMS | MODULE 4:
Embedded Firmware Design and Development

Emulator Control Logic Emulator control logic is the logic circuits used for implementing
complex hardware breakpoints, trace buffer trigger detection, trace buffer control, etc. Emulator
control logic circuits are also used for implementing logic analyser functions in advanced emulator
devices. The ‘Emulator POD’ is connected to the target board through a ‘Device adaptor’ and signal
cable.
Device Adaptors Device adaptors act as an interface between the target board and emulator POD.
Device adaptors are normally pin-to-pin compatible sockets which can be inserted/plugged into the
target board for routing the various signals from the pins assigned for the target processor. The
device adaptor is usually connected to the emulator POD using ribbon cables. The adaptor type
varies depending on the target processor’s chip package. DIP, PLCC, etc. are some commonly used
adaptors.

On Chip Firmware Debugging (OCD)

 Advances in semiconductor technology has brought out new dimensions to target firmware
debugging. Today almost all processors/controllers incorporate built in debug modules called
On Chip Debug ( OCD) support.
 Though OCD adds silicon complexity and cost factor, from a developer perspective it is a very
good feature supporting fast and efficient firmware debugging.
 The On Chip Debug facilities integrated to the processor/ controller are chip vendor dependent
and most of them are proprietary technologies like Background Debug Mode (BDM), OnCE, etc.
Chips with JTAG debug interface contain a built-in JTAG port for communicating with the remote
debugger application. JTAG is the acronym for Joint Test Action Group. JTAG is the alternate name
for IEEE 1149.1 standard. Like BDM, JTAG is also a serial interface.

The signal lines of JTAG protocol are explained below.

 Test Data In (TDI): It is used for sending debug commands serially from remote debugger to the
target processor.
 Test Data Out (TDO): Transmit debug response to the remote debugger from target CPU.
 Test Clock (TCK): Synchronises the serial data transfer.
 Test Mode Select (TMS): Sets the mode of testing.
 Test Reset (TRST): It is an optional signal line used for resetting the target CPU

AAA D E P T . O F CSE AJIET

| AJIET