Module-5: Embedded System Components and

Embedded Environment
Embedded System Components(Part A): Embedded Vs General
computing system, History of embedded systems, Classification of
Embedded systems, Major applications areas of embedded systems,
purpose of embedded systems. Core of an Embedded System
including all types of processor/controller, Memory.
Chapter 01 & 02 from Textbook 02
Embedded system Development Environment – Block diagram
(excluding Keil), Disassembler/decompiler, simulator, emulator and
debugging techniques, target hardware debugging, boundary scan
Chapter 13 from Text book 02(Shibu K V, “Introduction to Embedded Systems”)

1
Embedded System
Components(Part A):

2
Introduction

• Our day-to-day life is becoming-more and more dependent on

“embedded systems” and digital techniques.
• Home appliances,
• Vehicles,
• Industry control systems, etc.,
• Embedded technologies are bonding into our daily activities even
without our knowledge.

3
Introduction

• People experience the power of embedded systems and enjoy the

features and comfort provided by them.

• Embedded systems are like reliable servants

4
What is an Embedded
System?

5
 Embedded system

• An embedded system is a small computer that's part of a

larger mechanical or electrical system, performing a
“specific task.”

• Embedded systems can be independent or part of a

larger system and can range in complexity from a single
microcontroller to a network of processors.

6
 What is an Embedded System?

• An embedded system is an electronic/electro-mechanical

system designed to perform a specific function.
• Every embedded system is unique and the hardware as well
as the firmware is highly specialised to the application
domain.
• It is a combination of both hardware and firmware.
• It is a type of software, specifically low-level code embedded in
hardware,
• Which controls the device's basic functions.
7
 Embedded Systems vs. General Computing Systems
• The computing revolution began with the general-purpose computing
requirements.
• Later it was realised that the general computing requirements are not
sufficient for the embedded computing requirements.
• The embedded computing requirements demand ‘something
special’ in terms of response to
• stimuli/provocations,
• meeting the computational deadlines,
• power efficiency,
• limited memory capability, etc.
8
General Purpose Computing System Embedded System
• A system which is a combination • A system which is a combination
of a generic hardware and a of special purpose hardware and
General-Purpose Operating embedded OS for executing a
System for executing a variety of specific set of applications
applications

• Contains a General-Purpose • May or may not contain an

Operating System (GPOS) operating system for
functioning

9
General Purpose Computing Embedded System
System
• Applications are alterable • The firmware of the embedded
(programmable) by the user system is pre-programmed, and it is
• i.e., the end user can re-install non-alterable by the end-user (There
the operating system, and also may be exceptions for system
add or remove user supporting OS kernel image flashing
applications through special hardware settings)
• Performance is the key deciding • Application-specific requirements
factor in the selection of the (like performance, power
system. Always, ‘Faster is Better’ requirements, memory usage, etc.)
are the key deciding factors

10
General Purpose Computing System Embedded System
• Less tailored or not tailored • Highly tailored to take advantage
towards reduced operating of the power saving modes
power requirements, options for supported by the hardware and
different levels of power the operating system
management(Monolithic)
• Response requirements are not • For certain category of embedded
time-critical systems like mission critical
systems, the response time
requirement is highly critical.
• Need not be deterministic in • Execution behaviour is deterministic
execution behaviour for certain types of embedded
systems like ‘Hard Real Time’ systems
11
History of Embedded Systems
• Embedded systems were in existence even before the IT revolution.
• Built around the old vacuum tube and transistor technologies.
• Advances in semiconductor and nanotechnology and IT
revolution gave way to the development of miniature/tiny
embedded systems.
• The first recognised modern embedded system is the Apollo
Guidance Computer (AGC) developed by the MIT Instrumentation
Laboratory for the lunar project/expedition carried out by a team..
• It was designed to provide guidance, navigation, and control for the
Apollo spacecraft
12
History of Embedded Systems
• AGC Specification:
• It had 36K words of fixed memory(ROM-72 KB) and 2K words of
erasable memory.(RAM- 332kb)
• The clock frequency of was 1.024 MHz and it was derived from a
2.048 MHz crystal clock.
• The first mass-produced embedded system was the Autonetics D-17
guidance computer for the Minuteman-I missile in 1961.
• It was built using discrete transistor logic and a hard-disk for main
memory.
• The first integrated circuit was produced in September 1958 and
computers using them began to appear in 1963.
13
Classification of Embedded Systems

• There are 4 criteria used in the classification of

embedded systems are:
1. Based on generation
2. Complexity and performance requirements
3. Based on deterministic behaviour
4. Based on triggering

14
1. Classification Based on Generation
• First Generation - 1960
• Second Generation - 1970
• Third Generation - 1980
• Fourth Generation - 1990
• Next Generation

15
Classification Based on Generation
(continued)
• First Generation (1970-1990)
• Early embedded systems were built around 8-bit microprocessors
like 8085 and Z80 and 4-bit microcontrollers.
• Simple in hardware circuits with firmware developed in assembly
code.
• These systems used individual components like transistors and
resistors.

16
Classification Based on Generation (continued)
• First Generation examples:
• Digital telephone keypads, stepper motor control units, etc.
• D-17B computer, developed by Autonetics in 1965 for the
Minuteman I missile guidance system.
• The first modern, real-time embedded computing system 1960:
• The Apollo Guidance Computer (AGC), developed in the 1960s at
MIT for the Apollo Program.
17
 Classification Based on Generation (continued)
• Second Generation (1970s)
• Embedded systems built around 16-bit microprocessors and 8-bit
or 16-bit microcontrollers.
• Instruction set were much more complex and powerful than the
first generation.
• It was powerful and sophisticated systems than the first
generation.
• Some of the second-generation embedded systems contained
embedded operating systems for their operation.
• E.g.: Data acquisition systems, SCADA systems(Supervisory Control And Data
Acquisition, etc.
18
Classification Based on Generation (continued)
• Third Generation 1980s
• Embedded systems built around 32-bit microprocessors and
16-bit microcontrollers.
• Application and domain specific processors/controllers
• Such as Digital Signal Processors (DSP) and Application
Specific Integrated Circuits (ASICs) came into picture.
• The instruction set of processors became more complex(CISC)
and powerful and the concept of instruction pipelining also
evolved.
19
Classification Based on Generation (continued)

• Third Generation 1980s

• Dedicated embedded real time and general-purpose operating
systems entered into the embedded market.

• Embedded systems spread its ground to areas

• Such as robotics, media, industrial process control,

networking, etc.

20
Classification Based on Generation (continued)
• Fourth Generation 1990s
• The advent of System on Chips (SoC), reconfigurable processors
and multicore processors are bringing these features
• High performance,
• Tight integration and
• Miniaturization into the embedded device market.
• The SoC technique implements a total system on a chip by
implementing different functionalities with a processor core on
an integrated circuit.

21
Classification Based on Generation (continued)

• Fourth Generation 1990s

• Modern advancements in microprocessors and
microcontrollers, along with new concepts.
• Such as System-on-Chip (SoC), reconfigurable, multicore
processors, and coprocessors, have significantly improved
the performance of embedded systems.
• These systems often use high-performance real-time
operating systems for their operation.
• E.g.: Smart phone devices, Mobile Internet Devices (MIDs), etc.

22
Classification Based on Generation
(continued)
• Next Generation(present technology)
• The processor and embedded market is highly dynamic
and demanding.
• The next generation embedded systems are expected to
meet growing demands in the market.
• Communication with server on the cloud computing

23
Demands in the market
• Security:
• Hardware-level encryption and multi-factor authentication to
protect data and systems from breaches
• AI and Machine Learning:
• Integration of AI and Machine Learning (ML) for predictive
maintenance, data analysis, and real-time decision-making
• Edge computing:
• Network connectivity for new functions related to control,
device status, and data
• Sustainability:
• Energy-efficient designs and power optimization to align with
the global emphasis on environmentally conscious technology
solutions (green computing)
24
2. Classification Based on Complexity and Performance

• These systems can range from simple to highly sophisticated designs,

depending on their memory, processing power, and applications.
• The three main categories of embedded systems based on complexity
include:

• Small-Scale Embedded Systems

• Medium-Scale Embedded Systems

• Large-Scale Embedded Systems

25
Classification Based on Complexity and Performance
(continued)
• Small-Scale Embedded Systems
• These systems use either a single 8 or 16-bit microprocessor or
controller.
• They have limited memory and processing power.
• They also have relatively lower hardware and software
complexities.
• They may or may not contain an operating system for their
functioning.
• Usually built around low performance and low cost 8-bit or 16-bit
microprocessors/microcontrollers.

26
Classification Based on Complexity and Performance
(continued)
• Small-Scale Embedded Systems
• They are majorly found in gadgets like electronic toys, smartcards,
etc.
• The main programming tools used for these systems include an
editor, cross assembler, and integrated development environment
(IDE).
• Simple in application needs and the performance requirements
are not time critical.
• E.g.: An electronic toy, smart cards, simple home appliances, etc.,

27
Classification Based on Complexity and Performance
• Medium-Scale Embedded Systems
• These come with 16-bit or 32-bit microprocessors or
controllers, ASICs (Application Specific Integrated Circuit), or
DSPs.
• Also, they have a fair amount of memory and processing
power.
• These systems have complexities in both hardware and
software and run on a real-time operating system (RTOS).
• They are often employed in home appliances, medical devices,
and automotive systems.
• The main programming tools used for these systems include C, C++, JAVA, Visual C++, RTOS, etc.

28
Classification Based on Complexity and Performance
• Medium-Scale Embedded Systems
• Slightly complex in hardware and firmware (software)
requirements.

• Usually built around medium performance, low cost 16-bit or 32-bit

microprocessors/microcontrollers or digital signal processors.

• Usually contain an embedded operating system (either general

purpose or real time operating system) for functioning.

29
 Based on Complexity and Performance (continued)
• Large-Scale Embedded Systems
• These systems have highly complex hardware and software, like ones
built on 32-bit or 64-bit RISC processors,
• System-on-Chip (SoC), processors/controllers, and scalable and
configurable processors.
• A high-performance real-time OS is usually required for task
scheduling, prioritization, and management.
• They are used in innovative applications that demand hardware and
software design.
• Such as aerospace technologies, industrial automation, and wireless
communication systems.
30
Classification Based on Complexity and
Performance (continued)
• Highly complex in hardware and firmware (software) requirements.
• They are employed in mission critical applications
demanding high performance.
• Decoding/encoding of media, cryptographic function
implementation, etc. are examples of processing requirements
which can be implemented using a co-processor/hardware
accelerator.

31
3. Classification Based on Deterministic Behaviour

• Applicable for ‘Real Time’ systems. The application/task execution

behaviour can be either deterministic or non-deterministic.

• Based on the execution behaviour, real time embedded systems are

classified into

• Hard Real Time systems

• Soft Real Time systems.
32
 Classification Based on Deterministic Behaviour

Soft Real-Time Systems

• These systems do not enforce strict timing constraints for task
deadlines.
• While they still require a response time to specific events, missing
a deadline is acceptable.
• Examples include ATMs and multimedia systems.
• In these cases, a late answer is still an acceptable answer.

33
Classification Based on Deterministic Behaviour

Hard Real-Time Systems

• These systems demand strict adherence to their timing
constraints, as failing to meet the required response time can
result in severe consequences or system failure.
• So, for these systems, a late answer is always considered a wrong
answer.
• Examples are airbag control systems and antilock braking systems
in vehicles, Military systems, etc.,

34
4. Classification Based on Triggering

• Embedded systems which are ‘Reactive’ in nature (like process

control systems in industrial control applications) can be classified
based on the trigger.
• These systems are of the following two types:

• Event-triggered systems

• Time-triggered systems

35
Classification Based on Triggering
Event-triggered systems
• These systems rely on specific external events or activities to
initiate tasks.
• They respond to changes in variables
• Such as temperature, pressure, or user inputs, making them
more adaptive to their environment.
• They are particularly suited for applications requiring
immediate responses or real-time reactions, such as intrusion
detection systems, medical device monitoring, etc.
36
Classification Based on Triggering
Time-triggered systems
• These systems are activated or initiated at pre-determined
intervals or at a specific point in time.
• In these systems, the tasks are scheduled to be executed based
on a predefined time or periodic timer, which ensures the
timely and consistent execution of processes.
• They are used for data collection, industrial systems with
routine control loops, and scheduled car maintenance systems.

37
Major Application Areas of Embedded Systems

1. Consumer electronics: Camcorders, cameras, etc.

2. Household appliances: Television, DVD players, washing machine,
refrigerators, microwave oven, etc.
3. Home automation and security systems: Air conditioners,
sprinklers, intruder detection alarms, closed circuit television
(CCTV) cameras, fire alarms, etc.
4. Automotive industry: Anti-lock braking systems (ABS), engine
control, ignition systems, automatic navigation systems, etc.
5. Telecom: Cellular telephones, telephone switches, handset
multimedia applications, etc.

38
Major Application Areas of Embedded Systems
(continued)
6. Computer peripherals: Printers, scanners, fax machines, etc.
7. Computer networking systems: Network routers, switches, hubs,
firewalls, etc.
8. Healthcare: Different kinds of scanners, EEG, ECG machines, etc.
9. Measurements & Instrumentation: Digital multimeters, digital
CROs, logic analyzers, PLC systems, etc.
10. Banking & Retail: Automated teller machines (ATM) and currency
counters, point of sales (POS), etc.
11. Card readers: Barcode, smart card readers, hand held devices, etc.

39
Purpose of Embedded Systems

• Each embedded system is designed to serve the purpose of any one

or a combination of the following tasks:
1. Data Collection/Storage/Representation
2. Data Communication
3. Data (Signal) Processing
4. Monitoring
5. Control
6. Application Specific User Interface

40
 Purpose of Embedded Systems (continued)
1. Data Collection/Storage/Representation
• Embedded systems designed for the purpose of data collection
performs acquisition of data from the external world.
• Data collection is usually done for storage, analysis,
manipulation and transmission.
• The term "data" refers all kinds of information, viz. text, voice, image,
video, electrical signals and any other measurable quantities.
• Data can be either analog (continuous) or digital (discrete).
• The collected data may be stored or transmitted, or it may be
processed, or it may be deleted instantly after giving a meaningful
representation.
41
Purpose of Embedded Systems (continued)

• A digital camera is a typical example of an

embedded system with data
collection/storage/representation of data.
• Images are captured and the captured
image may be stored within the memory
of the camera.
• The captured image can also be
presented to the user through a graphic
LCD unit.

42
 Purpose of Embedded Systems (continued)
2. Data Communication
• Embedded data communication systems are deployed in
applications ranging from complex satellite communication systems
to simple home networking systems(IoT).
• The transmission is achieved either by a wire- line medium or by a
wireless medium.
• The data collecting embedded terminal itself can incorporate data
communication units like
• wireless modules (Bluetooth, ZigBee, Wi-Fi, EDGE, GPRS,
etc.) or
• wire-line modules (RS- 232C, USB, TCP/IP, PS2, etc.).
43
 Purpose of Embedded Systems (continued)

• Network hubs, routers, switches, etc.

are typical examples of dedicated data
transmission embedded systems.
• They act as mediators in data Fig: A wireless network router for
data communication
communication and provide various
features like data security, monitoring
etc.

44
Purpose of Embedded Systems (continued)

3. Data (Signal) Processing

• The data (voice, image, video, electrical signals and other
measurable quantities) collected by embedded systems may be
used for various kinds of data processing.
• Embedded systems with signal processing functionalities are
employed in applications demanding signal processing like
speech coding, synthesis, audio video codec, transmission
applications, etc.

45
Purpose of Embedded Systems (continued)

• A digital hearing aid is a typical

example of an embedded system
employing data processing.
• Digital hearing aid improves the
hearing capacity of hearing-impaired
persons.
• Translators i.e., voice-text or text-
voice

46
 Purpose of Embedded Systems (continued)

4. Monitoring
• Almost embedded products coming under the medical domain
are used for monitoring.
• A very good example is the Electro Cardio Gram (ECG) machine
for monitoring the heartbeat of a patient.
• The machine is intended to do the monitoring of the
heartbeat.
• It cannot impose control over the heartbeat.
• The sensors used in ECG are the different electrodes
connected to the patient's body.
47
 Purpose of Embedded Systems
(continued)

• Some other examples of embedded systems

with monitoring function are measuring
instruments like digital CRO, digital
multimeters, logic analyzers, etc.
• Used in Control & Instrumentation
applications.
Fig: A patient monitoring system
for monitoring heartbeat

48
Purpose of Embedded Systems (continued)
5. Control
• Embedded systems with control functionalities impose control
over some variables according to the changes in input variables.
• A system with control functionality contains both sensors and
actuators.
• Sensors are connected to the input port for capturing the
changes in environmental variable or measuring variable.
• The actuators connected to the output port are controlled
according to the changes in input variable to put an impact on
the controlling variable to bring the controlled variable to the
specified range.
49
Purpose of Embedded Systems (continued)

• An Air Conditioner System used to control

the room temperature to a specified limit is
a typical example for embedded system for
control purpose.
• An air conditioner contains a room
temperature-sensing element (sensor)
which may be a thermistor and a handheld
unit for setting up (feeding) the desired
temperature.

50
 Purpose of Embedded Systems (continued)
6. Application Specific User Interface
• These are embedded systems with
application-specific user interfaces like
buttons, switches, keypad, lights, bells, display
units, etc.
• Cell phone is an example for this.
• Example: A cell phone with an application-
specific user interfaces
• In mobile phone the user interface is provided A cell phone
through the keypad, graphic LCD module,
system speaker, vibration alert, etc.

51
A Typical Embedded System

Fig: Elements of an Embedded System

52
➢A typical embedded system (Fig. 2.1) contains a single chip controller ,
it can be
✓ Microprocessor' (e.g. Intel 8085)
✓ Microcontroller (e.g. Atmel AT89C51)
✓ Field Programmable Gate Array (FPGA) device (e.g. Xilinx Spartan)
✓ Digital Signal Processor (DSP)
(e.g. Blackfin® Processors from Analog Devices)
✓ Application Specific Integrated Circuits
(e.g. ADE7760 Single Phase Energy Metering IC)
• An embedded system can be viewed as a Reactive system.
• The control is achieved by processing the information coming
from the sensors and user interfaces and controlling some
actuators that regulate the physical variable.

• Keyboards, push button switches, etc. are examples for common

user interface input devices

• Where as LEDs, liquid crystal displays, electric buzzers, etc. are

examples for common user interface output devices for a typical
embedded system.
• The Memory of the system is responsible for holding the
control algorithm and other important configuration
details.
• The most common types of memories used in embedded
systems for control algorithm storage are ROM, PROM,
UVEPROM, EEPROM and FLASH.
• Depending on the control application, the memory size may
vary from a few bytes to megabytes.
• Random Access Memory (RAM) is used in most of the
systems as the working memory.
• Various types of RAM like SRAM, DRAM and NVRAM are used
for this purpose.
• The size of the RAM also varies from a few bytes to kilobytes
or megabytes depending on the application.
 Core of the Embedded System
• Embedded systems are domain and application specific and are built
around a central core.
• The core of the embedded system falls into any one of the
following categories:
1. General Purpose and Domain Specific Processors
a) Microprocessors
b) Microcontrollers
c) Digital Signal Processors
2. Application Specific Integrated Circuits (ASICs)
3. Programmable Logic Devices (PLDs)
4. Commercial off-the-shelf Components (COTS)
57
 1. General Purpose and Domain Specific Processors
• Almost 80% of the embedded systems are processor/controller based.
• The processor may be a microprocessor or a microcontroller or a digital
signal processor, depending on the domain and application.
• Most of the embedded systems in the industrial control and
monitoring applications make use of the commonly available
microprocessors or microcontrollers.
• Domains which require signal processing such as speech coding,
speech recognition, etc. make use of special kind of digital signal
processors.
58
a) Microprocessors
• A Microprocessor is a silicon chip representing a central processing
unit (CPU), which can perform arithmetic as well as logical
operations according to a pre-defined set of instructions.
• In general, the CPU contains the Arithmetic and Logic Unit (ALU),
control unit and working registers.
• A microprocessor is a dependent unit, and it requires the
combination of other hardware like memory, timer unit, and
interrupt controller, etc. for proper functioning.
• Intel, AMD, Freescale, IBM, TI, Cyrix, Hitachi, NEC, LSI Logic, etc.
are the key players in the processor market.
59
 General Purpose Processor (GPP) vs. Application-
Specific Instruction Set Processor (ASIP)
General Purpose Processor (GPP)
• A GPP is a processor designed for general computational tasks.
• The processor running inside laptop or desktop is a typical
example for general purpose processor.
• Due to the high-volume production, the per unit cost for a chip is
low.
• A typical general-purpose processor contains an Arithmetic and
Logic Unit (ALU) and Control Unit (CU).

60
General Purpose Processor (GPP) vs. Application-
Specific Instruction Set Processor (ASIP)
Application-Specific Instruction Set Processor (ASIP)
• ASIPs are processors with architecture and instruction set optimised to specific-
domain/application requirements (network processing, automotive, telecom, media
applications, digital signal processing, control applications, etc.
• Most of the embedded systems are built around application specific instruction
set processors.
• Some microcontrollers (like automotive AVR, USB AVR from Atmel), system on
chips, digital signal processors, etc. are examples for application specific
instruction set processors (ASIPs).
• ASIPs incorporate a processor and on-chip peripherals, demanded by the application
requirement, program and data memory.
61
 b). Microcontrollers
• A Microcontroller is an integrated chip that contains a CPU, scratch pad
RAM, special and general-purpose register arrays, on chip ROM/FLASH
memory for program storage, timer and interrupt control units and
dedicated I/O ports.
• A microcontroller contains all the necessary functional blocks for
independent working.
• Having greater place in embedded domain in place of microprocessors.
• They are cheap, cost effective and are readily available in the market.
• Ex: Atmel, Texas Instruments, Toshiba, Philips, Freescale, NEC, Zilog, Hitachi, Mitsubishi,
Infineon, ST Micro Electronics, National, Microchip, Analog Devices, Daewoo, Intel,
Maxim, Sharp, Silicon Laboratories, TDK, Triscend, Winbond, etc. are the key players in
the microcontroller market.
62
c). Digital Signal Processors – domain specific
• Digital Signal Processors (DSPs) are powerful special purpose
8/16/32 bit microprocessors
• Designed specifically to meet the computational demands and power
constraints of today's embedded audio, video, and communications
applications.
• Digital signal processors are 2 to 3 times faster than the general-
purpose microprocessors in signal processing applications.
• This is because of the architectural difference between the two.
• DSPs implement algorithms in hardware which speeds up the execution
whereas general purpose processors implement the algorithm in
firmware
63
c). Digital Signal Processors

• Audio video signal processing, telecommunication and

multimedia applications are typical examples where DSP is
employed.
• Digital signal processing employs a large amount of real-time
calculations.
• Sum of products (SOP) calculation, convolution, fast fourier
transform (FFT), discrete fourier transform (DFT), etc, are some
of the operations performed by digital signal processors.

64
 DSP

• In general, DSP can be viewed as a microchip designed for

performing high speed computational operations for ‘addition’,
‘subtraction’, ‘multiplication’ and ‘division’.
• A typical digital signal processor incorporates the following key
units:
• Program Memory: Memory for storing the program required by DSP
to process the data
• Data Memory: Working memory for storing temporary variables and
data/signal to be processed.
• Computational Engine: Performs the signal processing in accordance
with the stored program memory.
65
 DSP

• Computational Engine incorporates many specialized arithmetic

units and each of them operates simultaneously to increase the
execution speed.
• It also incorporates multiple hardware shifters for shifting
operands and thereby saves execution time.
• I/O Unit Acts as an interface between the outside world and
DSP.
• It is responsible for capturing signals to be processed and
delivering the processed signals

66
 RISC vs. CISC Processors/Controllers

• The term RISC stands for Reduced Instruction Set Computing.

• As the name implies, all RISC processors/controllers possess lesser
number of instructions, typically in the range of 30 to 40.
• CISC stands for Complex Instruction Set Computing.
• From the definition itself the instruction set is complex, and
instructions are high in number.
• From a programmer's point of view RISC processors are
comfortable since we need to learn only a few instructions,
• Whereas for a CISC processor we need to learn a greater number
of instructions.
67
 RISC vs. CISC Processors/Controllers

• Atmel, AVR microcontroller is an example for a RISC processor

and its instruction set contains only 32 instructions.
• The original version of 8051 microcontroller (e.g. AT89C51) is a
CISC controller and its instruction set contains 255 instructions.
• Remember it is not the number of instructions that determines
whether a processor/controller is CISC or RISC.
• There are some other factors like pipelining features, instruction
set type, etc. for determining the RISC/CISC

68
 RISC CISC
• Lesser Number of instructions • Greater number of Instructions
• Instruction pipelining and increased • Generally no instruction pipelining feature
execution speed
• Orthogonal instruction set (Allows each • Non-orthogonal instruction-set (All instructions are not allowed to
instruction to operate on any register and operate on any register and use any addressing mode. It is
use any addressing mode) instruction-specific)

• Operations are performed on registers only, • Operations are .'performed on registers or memory depending on the
the only memory operations are load and instruction
store
• A large number of registers are available • Limited number of general purpose registers
• Programmer needs to write more code to • Instructions are like macros in C language. A programmer .can
execute a task since the instructions are achieve the desired functionality with a single instruction which in
simpler ones turn provides the effect of using more simpler single instructions in
RISC

• Single, fixed length instructions • Variable length instructions

• Less silicon usage and pin count • More silicon usage since more additional decoder logic is required to
implement the complex instruction decoding.
• With Harvard Architecture • Can be Harvard or Von-Neumann Architecture 69
Load Store Operation and Instruction Pipelining

• We know that the RISC processor instruction set is orthogonal,

meaning it operates on registers.
• The memory access related operations are perforated by the
special instructions load and store.
• If the operand is specified as memory location, the content of it is
loaded to a register using the load instruction.
• The store instruction stores data from a specified register to a
specified memory location.
• The concept of Load Store Architecture illustrated with the
following example

70
The concept of Load Store Architecture

71
• Suppose x, y and z are memory locations and we want to add the
contents of x and y and store the result in location z.
• Under the load store architecture, the same is achieved with 4
instructions
• The first instruction load Rl, x loads the register R1 with the
content of memory location x,
• the second instruction load R2,y loads the register R2 with the
content of memory location y.
• The instruction add R3, Rl, R2 adds the content of registers Rl
and R2 and stores the result in register R3.
• The next instruction store R3,z stores the content of register R3
in memory location z.

72
• The conventional instruction execution by the processor follows
the fetch-decode-execute sequence.
• Where the ‘fetch’ part fetches the instruction from program
memory or code memory.
• The decode part decodes the instruction to generate the
necessary control signals.
• The execute stage reads the operands, perform ALU operations
and stores the result.
• In conventional program execution, the fetch and decode
operations are performed in sequence.

73
• For simplicity let’s consider decode and execution together.
• During the decode operation the memory address bus is available
and if it is possible to effectively utilize it for an instruction fetch,
the processing speed can be increased.
• In its simplest form instruction pipelining refers to the
overlapped execution of instructions.
• Depending on the stages involved in an instruction (fetch, read
register and decode, execute instruction, access an operand in
data memory, write back the result to register, etc.), there can be
multiple levels of instruction pipelining.

74
The three-stage pipelining concept

75
4. Programmable Logic Devices

• Logic devices provide specific functions, including device-to-

device interfacing, data communication, signal processing, data
display, timing and control operations, and almost every other
function a system must perform.
• Logic devices can be classified into two broad categories—
• Fixed and Programmable.
• The circuits in a fixed logic device are permanent, they perform
one function or set of functions—once manufactured, they cannot
be changed.
76
4. Programmable Logic Devices

• Programmable Logic Devices (PLDs) offer customers a wide range

of logic capacity, features, speed, and voltage characteristics and
these devices can be re-configured to perform any number of
functions at any time.
• Designers use software tools to quickly develop, simulate,
and test their designs.
• Then, a design can be quickly programmed into a device, and
immediately tested in a live circuit with suitable tools.

77
Programmable Logic Devices (continued)
• There are no NRE costs (Non-Recurring Engineering costs are
one-time costs that are incurred during the pre-production
phase of a new product or product enhancement.)
• They include the costs of research, design, development,
testing, and other functions required to create the product.
• The final design is completed much faster than that of a
custom, fixed logic device.

78
Programmable Logic Devices (continued)

• Another key benefit of using PLDs is that during the design

phase customers can change the circuitry as often as they
want until the design operates to their satisfaction.
• PLDs are based on re-writable memory technology to
change the design, the device is simply reprogrammed.
• The two major types of programmable logic devices are Field
Programmable Gate Arrays (FPGAs) and Complex
Programmable Logic Devices (CPLDs).

79
5.Commercial Off-the-Shelf Components (COTS)

• A Commercial Off-the-Shelf (COTS) product is one which is

used 'as-is’. (reusability)
• COTS products are designed in such a way to provide easy
integration and interoperability with existing system
components.
• The COTS component itself may be developed around a
general purpose or domain specific processor or an
Application Specific Integrated Circuit or a Programmable
Logic Device.

80
5.Commercial Off-the-Shelf Components (COTS)

• Advantages:
• They are readily available in the market
• Cheap means less expensive
• Developer can cut down his development time to a
great extent
• Reduces the time to market

81
Commercial Off-the-Shelf Components (COTS)
(continued)

• Typical examples of COTS hardware unit are remote

controlled toy car control units including
• The RF circuitry part,
• High performance,
• High frequency microwave electronics (2—200 ghz),
• High bandwidth analog-to-digital converters, devices and
• Components for operation at very high temperatures,
electro-optic IR imaging arrays, UV/IR detectors, etc.

82
 Commercial Off-the-Shelf Components (COTS)
(continued)

• E.g.: The TCP/IP plug-in module available

from various manufactures like 'WIZnet',
'Freescale', 'Dynalog', etc.

Fig: An example of a COTS product for TCP/IP

plug-in from WIZnet (WIZnet NM7010A Plug
in Module)

83
 Memory
• Memory is an important part of a Microprocessor/
Microcontroller based embedded systems.
• On-chip and off-chip memory
• If the processors/controllers contain built in memory and this
memory is referred as on-chip memory.
• Others do not contain any memory inside the chip and requires
external memory to be connected with the controller/processor to
store the control algorithm. It is called off-chip memory.
• Also, some working memory is required for holding data temporarily
during certain operations.
84
 Types of memory used in embedded system
applications

A. Program Storage Memory (ROM)

B. Read-Write Memory/Random Access Memory (RAM)
C. Memory According to the Type of Interface

85
A. Program Storage Memory (ROM):
• The program memory or code storage memory of an
embedded system stores the program instructions. The code
memory retains its contents even after the power is turned off. It
is generally known as non-volatile storage memory.
1. Masked ROM (MROM)
2. Programmable Read Only Memory (PROM) / (OTP)
3. Erasable Programmable Read Only Memory (EPROM)
4. Electrically Erasable Programmable Read Only Memory (EEPROM)
5. FLASH

86
 Program Storage Memory (ROM)
1. Masked ROM (MROM):
• Masked ROM is a one-time programmable device("hard-wired
ROM," )
• Mask ROM is programmed during the manufacturing process (such
as for storing firmware and system code) and we can't alter it
afterward
• The device is factory programmed according to the data provided
by the end user.
• The primary advantage of this is low cost for high volume
production. They are the least expensive type of solid state
memory.
87
Program Storage Memory (ROM)
1. Masked ROM (MROM):
• Masked ROM is a good for storing the embedded firmware
for low cost embedded devices.
• Once the design is proven and the firmware requirements are
tested and frozen, the binary data (The firmware cross
compiled/assembled to. target processor specific machine
code) corresponding to it can be given to the MROM
fabricator.
• The limitation with MROM based firmware storage is the
inability to modify the device firmware against firmware
upgrades.
88
 Program Storage Memory (ROM)
2.Programmable Read Only Memory (PROM) / (OTP)
• Unlike Masked ROM Memory, One Time Programmable Memory
(OTP) or PROM is not pre-programmed by the manufacturer.
• The end user is responsible for programming these devices.
• This memory has nichrome or polysilicon wires arranged in a
matrix.
• It is programmed by a PROM programmer which selectively bums
the fuses according to the bit pattern to be stored.

89
 Program Storage Memory (ROM)
• Fuses which are not blown/burned represents a logic “1” whereas
fuses which are blown/bumed represents a logic “0”.
• The default state is logic “1”.
• OTP is widely used for commercial production of embedded
systems whose proto-typed versions are proven and the code is
finalized.
• It is a low cost solution for commercial production.
• PROMs are often used in microcontrollers based applications,
mobile phones, video game consoles, and other consumer and
automotive electronics.
90
Program Storage Memory (ROM)
3. Erasable Programmable Read Only Memory (EPROM)
• OTPs are not useful and worth for development purpose.
• During the development phase the code is subject to continuous
changes and using an OTP each time to load the code is not
economical.
• Erasable Programmable Read Only Memory (EPROM) gives the
flexibility to re-program the same chip.
• EPROM stores the bit information by charging the floating gate of
an FET.

91
 Program Storage Memory (ROM)

• EPROM contains a quartz crystal window for erasing the

stored information.
• If the window is exposed to ultraviolet rays for a fixed
duration, the entire memory will be erased.
• Even though the EPROM chip is flexible in terms of re-
programmability, it needs to be taken out of the circuit board
and put in a UV eraser device for 20 to 30 minutes.
• So it is a tedious and time-consuming process.

92
 Program Storage Memory (ROM)
4.Electrically Erasable Programmable Read Only Memory
(EEPROM)
• As the name indicates, the information contained in the EEPROM memory
can be altered by using electrical signals at the register/Byte level.
• They can be erased and reprogrammed in-circuit.
• These chips include a chip erase mode and in this mode they can be
erased in a few milliseconds.
• It provides greater flexibility for system design. The only limitation is their
capacity is limited when compared with the standard ROM (A few
kilobytes).
93
 Program Storage Memory (ROM)
5. FLASH
• FLASH is the latest ROM technology and is the most popular ROM
technology used in today’s embedded designs.
• FLASH memory is a variation of EEPROM technology.
• It combines the re-programmability of EEPROM and the high
capacity of standard ROMs.
• FLASH memory is organized as sectors (blocks) or pages.
• FLASH memory stores information in an array of floating gate MOS-
FET transistors.
94
Program Storage Memory (ROM)

• The erasing of memory can be done at sector level or page

level without affecting the other sectors or pages.
• Each sector/page should be erased before re-programming.
• The typical erasable capacity’ of FLASH is 1000 cycles.

95
B. Read-Write Memory/Random Access Memory (RAM)

• Read-Write Memory/Random Access Memory (RAM)

• Static RAM (SRAM)
• Dynamic RAM(DRAM)
• NVRAM

96
1. Static RAM (SRAM)

• Static RAM stores data in the form of voltage.

• They are made up of flip-flops.
• Static RAM is the fastest form of RAM available.
• Fast due to its resistive networking and switching capabilities.
• In typical implementation, an SRAM cell (bit) is realised using
six transistors (or 6 MOSFETs).
• Four of the transistors are used for building the latch (flip-flop)
part of the memory cell and two for controlling the access.

97
 2.Dynamic RAM (DRAM)
• Dynamic RAM stores data in the form of charge.
• They are made up of MOS transistor gates.
• Advantages – high density and low cost compared to SRAM.
• Disadvantage – since the information is stored as charge it gets
leaked off with time and to prevent this they need to be refreshed
periodically.
• Special circuits called DRAM controllers are used for the refreshing
operation.
• The refresh operation is done periodically in milliseconds interval.
98
 Dynamic RAM (DRAM)
• The relative merits and demerits of SRAM and DRAM technology.
SRAM Cell DRAM Cell
Made up of 6 CMOS transistors Made up of a MOSFET and a capacitor
(MOSFET)
Doesn't require refreshing Requires refreshing
Low capacity (Less dense) High capacity (Highly dense)
More expensive Less expensive
Fast in operation. Typical access time Slow in operation due to refresh requirements.
is 10ns Typical access time is 60ns. Write operation is
faster than read operation.
99
NVRAM - Non-volatile RAM

3.NVRAM(Non-volatile RAM )
• Non-volatile RAM is a random-access memory with battery
backup.
• It contains 5 static RAM based memory and a minute battery
for providing supply to the memory in the absence of external
power supply.
• The memory and battery are packed together in a single
package.
• The life span of NVRAM is expected to be around 10 years.

100
C. Memory According to the Typeof Interface

• The interface (connection) of memory with the

processor/controller can be of various types.
1. Parallel interface
2. Serial interface
3. SPI (Serial peripheral interface)
4. Single wire interconnection

101
C. Memory According to the Typeof Interface

• Serial interface is commonly used for data storage memory

like EEPROM.
• The memory density of a serial memory is usually expressed in
terms of kilobits.
• Whereas that of a parallel interface memory is expressed in
terms of kilobytes.
• Atmel Corporations AT24C512 is an example for serial
memory with capacity 512 kilobits and 2-wire interface.

102
 Memory Selection for Embedded Systems
(continued)
• There are two parameters for representing a memory:
• Size of the memory chip
• Word size of the memory

1. Size of the memory chip – Memory density expressed in terms

of number of memory bytes per chip.
◦ Memory chips come in standard sizes like 512 bytes, 1024
bytes (1 kilobyte), 2048 bytes (2 kilobytes), 4KB, 8KB, 16KB,
32KB, 64KB, 128KB, 256KB, 512KB, 1024KB(1 megabytes),
etc.
103
Memory Selection for Embedded Systems
(continued)
2. Word size of the memory – The number of memory bits that
can be read/written together at a time.
◦ Word size can be 4, 8, 12, 16, 24, 32, etc.
◦ The word size supported by the memory chip must
match with the data bus width of the
processor/controller.

104
PART B:
Embedded system Development Environment – Block diagram
(excluding Keil), Disassembler/decompiler, simulator, emulator
and debugging techniques, target hardware debugging, boundary
scan
Chapter 13 from Text book 02(Shibu K V, “Introduction to
Embedded Systems”)

105
A typical embedded system development environment is illustrated in Figure

2. (IDE)

5. Signal sources
3. (EDA)

1. Host
4. An emulator
hardware
7. target
hardware

6. hardware
debugging
tools

106
The development environment consists of
1. A Development Computer (PC) or Host, which acts as the
heart of the development environment.
2. Integrated Development Environment (IDE) Tool for
embedded firmware development and debugging.
3. Electronic Design Automation (EDA) Tool for Embedded
Hardware design.

107
4. An emulator hardware for debugging the target board,
5. Signal sources (like Function generator) for simulating
the inputs to the target board.
6. Target hardware debugging tools (Digital CRO,
Multimeter, Logic Analyzer, etc.) and
7. The target hardware.

108
 2. THE INTEGRATED DEVELOPMENT ENVIRONMENT
(IDE)
• It is 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
• ‘Linker’ and
• ‘Debugger’.

109
Some IDEs may provide
• Interface to target board emulators,
• Target processor’s/controller’s flash memory programmer,
etc.
• IDEs can be either command line-based, or GUI based.
• Command line-based ides may include little or less GUI
support.
• GUI based ides provide a visual development environment with
mouse click support for each action. Such ides are generally
known as visual ides.

110
• IDEs used in embedded firmware development are slightly
different from the generic/basic IDEs(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.
• Ex: MPLAB is an IDE tool supplied by microchip for developing
embedded firmware using.
• Keil pVision3 from Keil software is an example for a third party IDE,
which is used for developing embedded firmware.

111
 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
• Example: ARM processor or 8051 microcontroller specific machine
code).
• The conversion of the code is done by software running on a
processor/controller.
• “The software performing this operation is referred as the
‘Cross-compiler”.
• In a single word cross-compilation is the process of cross
platform software/firmware development .

112
• Cross assembling is like 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.

113
The various files generated during the cross -compilation/cross-
assembling process are:
1. List File (.1st),
2. Hex File (.hex),
3. Pre-processor Output file,
4. Map File (File extension linker dependent),
5. Object File (.obj)

114
 DISASSEMBLER/DECOMPILER

• Disassembler is a utility program which converts machine

codes into target processor specific Assembly
codes/instructions.
• The process of converting machine codes into Assembly
code is known as ‘Disassembling’.
• Decompiler is the utility program for translating machine
codes into corresponding high level language instructions.

115
• Decompiler performs the reverse operation of compiler/cross-
compiler.
• The disassemblers/decompiler for different family of
processors/controllers are different.
• Disassemblers/Decompiler are deployed in reverse
engineering.
• Reverse engineering is the process of revealing the technology
behind the working of a product.

116
• Disassemblers/Decompilers are powerful tools for analysing
the presence of malicious codes (virus information) in an
executable image.
• 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.

117
 SIMULATORS, EMULATORS AND DEBUGGING

• Simulators and emulators are two important tools used in

embedded system development.
• 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.
118
• 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 product can be developed in software.
• Emulator is hardware device which emulates/imitates/matches
the functionalities of the target device.
• It allows real time debugging of the embedded firmware in a
hardware environment.

119
Simulator-based debugging
• 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 (Everything is a simulated one)
4. Lack of Real-time behaviour

120
 Advantages of Simulator Based Debugging
• Simulator based debugging techniques are simple and
straightforward.
1. 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.
• Since the real hardware is not required, firmware
development can start well in advance immediately after the
device interface and memory maps are finalized.
• This saves development time.
121
Advantages of Simulator Based Debugging

2. Simulate I/O Peripherals:

• Simulator provides the option to simulate various I/O
peripherals.
• Using simulator’s, I/O support we 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.

122
3. Simulates Abnormal Conditions:
• With simulator’s simulation support we can input any
desired value for any parameter during debugging the
firmware and can observe the control flow of firmware.
• It really helps the developer in simulating abnormal
operational environment for firmware.
• So it helps the firmware developer to study the behaviour of
the firmware under abnormal input conditions.

123
Limitations of Simulator based Debugging

• Some of the limitations of simulator- based debugging are

explained below.
1. 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.

124
Limitations of Simulator based Debugging

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

125
Emulators and Debuggers

• What is debugging and

• why debugging is required?

126
What is debugging and why debugging is required?

• It 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 types
1. Hardware debugging and
2. Firmware debugging.

127
Emulators and Debuggers

1. Hardware debugging:
• It deals with the monitoring of various bus signals and
checking the status lines of the target hardware.
2. Firmware debugging: It deals with
• Examining the firmware execution,
• Execution flow,
• Changes to various CPU registers and
• Status registers on execution of the firmware to ensure
that the firmware is running as per the design.

128
 Why is debugging required?
• Firmware debugging is performed to discover the bug or the error
in the firmware which creates the unexpected behaviour.
• Firmware is analogous to the human body in the sense it is
widespread and/or modular.
• Any abnormalities in any area of the body may lead to sickness.
• How is the region causing illness identified correctly when you are
sick?
• If we look back, where no sophisticated diagnostic techniques
were available, only a skilled doctor was capable of identifying
the root cause of illness, that too with his solid experience.

129
Why is debugging required?

• Now, with latest technologies, the scenario is totally changed.

• Sophisticated diagnostic techniques provide offline diagnosis
like Computerized Tomography (CT), MRI and ultrasound
scans and online diagnosis like micro camera based imaging
techniques.
• With the intrusion of a micro camera into the body, the doctors
can view the internals of the body in real time.

130
• During the early days of embedded system development, there
were no debug tools available and the only way was “Burn the
code in an EEPROM and pray for its proper functioning”.
• If the firmware does not crash, the product works fine, If the
product crashes, the developer is unlucky.
• He needs to sit back and rework on the firmware till the
product functions in the expected way.
131
• Most of the time the developer had to seek the help of an
expert to figure out the exact problem creator.
• As technology has achieved a new dimension from the early
days of embedded system development, various types of
debugging techniques are available today.

132
• A brief history of firmware debugging

1. Incremental EEPROM Burning Technique

2. In-line Breakpoint Based Firmware Debugging
3. Monitor Program Based Firmware Debugging
4. In Circuit Emulator (ICE) Based Firmware Debugging
5. On Chip Firmware Debugging (OCD)

133
1. 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 or activate a “BUZZER if the code is functioning in the
expected way.
134
• It is a time-consuming process.
• But it is a onetime process and once we test the firmware in an
incremental model we can go for mass production.
• In incremental firmware burning technique, the process is not
doing any debugging but observing the status of firmware
execution as a debug method.
• Incremental firmware burning technique is widely adopted in
small, simple system developments and in product development
where time is not a big constraint (e.g. R&D projects).
• It is also very useful in product development environments where
no other debug tools are available.

135
2. Inline Breakpoint Based Firmware Debugging
• In-line breakpoint-based firmware debugging is a method where
we insert debugging code (like printf statements) directly into the
firmware to check if the code is executing as expected at specific
points.
• Firmware: It is a combination of both hardware and firmware. It is a type of
software, specifically low-level code embedded in hardware, Which controls
the device's basic functions.
• This technique essentially functions as a simple breakpoint
system,
• Allowing to print messages to a terminal or logger to track the
program's flow and verify if it's reaching the intended locations.

136
2. Inline Breakpoint Based Firmware Debugging

• It is another primitive method of firmware debugging.

• The debug code is a printfQ function which prints a string given as
per the firmware.
• We can insert debug codes {printfQ) commands at each point
where we 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.

137
 3. Monitor Program Based Firmware Debugging
(supervisor program)
• Monitor program-based firmware debugging is the first adopted
aggressive method for firmware debugging.
• In this approach a monitor program which acts as a supervisor is
developed.
• Monitor program-based firmware debugging" refers to using a
specialized debugging tool, often a "monitor program", to
examine and control the execution of firmware within a target
system.

138
 3. Monitor Program Based Firmware Debugging
(supervisor program)
• This allows developers to identify and resolve issues in the
firmware while it's running, which is crucial for debugging
embedded systems and other hardware-software
integrations
• The monitor program controls the downloading of user code
into the code memory, inspects and modifies
register/memory locations.
• The monitor program implements the debug functions as per
a pre-defined command set from the debug application
interface.
139
• 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
140
4. In Circuit Emulator (ICE) Based Firmware
Debugging

• In-Circuit Emulator (ICE) based firmware debugging uses a

hardware device.
• It replaces the microcontroller in a circuit, allowing for in-depth
debugging of the embedded system's firmware while it's running
in real-time.
• This means developers can monitor the system's behavior,
examine and modify registers and memory, and
• Trace the execution flow, all without interrupting the normal
operation of the system

141
4. In Circuit Emulator (ICE) Based Firmware
Debugging

• The basic functionality of ‘Simulator’ and ‘Emulator’ are same -

“Debug the target firmware”, the way in which they achieve this
functionality is totally different.
• ‘Simulator’ is a software application that precisely duplicates
(mimics) the target CPU and simulates the various features and
instructions supported by the target CP.
• Whereas an ‘Emulator’ is a self-contained hardware device which
emulates the target CPU.

142
• Figure illustrates the different subsystems and interfaces of an
‘Emulator’ device.

(Plug-On Device)

143
 5. On-Chip Firmware Debugging (OCD)

• On-Chip Debugging (OCD) refers to a method for debugging

software running on embedded systems, particularly
microcontrollers and System-on-Chip (SoC) designs.
• It allows developers to inspect and control the internal workings
of a device while it's running, without requiring external probes or
connectors.
• OCD enables features like code download, memory access,
breakpoint setting, and single-stepping.

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

145
• Processors/controllers with OCD support incorporate a
dedicated debug module to the existing architecture.
• OCD module implements dedicated registers for controlling
debugging.
• An On-Chip Debugger can be enabled by setting the OCD enable
bit.
• Debug related registers are used for debugger control
(Enable/disable single stepping, Freeze execution, etc.) and
breakpoint address setting

146
 Target Hardware Debugging
• Even though the firmware is bug free and everything is intact
in the board, our embedded product need not function as per
the expected behaviour in the first attempt.
• Because of various hardware related reasons like..
• Dry soldering of components,
• Missing connections in the PCB due to any un-noticed errors
in the PCB layout design,
• Misplaced components,
• Signal corruption due to noise, etc.
147
 Target Hardware Debugging
• The only way to sort out these issues and figure out the real
problem creator is debugging the target board.
• Hardware debugging is not like firmware debugging.
• Hardware debugging involves the monitoring of various
signals of the target board (address/data lines, port pins, etc.).
• Checking the inter connection among various components,
circuit continuity checking, etc.,
• There are various hardware debugging tools available to use
in Embedded Product Development.

148
1. Magnifying Glass (Lens)

• Example: we might have noticed watch repairer wearing a small

magnifying glass while engaged in repairing a watch.
• They use the magnifying glass to view the minute components inside
the watch in an enlarged manner so that they can easily work with
them.
• Like a watch repairer, magnifying glass is the primary hardware
debugging tool for an embedded hardware debugging professional.
• A magnifying glass is a powerful visual inspection tool.
• The magnifying station incorporates magnifying glasses attached to
a stand with CFL tubes for providing proper illumination for
inspection.
149
• With a magnifying glass (lens), the surface of the target board can
be examined thoroughly for dry soldering of components, missing
components, improper placement of components, improper
soldering, track (PCB connection) damage, short of tracks, etc.
• Nowadays high-quality magnifying stations are available for visual
inspection.
• The station usually incorporates multiple magnifying lenses.
• The main lens acts as a visual inspection tool for the entire
hardware board whereas the other small lens within the station is
used for magnifying a relatively small area of the board which
requires thorough inspection.

150
2. Multimeter
• A multimeter is used for measuring various electrical
quantities like
• Voltage (both AC and DC),
• Current (DC as well as AC),
• Resistance,
• Capacitance,
• Continuity checking,
• Transistor checking,
• Cathode and anode identification of diode, etc.
• Any multimeter will work over a specific range for each
measurement.
151
• A multimeter is the most valuable tool in the toolkit of an
embedded hardware developer.
• It is the primary debugging tool for physical contact-based
hardware debugging and almost all developers start debugging
the hardware with it.
• In embedded hardware debugging it is mainly used for
checking the “circuit continuity” between different points on
the board, measuring the supply voltage, checking the signal
value, polarity, etc.
• Both analog and digital versions of a multimeter are available.
152
3. Digital CRO

• Cathode Ray Oscilloscope (CRO) is a little more sophisticated

tool compared to a multimeter.
• CRO is used for waveform capturing and analysis,
measurement of signal strength, etc.
• By connecting the point under observation on the target board
to the Channels of the Oscilloscope, the waveforms can be
captured and analyzed for expected behaviour.
• CRO is a very good tool in analysing interference noise in the
power supply line and other signal lines.

153
• Monitoring the crystal oscillator signal from the target board is a
typical example of the usage of CRO for waveform capturing and
analysis in target board debugging.
• CROs are available in both analog and digital versions.
• Though Digital CROs are costly, feature wise they are best suited
for target board debugging applications.
• Digital CROs are available for high frequency support, and they
also incorporate modem techniques for recording waveform over
a period of time, capturing waves on the basis of a configurable
event (trigger) from the target board

154
 4. Logic Analyser

• A logic analyser is the advanced level of digital CRO.

• Logic analyser is used for capturing digital data (logic 1 and 0)
from a digital circuitry whereas CRO is employed in capturing
all kinds of waves including logic signals.
• Another major limitation of CRO is that the total number of
logic signals/waveforms that can be captured with a CRO is
limited to the number of channels.
• A logic analyser contains special connectors and clips which
can be attached to the target board for capturing digital data.

155
• In target board debugging applications, a logic analyser captures
the states of various port pins, address bus and data bus of the
target processor/controller, etc.
• Logic analysers give an exact reflection of what happens when a
particular line of firmware is running.
• This is achieved by capturing the address line logic and data line
logic of target hardware.
• Most modem logic analysers contain provisions for storing
captured data, selecting a desired region of the captured
waveform, zooming selected region of the captured waveform,
etc.
156
5. Function Generator
• Function generator is not a debugging tool. It is an input signal
simulator tool.
• A function generator can produce various periodic waveforms
like sine wave, square wave, saw-tooth wave, etc. with
different frequencies and amplitude.
• Sometimes the target board may require some kind of periodic
waveform with a particular frequency as input to some part of
the board.
• Thus, in a debugging environment, the function generator
serves the purpose of generating and supplying required
signals.
157
13.6 BOUNDARY SCAN
• As the complexity of the hardware increase, the number of chips
present in the board and the interconnection among them may
also increase in turn it will increase the complexity.
• The traditional methods used in the PCB become small to
reduce the total board space occupied by them and multiple
layers may be required to route the inter connections among the
chips.
• With small device packages and multiple layers for the PCB it will
be very difficult to debug the hardware using magnifying glass,
multimeter, etc. to check the interconnection among the various
chips.
158
• Boundary scan is a technique used for testing the
interconnection among the various chips, which support JTAG
(Joint Test Action Group) interface, present in the board.
• A JTAG port which contains the five signal lines namely
1.TDI (Test Data In)
2.TDO (Test Data Out)
3.TCK (Test Clock)
4.TMS (Test Mode Select)
5.TRST (Test Reset) optional.
• These form the Test Access Port (TAP) for a JTAG supported chip
and each device will have its own TAP.
• The PCB also contains a TAP for connecting the JTAG signal lines
to the external world.
159
This forms a boundary scan path. Figure illustrates the same.

• TDI (Test Data In)

• TDO (Test Data Out)
• TCK (Test Clock)
• TMS (Test Mode Select)
• TRST (Test Reset)

Test Access
Port (TAP)

160
• A boundary scan path is formed inside the board by
interconnecting the devices through JTAG signal lines.
• The TDI pin of the TAP of the PCB is connected to the TDI pin of
the first device.
• The TDO pin of the first device is connected to the TDI pin of
the second device.
• In this way all devices are interconnected and the TDO pin of the
last JTAG device is connected to the TDO pin of the TAP of the
PCB.
• The clock line TCK and the Test Mode Select (TMS) line of the
devices are connected to the clock line and
• Test mode select line of the Test Access Port of the PCB
respectively.
161
• The boundary scan cell is a multipurpose memory cell.
• The boundary scan cell associated with the input pins of an IC
is known as input cells.
• The boundary scan cells associated with the output pins of an
IC is known as output cells.
• The boundary scan cells can be used for capturing the input
pin signal state and passing it to the internal circuitry,
capturing the signals from the internal circuitry and passing it
to the output pin, and shifting the data received from the Test
Data In pin of the TAP.
162
• The boundary scan cells associated with the pins are
interconnected and they form a chain from the TDI pin of the
device to its TDO pin.
• The boundary scan cells can be operated in
• Normal mode
• Capture mode
• Update mode
• Shift mode.

163
• ICs supporting boundary scan it contain additional boundary
scan related registers for facilitating the boundary scan
operation.
• Instruction Register,
• Bypass Register,
• Identification Register, etc.
• The Instruction Register is used for holding and processing
the instruction received over the TAP.
• The bypass register is used for bypassing the boundary scan
path of the device and directly interconnecting the TDI pin
of the device to its TDO.

164
• Different instructions are used for testing the interconnections
and the functioning of the chip.
• Extest, Bypass, Sample and Preload, Intest, etc. are examples
for instructions for different types of boundary scan tests,
• Whereas the instruction Runbist is used for performing a self
test On the internal functioning of the chip.
• The Runbist instruction produces a pass/fail result.
• Boundary Scan Description Language (BSDL) is used for
implementing boundary scan tests using JTAG.
• BSDL is a subset of VHDL and it describes the JTAG
implementation in a device.

165
• BSDL provides information on how boundary scan is implemented
in an integrated chip.
• The BSDL file is used as the input to a Boundary Scan Tool for
generating boundary scan test cases for a PCB.
• Automated tools are available for boundary scan test
implementation from multiple vendors.
• The ScanExpress Boundary Scan (JTAG) product from Corelis
Inc. (www.corelis.comJ is a popular tool for boundary scan test
implementation.

166
References
1. Shibu K V, “Introduction to Embedded Systems”, Tata McGraw Hill, 2009.
2. Raj Kamal, “Embedded Systems: Architecture and Programming”, Tata
McGraw Hill, 2008.

167