UNIT-IV: EMBEDDED SYSTEM DESIGN, DEVELOPMENT,

IMPLEMENTATION AND TESTING.

SYSTEM BOOT-UP:
With the development tools ready to go, and either a reference board or
development board connected to the development host, it is time to startup the system
and see what happens. System boot-up means that some type of power-on or reset source,
such as an internal/external hard reset (i.e., generated by a check-stop error, the software
watchdog, a loss of lock by the PLL, debugger, etc.) has occurred or an internal/external
soft reset (i.e., generated by a debugger, application code, etc.) has occurred.
When power is applied to an embedded board (because of a reset), start-up code,
also referred to as bootcode, bootloader, bootstrap code, or BIOS (Basic Input Output
System) depending on the architecture, in the systems ROM is loaded and executed by
the master processor. Some embedded (master) architectures have an internal program
counter that is automatically configured with an address in ROM in which the start of the
boot-up code (or table) is located, while others are hardware wired to start executing at a
specific location in memory.
Bootcode differs in length and functionality depending on where in the
development cycle the board is, as well as the components of the actual platform that
need initialization. The same (minimal) general functions are performed by bootcode
across the various platforms, which are basically initializing the hardware, which
includes disabling interrupts, initializing buses, settling the master and slave processors in
a specific state, and initializing memory. This first hardware initialization portion of bootup code is essentially the executing of the initialization device drivers. The initialization
is actually done, that is, the order in which drivers are executed, is typically outlined by
the master architecture documentation or in documentation provided by the
manufacturers of the board.
After the hardware initialization sequence, executed via initialization device
drivers, the remaining system software, if any, is then initialized. This additional code

may exist in ROM, for a system that is being shipped out of the factory or loaded from an
external host platform.
The callout box with bootcode example is as follows.
bootcodeExample()
{
---------//Serial Port Initialization Device Driver
initializeRS232(UART,BAUDRATE,DATA_BUS,STOP_BITS,PARITY);
//Initialize Networking Device Driver
initializeEthernet(IPAddress,Subnet,GatewayIP,ServerIP);
//check for host development system for down loaded file of rest of code to RAM
//through Ethernet
//start executing rest of code (i.e., define memory map, load OS, etc.)
---------}
POR (POWER ON RESET):
During power up/reset, CPU is not initialized. The power-on-reset is an
electronic device incorporated into the integrated circuit that detects the power applied to
the chip and generates a reset impulse that goes to the entire circuit placing it into a
known state.
RBL (ROM BOOTLOADER):
System boots via stages of boot codes, bootstrap/BIOS code is executed first. In
case of embedded system, after power on reset, processor executes BOOT ROM code to
initialize bare minimum hardware. RBL is a small piece of code that is hardwired in the
processor ASIC, which can perform sophisticated boot sequence on its own and load boot

programs from boot media devices like DDR, NAND, NOR, SD-CARD, PCI etc. Boot
mode options are available through boot mode pins. RBL reads this boot mode pins to
figure out which peripheral will be used to load 1st stage bootloader.
Processors (without ROM boot code) have a default address from which the first
bytes of code are fetched after power on/reset. Hardware designers use this information to
store bootloader code at that flash memory. NOR flash memory is used for this purpose
as it supports execution directly from flash.
BOOTLOADER:
Bootloader is small piece of code that is executed first with very limited
resources. Job of bootloader is to initialize hardware and load the operating system; it
loads the OS code from the non-volatile memory to volatile memory (RAM) and
transfers the execution to kernel.
Bootloader is broken into atleast two stages, as internal RAM memory size is
limited.
1ST STAGE:
1st stage bootloader (non-interactive) is small assembly code (machine code in
some cases) and its sole job is to load 2nd stage bootloader and transfer control to same.
External RAM is not yet initialized; hence 1st stage bootloader will first detect and setup
RAM memory.
Also, non-volatile memory (NAND, NOR etc.) where 2nd stage bootloader
resides is initialized. As soon as basic initialization is done, 2 nd stage bootloader is loaded
and executed from RAM memory.
2ND STAGE:
2nd stage bootloader performs hardware initialization (Ethernet, timers, clocks,
etc.), loading the kernel in RAM memory, passing necessary arguments to the kernel, and
transfer control to kernel. 2nd stage bootloader provides information about the location of
the filesystem to the kernel.
Not all embedded systems have two separate bootloaders. Like U-boot for few
systems is used as the second stage bootloader and few, it is both 1 st and 2nd stage

bootloader and resides in non-volatile memory. Small section of U-boot is 1 st stage

bootloader which is loaded by RBL and after basic initialization, U-boot relocates itself
to RAM location and starts executing from that location.

KERNEL:
The heart of a real time OS is the kernel. A kernel is the central core of an
operating system, and it takes care of all the OS jobs booting, task scheduling, standard
function libraries. In an embedded system, frequently the kernel will boot the system,
initialize the ports and the global data items. Then, it will start the scheduler and
instantiate any hardware timers that need to be started. After all that, the kernel basically
gets dumped out of memory (except for the library functions, if any), and the scheduler
will start running the child tasks.
MPC823-BASED BOARD BOOTING EXAMPLE:
The MPC823 processor contains a reset controller that is responsible for
responding to all reset sources. The actions taken by the reset controller differ depending
on the source of a reset event, but in general the process includes reconfiguring the
hardware, and then sampling the data pins or using an internal default constant to
determine the initial reset values of system components.
The block diagram of a reset controller is shown in the following figure. The
Reset Status Register (RSR) indicates that the last source to cause a reset. There are eight
sources of interrupts. Four are external pins and four are internal sources. HRESET* and
SRESET* are bidirectional. They can be asserted by external devices therefore, inputs.
From PORESET, they will be asserted also, therefore they can be outputs.

Fig 43.1: RESET CONTROLLER

The following diagram shows the operation and interactions of power-on-reset,
hard reset and soft reset.

Fig 43.2: HOW THE RESET PINS ARE HANDLED

When the power-on-reset pin is asserted (for atleast 16 clocks after external
power is atleast (2/3) Vcc), the MPC823 enters the power on reset state. When PORESET
is negated and the PLL locks, the 823 moves to the hard and soft reset state where
assertion of the hard and soft reset pins is assured for 512 clocks and the hard reset
configuration occurs. After 512 clocks elapses, the 823 moves into the wait state for 16
clocks. Here, HRESET and SRESET are negated. Finally, the 823 goes into the test for
HRESET and SRESET state where, if either pin should be asserted, it will again respond.

The following diagram shows the operation of soft reset.

Fig 43.3: HOW THE SOFT RESET INPUTS ARE HANDLED

When SRESET is asserted, internal hardware is reset but the hard reset
configuration does not change, and the 823 moves into the soft reset state. After 512
clock elapses, the 823 moves into the wait state for 16 clocks. Here, SRESET is negated.
Finally, the 823 goes into debug mode or goes into the test for SRESET state, where if
the SRESET pin should be asserted, it will again respond.