ARM MICROCONTROLLER & EMBEDDED

SYSTEMS (17EC62)

RTOS and IDE for Embedded System Design

(Lecture-4)
(Lecture-7)
Embedded System
Development Environment
Embedded System Development
Environment - Block Diagram
• The embedded system 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.
In system programming (ISP) interface (Serial/USB/Parallel/TCP
Integrated
development
environment (IDE)
tool

Signal source

EDA tool (Function generator)

Emulator-Target Board
interface (JTAG/BDM/Pin to
pin socket)

Emulator
Development PC
(Host)
Target board

PCB fabrication
files
Multimeter il-tt

Logic analyser
Fig.: The Embedded
System Development Hardware debugging tools

Environment
Embedded System Development
Environment - Block Diagram
• 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 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.
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

• Debugger.
Integrated Development
Environment (IDE)
• IDEs used in embedded firmware development are slightly different from the
generic IDs 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.
• Keil ^Vision from Keil software is an example for a third party IDE, which is
used for developing embedded firmware for 8051 family
microcontrollers and also ARM microcontrollers.
• MPLAB is an IDE tool supplied by microchip for developing embedded
firmware using their PIC family of microcontrollers.
• CodeWarrior by Metrowerks is an example of IDE for ARM family of
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'.
• In operation, disassembling is complementary to assembling/cross-assembling.

• 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.
Disassembler/Decompiler
• Disassemblers/Decompilers are deployed in reverse engineering.

• Reverse engineering is the process of revealing the technology behind the working
of a product.
• Reverse engineering in Embedded Product development is employed to find out
the secret behind the working of popular proprietary products.
• Disassemblers/Decompilers help the reverse engineering process by translating
the embedded firmware into Assembly/high level language instructions.
• Disassemblers/Decompilers are powerful tools for analysing the presence of
malicious codes (virus information) in an executable image.
Simulators
• 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.
• Simulators simulate the target hardware and the firmware execution can be
inspected using simulators.
• The features of simulator based debugging are:
• Purely software based
• Doesn't require a real target system
• Very primitive (Lack of featured I/O support. Everything is a simulated
one)
• Lack of Real-time behaviour
Simulators
• Advantages of Simulator Based Debugging

• Simulator based debugging techniques are simple and straightforward.

• The major advantages of simulator based firmware debugging techniques are:

• 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.
Simulators
• Simulate I/O Peripherals

• Simulator provides the option to simulate various I/O peripherals.

• Using simulator's I/O support, the values for I/O registers can be edited
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 flow of firmware.

Simulators
• Limitations of Simulator Based Debugging

• 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
realtime 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
• 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.
• A circuit for emulating target device remains independent of a particular target system
and processor.
• The emulator emulates the target system with extended memory and with code
downloading ability during the edit-test-debug cycles.
• Emulators maintain the original look, feel, and behaviour of the embedded system.

• Even though the cost of developing an emulator is high, it proves to be the more cost
efficient solution over time.
• Emulators allow software exclusive to one system to be used on another.

• It is more difficult to design emulators and it also requires better hardware than the
original system.
Simulator vs. Emulator
• Simulator is a software application • Emulator is a self-contained hardware
that precisely duplicates (mimics) device which emulates the target CPU.
the target CPU and simulates the • The emulator hardware contains
various features and instructions necessary
supported by the target CPU. emulation logic and it is hooked to the
• The simulator is a host-based debugging application running on the
program that imitates the development PC on one end and connects
functionality and instruction set of
the target processor. to the target board through some interface
• In summary, the simulator
'simulates' the target board CPU. on the other end.
Debuggers
• Debugger is a software tool that is used to detect the source of program or script
errors, by performing step-by-step execution of application code and viewing the
content of code variables.
• 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.
• Firmware debugging 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.
Firmware Debugging
• Firmware debugging is performed to figure out the bug or the error in the

firmware which creates the unexpected behaviour.

• There are several techniques for firmware debugging:
• Incremental EEPROM Burning Technique
• Inline Breakpoint Based Firmware Debugging
• Monitor Program Based Firmware Debugging
• In Circuit Emulator (ICE) Based Firmware Debugging
• On Chip Firmware Debugging (OCD)
Incremental EEPROM Burning Technique
• This is the most primitive type of firmware debugging technique.

• In this technique, 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.
• This means the code corresponding to all functionalities are separately coded, cross-
compiled and burned into the chip one by one.

• In this technique, we are not doing any debugging, but we are 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.
Inline Breakpoint Based Firmware
Debugging
• This 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, an inline debug code is inserted immediately after the point.
• The debug code is a printf() function which prints a string given as per the
firmware.
• The debug codes (printf() commands) can be inserted at each point where you
want to ensure the firmware execution is covering that point.
• The source code is cross-compiled along with the debug codes embedded within it.
• The corresponding hex file is burned into the EEPROM.

• The printf() generated data can be viewed on the HyperTerminal.

Monitor Program Based Firmware
Debugging
• This 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 predefined
command set from the debug application interface.
• 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.
Monitor Program Based Firmware
Debugging
• Once the commands for each operation is fixed, the code is written for performing the
actions corresponding to these commands.
• The commands may be received through any of the external interface of the target
processor (e.g. RS-232C serial interface/parallel interface/USB, etc.).
• The monitor program should query this interface to get commands or should handle the
command reception if the data reception is implemented through interrupts.
• On receiving a command, it is examined and the action corresponding to it is performed.
• The entire code stuff handling the command reception and corresponding action
implementation is known as the “Monitor Program".
• After the successful completion of the 'Monitor Program1 development, it is compiled
and burned into the FLASH memory or ROM of the target board.
• The code memory containing the monitor program is known as the 'Monitor ROM'.
Monitor Program Based Firmware
Debugging

Target CPU

Monitor ROM

Debugger RS-232 Serial link

applicati
on

Target board
Von-Neumann RAM

Fig.: Monitor Program Based Target Firmware Debug Setup

In Circuit Emulator (ICE) Based
Firmware Debugging
• Emulator is a special hardware device used for emulating the functionality of a
processor/controller and performing various debug operations like halt firmware
execution, set breakpoints, get or set internal RAM/CPU register, etc.
• Nowadays pure software applications which perform the functioning of a hardware
emulator is also called as 'Emulators' (though they are 'Simulators' in operation).
• The emulator application for emulating the operation of a PDA phone for
application development is an example of a 'Software Emulator'.
• A hardware emulator is controlled by a debugger application running on the
development PC.
• Most of the IDEs incorporate debugger support for some of the emulators
commonly available in the market.
In Circuit Emulator (ICE) Based
Firmware Debugging
• Figure illustrates the different subsystems and interfaces of an
'Emulator' device.
Debugger application RS-232/USB cable Emulator POD

Target board interface

(Device adaptor)

In circuit emulator

Signal lines
PC COM/USB port
(Flat Cable
Target Board

Fig.: In Circuit Emulator (ICE) Based Target Debugging

On Chip Firmware Debugging (OCD)
• Modern 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.
• Some vendors add 'on chip software debug support' through JTAG (Joint Test Action Group)
port.
• Usually the on-chip debugger provides the means to set simple breakpoints, query the internal
state of the chip and single step through code.
• Background Debug Mode (BDM) and JTAG (Joint Test Action Group) are two commonly
used interfaces for OCD.
• OCD module implements dedicated registers for controlling debugging.
Target Hardware Debugging
• Hardware debugging involves the monitoring of various signals of the target
board (address/data lines, port pins, etc.), checking the interconnection among
various components, circuit continuity checking, etc.
• The various hardware debugging tools used in embedded product
development are:
• Magnifying Glass (Lens)
• Multimeter
• Digital CRO
• Logic Analyser
• Function Generator
Magnifying Glass (Lens)
• Magnifying glass is the primary hardware debugging tool used for embedded hardware
debugging.
• A magnifying glass is a powerful visual inspection tool.

• 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 magnifying station incorporates magnifying glasses attached to a stand with CFL
tubes for providing proper illumination for 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.
Multimeter
• A multimeter is used for measuring various electrical quantities like voltage (Both AC
and DC), current (DC and 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.

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

• The digital version is preferred over analog the one for various reasons like readability,
accuracy, etc.
Digital CRO
• Cathode Ray Oscilloscope (CRO) is used for waveform capturing and analysis, measurement of
signal strength, etc.
• CRO is a very good tool in analysing interference noise in the power supply line and other signal
lines.
• 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, featurewise they are best suited for target board debugging
applications.
• Digital CROS are available for high frequency support and they also incorporate modern
techniques for recording waveform over a period of time, capturing waves on the basis of a
configurable event (trigger) from the target board.
• Most of the modern digital CROs contain more than one channel and it is easy to capture and
analyse various signals from the target board using multiple channels simultaneously.
• Various measurements like phase, amplitude, etc. is also possible with CROs.
Logic Analyser
• 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.
• A logic analyser contains special connectors and clips which can be attached to the target
board for capturing digital data.
• 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 particular line of
firmware is running.
• This is achieved by capturing the address line logic and data line logic of target
hardware.
• Most modern logic analysers contain provisions for storing captured data, selecting a
desired region of the captured waveform, zooming selected region of the captured
waveform, etc.
Function Generator
• Function generator is not a debugging tool.

• It is an input signal simulator tool.

• A function generator is capable of producing 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.
Boundary Scan
• Boundary scan is a technique used for testing the interconnection among the
various chips, which support JTAG interface, present in the board.
• Boundary scan is also widely used as a debugging method to watch integrated
circuit pin states, measure voltage, or analyse sub-blocks inside an integrated
circuit.
• The boundary scan test architecture provides a means to test interconnects
between integrated circuits on a board without using physical test probes.
• It adds a boundary scan cell that includes a multiplexer and latches, to each pin
on the device.
Boundary Scan
• 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.
• The benefits provided by boundary scan are:
• Lower test generation costs
• Reduced test time
• Reduced time to market
• Simpler and less costly testers
• Compatibility with tester interfaces
• High-density packaging devices accommodation
Thank You