Digi NET 50 Microprocessor Guide

NET+OS with Green Hills
BSP Porting Guide
NET+Works with Green Hills
BSP Porting Guide
Operating system/version: NET+OS 6.0
Part number/version: 90000333_B
Release date: March 2006
www.digi.com
©2006 Digi International Inc.
Printed in the United States of America. All rights reserved.
Digi, Digi International, the Digi logo, the Making Device Networking Easy logo, NetSilicon,
a Digi International Company, NET+, NET+OS and NET+Works are trademarks or registered trademarks of
Digi International, Inc. in the United States and other countries worldwide. All other trademarks are the
property of their respective owners.
Information is this document is subject to change without notice and does not represent a committment
on the part of Digi International.
Digi provides this document “as is,” without warranty of any kind, either expressed or implied, including,
but not limited to, the implied warranties of, fitness or merchantability for a particular purpose. Digi
may make improvements and/or changes in this manual or in the product(s) and/or the program(s)
described in this manual at any time.
This product could include technical inaccuracies or typographical errors. Changes are made
periodically to the information herein; these changes may be incorporated in new editions
of the publication.
Contents
C h a p t e r 1 : B S P O v e r v i e w .................................................................................. 1
Overview ........................................................................................................................ 2
Hardware reset .............................................................................................................. 2
ROM startup................................................................................................................... 3
ncc_init routine .................................................................................................... 4
C library startup............................................................................................................. 4
main routine ......................................................................................................... 5
NABoardInit routine..................................................................................................... 5
netosStartup routine ........................................................................................... 6
C h a p t e r 2 : P r o c e s s o r M o d e s a n d E x c e p t i o n s ................................. 9
Overview ...................................................................................................................... 10
Vector table................................................................................................................... 10
IRQ handler .................................................................................................................. 11
Servicing interrupts........................................................................................... 12
Changing interrupt priority............................................................................. 13
Interrupt sources and default priorities ................................................................... 13
Interrupt service routines ........................................................................................... 14
FIQ handlers................................................................................................................. 15
Installing a FIQ handler.................................................................................... 15
v
Chapter 3: Customizing the BSP
f o r A p p l i c a t i o n H a r d w a r e .................................................. 17
Overview ...................................................................................................................... 18
Before you begin.......................................................................................................... 18
Task 1: Purchase Ethernet MAC addresses from the IEEE ................................... 19
Task 2: Create a new platform directory ................................................................. 20
Task 3: Modify the BSP configuration settings ....................................................... 21
Task 4: Create a build file for your platform........................................................... 21
Task 5: Modify the linker scripts............................................................................... 23
Bootloader considerations ............................................................................... 23
Task 6: Modify the new BSP for the application hardware .................................. 24
Phase Lock Loop ............................................................................................... 24
Memory timing settings ................................................................................... 25
Chip select settings ........................................................................................... 25
General purpose I/O settings ......................................................................... 27
Ethernet PHY ..................................................................................................... 29
Simple serial driver........................................................................................... 30
Task 7: Modify the format of BSP arguments in NVRAM .................................... 30
Task 8: Modify error and exception handlers ......................................................... 31
Task 9: Create the debugger initialization files....................................................... 32
Task 10: Debug the initialization code from RAM ................................................. 34
Working with a locked-up ICE ....................................................................... 34
Preparing to debug ........................................................................................... 35
Debugging the initialization code .................................................................. 36
Task 11: Debug the initialization code from ROM ................................................. 39
Verify processor bootstrap values .................................................................. 40
Debug the ncc_init routine .............................................................................. 41
Task 12: Modify the Startup dialog .......................................................................... 42
Task 13: Modify the POST ......................................................................................... 43
Task 14: Modify the ACE ........................................................................................... 43
vi
C h a p t e r 4 : D e v i c e D r i v e r s .............................................................................. 45
Overview ...................................................................................................................... 46
Adding devices ............................................................................................................ 46
deviceInfo structure .................................................................................................... 46
Device driver functions .............................................................................................. 48
deviceEnter .......................................................................................................... 49
deviceInit ............................................................................................................. 50
deviceOpen .......................................................................................................... 51
deviceClose ......................................................................................................... 53
deviceConfig ....................................................................................................... 54
deviceRead .......................................................................................................... 55
deviceWrite .......................................................................................................... 57
deviceIoctl ........................................................................................................... 59
Modifications to the Green Hills system library..................................................... 60
Making modifications ....................................................................................... 60
C h a p t e r 5 : U p d a t i n g F l a s h S u p p o r t ....................................................... 61
Overview ...................................................................................................................... 62
Flash table data structure ........................................................................................... 63
Adding new flash ........................................................................................................ 65
Supporting larger flash ............................................................................................... 66
C h a p t e r 6 : B o o t l o a d e r U t i l i t y O v e r v i e w ............................................ 67
Overview ...................................................................................................................... 68
Bootloader application images .................................................................................. 68
ROM image ........................................................................................................ 69
RAM image ........................................................................................................ 69
Application image structure ...................................................................................... 70
Application image header................................................................................ 70
Boothdr utility.............................................................................................................. 72
Generating an image ................................................................................................... 73
Configuration file .............................................................................................. 73
vii
C h a p t e r 7 : C u s t o m i z i n g t h e B o o t l o a d e r U t i l i t y ......................... 75
Overview ...................................................................................................................... 76
Customization hooks .................................................................................................. 76
NABlReportError ................................................................................................ 77
getMacAddress ................................................................................................... 78
isImageValid ....................................................................................................... 79
shouldDownloadImage ....................................................................................... 80
getDefaultFilename ............................................................................................. 81
downloadImage ................................................................................................... 82
C h a p t e r 8 : L i n k e r F i l e s ...................................................................................... 83
Overview ...................................................................................................................... 84
Linker files provided for sample projects................................................................ 84
Green Hills section of the linker files ............................................................. 85
NET+OS section of the linker files.................................................................. 86
Memory aliasing in NET+OS .................................................................................... 86
Address mapping.............................................................................................. 88
C h a p t e r 9 : H a r d w a r e D e p e n d e n c i e s ...................................................... 89
Overview ...................................................................................................................... 90
DMA channels ............................................................................................................. 90
Ethernet PHY ............................................................................................................... 91
ENI controller .............................................................................................................. 91
Serial ports.................................................................................................................... 92
Software watchdog ..................................................................................................... 92
Big Endian mode ......................................................................................................... 92
System clock................................................................................................................. 92
PLLTST_SELECT............................................................................................... 93
XTAL1_FREQUENCY ...................................................................................... 93
CRYSTAL_OSCILLATOR_FREQUENCY..................................................... 93
PLL_CONTROL_REGISTER_N_VALUE...................................................... 94
viii
System timers ............................................................................................................... 94
Timer 1 ................................................................................................................ 94
Timer 2 ................................................................................................................ 94
Interrupts ...................................................................................................................... 95
Memory map................................................................................................................ 96
ix
Using This Guide
R
eview this section for basic information about the guide you are using, as well
as general support and contact information.
About this guide
This guide provides general information for porting the NET+Works for NET+OS
board support package (BSP) to a new hardware platform based on the Digi
development board.
NET+OS, a network software suite optimized for the NET+ARM devices, is part
of the NET+Works integrated product family.
Software release
This guide supports NET+OS 6.0. By default, this software is installed in the
C:\NETOS60_GH361\ directory.
Who should read this guide
This guide is for engineers who are developing applications with NET+OS.
To complete the tasks described in this guide, you must:
Be familiar with installing and configuring network software and
development board systems
Have sufficient system or user privileges to do these tasks
xi
What’s in this guide
This table shows where you can find specific information in this guide:
To read about
See
The BSP and how it works
Chapter 1, “BSP Overview”
The modes in which NET+OS operates, and
how interrupts are handled
Chapter 2, “Processor Modes and
Exceptions”
How to modify the BSP to support your
application hardware
Chapter 3, “Customizing the BSP for
Application Hardware”
Device driver functions and device definitions
Chapter 4, “Device Drivers”
Adding new flash ROM parts to the existing
table of supported flash ROM parts
Chapter 5, “Updating Flash Support”
What the bootloader utility is
Chapter 6, “Bootloader Utility
Overview”
How to customize the bootloader utility to
support your applications
Chapter 7, “Customizing the
Bootloader Utility”
The linker files provided for sample projects,
including basic Green Hills and NET+OS
sections of the linker files
Chapter 8, “Linker Files”
Hardware dependencies for porting NET+OS
to your application hardware
Chapter 9, “Hardware Dependencies”
Conventions used in this guide
This table describes the typographic conventions used in this guide:
xii
This convention
Indicates
italic type
Emphasis, new terms, variables, and document titles.
Select menu menu
option or options.
Menu selections. The first word is the menu name; the
words that follow are menu selections.
monospaced type
Filenames, pathnames, and code examples.
NET+Works with Green Hills BSP Porting Guide
Related documentation
The Quick Installation Guide explains how to install the hardware.
NET+Works with Green Hills Programmer’s Guide describes how to use
NET+OS to develop programs for your application and hardware.
The NET+Works online help provides reference information on the
NET+OS application programming interfaces (APIs).
Review the documentation CD-ROM that came with your development kit for
information on third-party products and other components.
For information on the processor you are using, see the NET+Works hardware
documentation.
Customer support
To get help with a question or technical problem with this product, or to make
comments and recommendations about our products or documentation, use this
contact information:
United State telephone: 1 877 912-3444
International telephone: 1 952 912-3444
email: [email protected]
Web site: http://digi.com
www.digi.com
xiii
BSP Overview
C
H
A
P
T
E
R
1
T
his chapter provides general information about the NET+OS Board Support
Package (BSP) and how it operates.
1
Overview
The BSP consists of the hardware-dependent parts of the real-time operating
system (RTOS), which includes:
Initializing the hardware after a hard reset or a restart
Exception handling
Device drivers
Starting the ThreadX kernel
Starting the TCP/IP stack
The NET+OS BSP that is provided with the NET+Works development kit is
designed to work on NET+Works development boards. Because most user
applications require custom hardware, you will need to modify the NET+OS
BSP to work correctly on your application hardware.
The rest of this chapter describes how the BSP initializes the hardware.
Hardware reset
At startup, the NET+ARM reads the state of all external address lines to determine
how to configure itself. All NET+ARM address lines have input current sources,
so that if left unchanged, the address lines are in the high state.
Hardware configuration settings are implemented through pull-up and pulldown resistors attached to these pins.
NET+OS requires these configuration settings:ET+OS requires these configuration
settings:
2
Configuration
Address
Mode
State
Endian
A27
Big Endian
High
CPU bootstrap
A28
ARM CPU enabled
High
NET+Works with Green Hills BSP Porting Guide
At startup, the NET+ARM performs this process:
1
Resets all internal devices
2
Disables all chip selects except CS0
3
Configures CS0 to map the contents of the ROM to all memory
4
Disables cache
At reset, the ARM processor core does this:
1
Enables ARM mode
2
Sets Supervisor mode
3
Disables IRQ and FIQ interrupts
4
Sets the program counter (PC) to 0
5
Starts executing at 0 (512 clocks after reset is de-asserted)
ROM startup
After a hardware reset, the first code executed is in
C:\NETOS60_GH361\src\bsp\common\reset.s. This code jumps to the routine
Reset_Handler_Rom, located in C:\NETOS60_GH361\src\bsp\arm7init\init.s,
which performs this process:
1
Sets the processor mode and disables all interrupts.
2
Initializes the phase lock loop (PLL) on the NET+50.
3
Sets the BSPEED field in the System Control register to enable full
bus speed.
4
Executes a soft reset.
5
Places the direct memory access (DMA) controller into test mode.
The on-chip static RAM, which normally stores DMA context information and
register values, becomes available as RAM.
6
Sets the SVC stack pointer to point to the DMA RAM.
7
Calls the ncc_init routine to initialize the application hardware.
8
Sets up stacks for all processor modes.
www.digi.com
3
9
Releases the DMA controller from test mode.
10
Calls the C library startup routines. These routines do not return.
ncc_init routine
To complete the basic hardware initialization of the system, Reset_Handler_Rom
calls the ncc_init routine. The routine performs this process:
1
Calls customizeSetupMMCR to set the Memory Management Control register.
2
Calls customizeGetScr to set the System Control register.
3
Determines whether a software restart has occurred.
4
Determines whether a debugger is attached.
5
Calls the customizeSetupPortX routines to set up the general-purpose I/O
(GPIO) ports.
6
Calls customizeSetupCS0 to set up CS0.
7
Sets up the other chip selects.
If a startup reset has occurred, all the chip selects are initialized. Otherwise, the
default implementation assumes that the RAM chip selects have already been
set up and reinitializes only CS3, which is normally used to support nonvolatile RAM (NVRAM).
8
Calls customizeReadPowerOnButtons to read and save the state of buttons and
jumpers.
9
Verifies that the application can fit in available RAM.
10
Sets flags in memory (which is now set up) to indicate whether a debugger is
present and whether a software reset has occurred.
C library startup
The C library startup sets up the C runtime environment in two steps:
4
1
Copies initialized data from ROM to RAM, and resets uninitialized data to 0.
2
Calls the main routine.
NET+Works with Green Hills BSP Porting Guide
main routine
After the C runtime environment is set up, the C runtime code calls the main
routine. The main routine performs this process:
1
Calls customizeSetupLedTable to initialize the LED driver
2
Executes a power-on self-test (POST) if a hard reset has occurred and APP_POST is
set
3
Sets up the system vector table
4
Calls NABoardInit to shut down DMA, the Ethernet media access controller
(MAC), ENI, and serial ports; initialize the low-level flash and NVRAM APIs; and
turn on cache if the NET+ARM supports it.
5
Calls DDIFirstLevelInitilize to perform preliminary initialization of system
device drivers
6
Calls NAGetAppCpp, which initializes the C++ runtime environment if APP_CPP is
defined
7
Calls tx_kernel_enter to start the ThreadX kernel
NABoardInit routine
The NABoardInit routine in the narmbrd.c file performs this process:
1
Reads the chip revision and stores it in the g_NAChipRevision global variable
2
Shuts down all DMA channels, as well as the Ethernet controller and all serial ports
3
Masks all interrupts
4
Initializes the flash and NVRAM read and write APIs
5
Calls NACacheSetDefaults to initialize and turn on cache
www.digi.com
5
netosStartup routine
The startup sequence is completed in the netosStartup routine, which performs
these steps:
1
Sets up the semaphores that the flash driver uses in a multithreaded environment.
2
Sets up the sleep function that the NAWait function uses.
3
Loads default NVRAM parameters from the appconf.h file.
4
Calls DDISecondLevelInitialize to load the system device drivers.
This function calls the deviceInit function defined for each device in the
device table.
5
Creates the TCP timer thread to trigger calls to tcp_down_function, which calls
the TcpDown application each second.
6
Calls customizeDialog to prompt the user with a configuration dialog box.
7
Calls netosConfigStdio.
If APP_STDIO_PORT is defined in appconf.h as a valid device name,
netosConfigStdio redirects stdin, stdout, and stderr to the
indicated device.
8
Starts the time APIs and sets the time zone to the value stored in NVRAM, which is
EST by default.
9
Calls filesystem_init if BSP_INCLUDE_FILESYSTEM_For_CLIBRARY is
defined as 1. The filesystem_init call initializes the filesystem for C library file
functions.
10
Calls netosStartTCP to create and initialize resources (for example, semaphores
and memory), and to start up all threads required by the
TCP/IP stack.
The Address Configuration Executive (ACE) is used to set the IP parameters.
The parameters may be stacked in NVRAM, or the ACE may set them from the
network.
The application startup is delayed BSP_STARTUP_DELAY seconds.
(BSP_STARTUP_DELAY is defined in bspconf.h.)
11
6
Calls TcpDown once every tick until the TCP/IP stack is initialized.
NET+Works with Green Hills BSP Porting Guide
12
After the TCP/IP stack is loaded, deletes the timer thread created in
step 5.
13
Sets up PPP-related semaphores for a multithreaded environment.
14
Calls applicationStart after the TCP/IP stack has started.
These routines are in the bsproot.c file:
netosStartup
DDISecondLevelInitialize
netosConfigStdio
BSP_STARTUP_DELAY is defined in the bsp.h file.
The customizeDialog routine is in the dialog.c file. The netosStartTCP
routine is in the starttcp.c file, and the filesystem_init routine is in the
startfilesystem.c file.
www.digi.com
7
Processor Modes and
Exceptions
C
H
A
P
T
E
R
2
T
his chapter discusses the modes in which NET+OS operates. This chapter also
describes how interrupts are handled.
9
Overview
The ARM processor supports six modes:
USER
SVC (Supervisor)
ABORT
UNDEF (Undefined)
IRQ (Interrupt)
FIQ (Fast Interrupt)
NET+OS operates in SVC and IRQ modes. All threads and the kernel scheduler
operate in SVC mode.
Hardware interrupts cause the processor to switch to IRQ mode.
The IRQ handler switches back to SVC mode before calling the device’s service
routine, allowing higher priority devices to interrupt the service routine,
if necessary.
The rest of this chapter describes in detail how NET+OS handles interrupts.
Vector table
An exception occurs when the normal flow of a program halts temporarily; for
example, to service an interrupt. Each exception causes the ARM processor to save
some state information and then jump to a location in low memory. Low memory
is referred to as the vector table.
A vector table is stored from 0x00000000 to 0x0000001f. Each vector consists of
a 32-bit word that is a single NET+ARM instruction. The instruction loads the
program counter with the contents of a memory location, which implements a
32-bit jump to an interrupt service routine (ISR).
10
NET+Works with Green Hills BSP Porting Guide
This table shows the vector address for each exception type:
Exception
Vector address
Reset
0x00000000
Undefined instruction
0x00000004
Software interrupt
0x00000008 (Not used by NET+OS)
Pre-fetch abort
0x0000000c
Data abort
0x00000010
Interrupt (IRQ)
0x00000018
Fast interrupt (FIQ)
0x0000001c
NET+OS treats these exception types as fatal errors:
Prefetch aborts
Data aborts
Undefined instructions
Fast interrupts
Although NET+ARM does not allow fast interrupts to be triggered by external
devices, software can program the watchdog timer and the general-purpose timer
to trigger a fast interrupt.
The default FIQ handler normally calls customizeExceptionHandler.
For more information on FIQs, see “FIQ handlers” on page 15.
IRQ handler
The IRQ signal is multiplexed to support 32 signals by the interrupt controller built
into the NET+ARM:
23 interrupt signals support devices inside the NET+ARM.
4 interrupt signals support external devices.
5 interrupt signals are not used and are considered reserved.
Software can selectively enable or disable any of the 32 interrupt signals.
www.digi.com
11
The BSP provides an IRQ handler. An interrupt request is generated when one or
more devices assert their interrupt signal. The IRQ handler reads the Interrupt
Status register and determines which devices need to be serviced.
The IRQ handler has a prioritized interrupt scheme. If more than one device is
requesting service, the handler determines which device has higher priority and
services that device first. Interrupts for higher priority devices are enabled before
the device’s service routine is called, allowing the device’s service routine to be
interrupted if a higher priority device requests service.
Servicing interrupts
The NET+OS IRQ handler uses this procedure to service an interrupt:
1
A device requests service by asserting its interrupt signal.
2
The NET+ARM latches the request into the Interrupt Status register—
Raw (ISRR).
Once the signal has been latched, and if the interrupt pin is edgetriggered, the NET+ARM generates the interrupt even if the device
stops asserting its interrupt line.
3
When corresponding bits in the Interrupt Enable register and the ISSR are
set, the NET+ARM asserts the IRQ signal to the ARM CPU.
4
If interrupts are enabled when the IRQ signal is asserted, the ARM CPU
switches to IRQ mode and jumps to the IRQ handler.
5
The IRQ handler saves the context of the interrupted thread and switches to
SVC mode to service the interrupt.
6
The IRQ handler calls NAIrqHandler in na_isr.c, which calls
NAGetInterruptLevel to find the highest priority interrupt.
7
In a loop, NAIrqHandler masks all lower priority interrupts, enables
interrupts, and calls the function registered during the NAInstallIsr call.
Upon completing this procedure, the handler disables the interrupts
that are lower priority than the one currently being processed. The loop
repeats until the handler services all interrupts. When all pending
interrupts have been serviced, NET+OS restores the context of the
interrupted thread and then resumes processing the thread.
12
NET+Works with Green Hills BSP Porting Guide
Changing interrupt priority
You can change the interrupt priority level by changing the order of the
NAInterruptPriority array in the bsp.c file. This list is ordered from lowest to
highest priority. You can specify each priority only once.
NET+OS treats incorrect ordering as a fatal error (that is, it calls
customizeErrorHandler).
Interrupt sources and default priorities
This table lists the supported interrupt sources, their bit positions in the Interrupt
Enable register, and the default NET+OS priority for each (as specified in the
NAInterruptPriority array in the bsp.c file).
Interrupt sources with a higher-numbered priority level can interrupt the service
routines of devices with lower-numbered priority levels.
Interrupt source
Bit
Priority
DMA1 (Ethernet receiver)
31
31
DMA2 (Ethernet transmitter)
30
30
DMA3 (Parallel port 1/ENI FIFO receiver/external peripheral)
29
29
DMA4 (Parallel port 2/ENI FIFO transmitter/external peripheral) 28
28
DMA5 (Parallel port 3/external peripheral)
27
27
DMA6 (Parallel port 4/external peripheral)
26
26
DMA7 (Serial port 1 receiver)
25
25
DMA8 (Serial port 1 transmitter)
24
24
DMA9 (Serial port 2 receiver)
23
23
DMA10 (Serial port 2 transmitter)
22
22
Parallel port 1—NET+50 only
21
21
Parallel port 2—NET+50 only
20
20
Parallel port 3—NET+50 only
19
19
Parallel port 4—NET+50 only
18
18
www.digi.com
13
Interrupt source
Bit
Priority
Ethernet receive
17
17
Ethernet transmit
16
16
Serial port 1 receive
15
15
Serial port 2 receive
14
14
Serial port 1 transmit
13
13
Serial port 2 transmit
12
12
Reserved
11–7
11–7
Watchdog
6
6
Timer 1
5
5
Timer 2
4
4
Port C PC3
3
3
Port C PC2
2
2
Port C PC1
1
1
Port C PC0
0
0
Interrupt service routines
The IRQ handler calls ISRs to service interrupts that external devices generate.
You can implement ISRs as standard C functions. That is, they must clear the
interrupt condition (usually by acknowledging it) and service the interrupt, and
then they can return as a standard C function.
Interrupts are enabled for higher priority interrupt levels when the ISR is called, so
one ISR can interrupt another ISR with a lower priority.
You can install an ISR by calling NAInstallIsr. After this routine returns, the ISR
is installed and the interrupt associated with it is enabled.
To disable and remove an ISR, call NAUninstallIsr, which disables the interrupt
and uninstalls the ISR handler.
14
NET+Works with Green Hills BSP Porting Guide
FIQ handlers
A fast interrupt (FIQ) is a higher priority interrupt than an IRQ, and therefore, it
can interrupt an IRQ.
NET+OS does not use FIQs. The default handler installed by the BSP treats a FIQ
exception as an error (that is, calls customizeErrorHandler).
You can program the watchdog timer and the two general-purpose timers to
generate a FIQ interrupt. To enable these interrupts, set the corresponding bits in
the Interrupt Enable register. (For descriptions of the System Control register,
Timer 1 and Timer 2 Control registers, and Interrupt Enable register, see your
documentation for the NET+ARM.)
The Interrupt Enable and Interrupt Status registers function identically for both
IRQ and FIQ levels. Because NET+OS does not use FIQs, the IRQ handler does not
contain special handling for FIQs. Instead, the IRQ handler dispatches FIQs
according to their interrupt source default priorities.
Installing a FIQ handler
X To install a FIQ handler, follow these steps:
1
Write the address of the application FIQ handler to memory location 0x0000003C.
2
Enable the FIQs in the Interrupt Enable register.
3
Modify the IRQ handler routine to exclude the FIQs from being dispatched
with the IRQs.
The IRQ handler code is in na_isr.c, reset.s, and init.s.
www.digi.com
15
Customizing the BSP for
Application Hardware
C
H
A
P
T
E
R
3
T
his chapter describes how to port the NET+OS Board Support Package (BSP)
to your application hardware. It provides general information about the BSP and
presents the basic tasks for porting the BSP to a new hardware platform.
17
Overview
This table lists the basic tasks for porting the BSP to your application hardware.
The remainder of the chapter provides more information about each task.
Task
Action
1
Purchase Ethernet media access controller (MAC) addresses from
the IEEE.
2
Create a new platform directory.
3
Modify the BSP configuration settings.
4
Create a build file for the platform.
5
Modify the linker scripts.
6
Modify the new BSP for the application hardware.
7
Modify the format of BSP arguments in NVRAM.
8
Modify the error and exception handlers.
9
Create the debugger initialization files.
10
Debug the initialization code from RAM.
11
Debug initialization code from ROM.
12
Modify the startup dialog.
13
Modify the power-on self-test (POST) routines.
14
Modify the ACE.
Before you begin
When you design your application hardware, follow the NET+Works reference
design and hardware design guidelines (available on the NET+OS CD) as closely
as possible.
Use the same parts as used on the NET+Works development board, especially
memory peripherals and Ethernet PHY devices.
18
NET+Works with Green Hills BSP Porting Guide
By minimizing the differences between your application hardware and the
development board, you reduce the amount of work you have to do to make
the NET+OS BSP work on your application hardware.
In addition, be sure your hardware supports these features:
Flash at CS0
RAM (32-bit wide) at CS1
NVRAM at CS3
A JTAG port, which allows you to use an in-circuit emulator (ICE) to
debug the hardware and software. This feature is essential when you
are bringing up a new board.
Extra serial port to send diagnostic messages for debugging.
Enough RAM to run your entire application, even if your product runs
out of ROM. Being able to run an application from RAM greatly
simplifies debugging.
A way to disable flash ROM. This feature is necessary because flash can
be accidentally overwritten. In this situation, the NET+ARM CPU
executes garbage instructions when you start it up.
Task 1: Purchase Ethernet MAC addresses from the IEEE
Each device on a network must have a unique Ethernet MAC address. Your
company must purchase its own block of addresses from the IEEE. After you
purchase the addresses, you must assign a unique one to each board.
The addresses are stored in NVRAM or flash ROM. Digi provides an Ethernet
MAC address with each development board, but you need a unique address for
your own boards.
www.digi.com
19
Task 2: Create a new platform directory
To support your application hardware, you need to modify code in the BSP. You
can find this code in separate directories.
The src\bsp\platforms directory contains a set of subdirectories. Each
subdirectory contains all the code specific to a particular development board. For
example, the subdirectory ns7520_a contains the code needed to support the
NS7520 development board.
You need to create a new subdirectory to hold the platform-specific code for your
application hardware.
20
NET+Works with Green Hills BSP Porting Guide
X To create a new subdirectory, follow these steps:
1
Determine which development board platform is closest to your application
hardware.
2
Copy the platform’s subdirectory (and its contents), and place it in the
src\bsp\platforms directory.
3
Name the new subdirectory. Give the new subdirectory a name that is
appropriate for your hardware application.
In this document, the new subdirectory is referred to as the platform directory.
Task 3: Modify the BSP configuration settings
You need to configure the BSP for your platform. The BSP configuration settings
are stored in the bsp.h and bsp.c files in the platform directory. The content of
these files is described in the online help and in the comments in the files. Edit the
files and adjust the configuration settings to support your application hardware.
Task 4: Create a build file for your platform
The next step is to create a build file for your platform. To create this file, first
locate the set of .bld files in the src\bsp directory—there is a file for each
supported platform.
www.digi.com
21
X To create a build file for your platform, follow these steps:
1
Copy one of the .bld files in the src\bsp directory and give this copy a
name appropriate for your platform.
2
Open the file with MULTI.
3
Change the subproject for dbgbsp.bld to use the copy of this file in your
platform directory.
4
Change the subproject for bsp.bld to use the copy of this file in your
platform directory.
Make sure the bsp.bld file is listed before the bootloader-related files so
that this library is built before the bootloader is built.
5
Open the File Options dialog box for the project. In the General tab, change
the BSP_PLATFORM define to set your platform’s name for this define.
6
In the File Options dialog box, in the Configuration tab, remove the original
platform directory from the list of system include directories and replace it
with your platform’s directory.
7
Open the bsp.bld subproject in MULTI.
8
Open the File Options dialog box. In the Actions tab, in the Commands to set
up input files: box, change the commands that copy the bootloader
configuration files and linker scripts so that they copy those files and scripts
from your platform directory.
9
Open the subproject.bld subproject in MULTI.
The project will list the source files for the project. Some of the source
files will be located in the platform directory you copied in task 2.
10
Change the subproject.bld file so that the files from the new platform
directory are built.
Tip:
22
You might find it easier to perform this step by editing the
subproject.bld file with a standard text editor.
11
Save and close the subproject.bld and bsp.bld files.
12
Save the project file.
13
Perform a Rebuild All operation to verify that your platform is built
correctly.
NET+Works with Green Hills BSP Porting Guide
Task 5: Modify the linker scripts
The customize.lx file declares a set of constants used to generate the linker
scripts. These constants control the size and location of the program sections. For
most applications, the only constants you might need to change are listed here:
Constant
Description
RAM_SIZE
Size of RAM part on the board. The linker generates an error if
the application is too large to fit in RAM.
FLASH_SIZE
Size of the flash part on the board. The linker generates an error
if a ROM-based application is too large to fit in RAM.
MAX_CODE_SIZE
The largest possible size of the uncompressed application image.
Use this constant to reserve sufficient RAM to hold the
application image. When creating the bootloader, use this
constant to reserve a section of memory to hold the application.
And when creating the application, use it to reserve memory in
uncached memory so that the alias of the application will not
collide with RAM used for data storage. The compression
algorithm used by the bootloader generally achieves 2:1
compression, so a good rule of thumb is to set this constant to
twice the amount of flash available to hold the compressed
application image. The linker generates an error if an application
image is larger than this value.
INIT_DATA_SIZE
Size of the memory area used to hold the state of switches and
buttons read at powerup.
BOOTLOADER_SIZE_
IN_FLASH
Determines the amount of flash ROM reserved for the
bootloader. You can also use this constant to calculate where the
application image starts in flash.
NVRAM_FLASH_SIZE
Determines how much flash ROM is reserved for NVRAM
storage. Set this constant to 0 if flash is not used for NVRAM.
Bootloader considerations
At startup, the bootloader decompresses the application image in flash to RAM
and executes it. This creates two issues:
The bootloader must know where in RAM to decompress the
application image to.
www.digi.com
23
The bootloader must be positioned in RAM where it will not overwrite
itself when it decompresses the application.
The bootloader determines where to decompress the application to by reading
a field in the application's header. The value of the ramAddress field in the
bootldr.dat file sets the load address in the application header. This field must
be set to the same value as CACHE_CODE_START in the customize.lx file.
The position of the bootloader in RAM is determined in blbootldr.dat. This
file contains the information used to generate the header for the header for the
RAM image of the bootloader. The ramAddress field must be set to the value of
BOOTLOADER_CODE_START in the customize.lx file.
Task 6: Modify the new BSP for the application hardware
After you make your modifications to support your platform, you need to
modify additional settings to support your application hardware. These settings,
described in the next sections, are:
PLL
Memory timing
Chip selects
GPIO
Ethernet PHY
Simple serial driver
Phase Lock Loop
The PLL generates a clock when a crystal is used instead of an external oscillator.
The PLL must be configured to generate the correct clock speed. The PLL is
configured through pull-up and pull-down resistors on the NS7520, but is
configured by the BSP on the NET+50. The PLL settings are stored in a table in
bsp.c in the platform directory. The default settings in the table configure the
NET+50 PLL to run at 44 MHz and assume an 18.432 MHz crystal input. Modify
24
NET+Works with Green Hills BSP Porting Guide
the values in this table if your platform is different. For more information on this
table, see the online help.
Note:
The NS7520 development board BSP assumes that an external
oscillator will be used. See the online help to configure the BSP to
use the PLL.
Memory timing settings
The array NANetarmInitData in bsp.c in the platform directory holds the
timing settings for the memory parts. The timing settings control the number
of wait states and idle cycles. The default values in the table work for
commonly used parts.
Verify that the settings are correct for the memory parts on your board, and make
any necessary adjustments.
Chip select settings
The next table lists the customization hooks in cs.s. This file contains the routines
that configure the NET+ARM chip selects to support memory parts. You need to
modify the code in these routines to support your application hardware.
These routines execute before RAM is set up and before the C library is initialized.
Therefore, the routines cannot use global or static variables, or constants created
with the C const keyword. A small amount (512 bytes) of static RAM (SRAM) is
used to support a stack. The routines can create local variables on this stack in the
variables are small enough to fit.
Customization
hook
Hardware feature and default values set
customizeGetRamSize Returns the total amount of RAM on the system. The default
implementation does this by examining the configuration set
for CS1 and CS2. It therefore assumes that RAM is connected
to CS1 and, optionally, CS2.
www.digi.com
25
Customization
hook
Hardware feature and default values set
customizeGetScr
Returns the value to write to the System Control register
(SCR). The return value must leave the CACHE, CINIT,
DMATST, LENDIAN, and SMARST bits unchanged.
These hardware features are set by customizeGetScr:
Bus speed. Default is to run at full bus speed.
Bus Monitor Timer. Enabled and set for 128 clocks.
User mode access to ASIC registers. Enabled.
External bus master access to ASIC registers. Disabled.
Internal/External System Bus Arbiter. Internal.
DMA Test mode. Must leave enabled during initialization.
Use of TEA pin. Use only for error indications.
Misaligned bus transfer abort. Do not generate an abort
exception for misaligned transfers.
TA input synchronization. One state synchronization.
26
customizeSetupCS0
Configures CS0. The default implementation configures it to
support a flash part. The timing parameters are set according
to values in NANetarmInitData. The processor will be
executing code in flash when this function is called after a
power-on reset. Therefore, you must carefully write this
function so that the chip select remains valid at all times while
the function configures it.
customizeSetupCS1
Configures CS1. The default implementation assumes that
RAM will be connected to this chip select. It automatically
detects the RAM type and size and sets up the chip select
accordingly. The default implementation sets the timing
parameters according to the values in NANetarmInitData,
and generates a fatal error if no RAM is detected on this chip
select.
customizeSetupCS2
Configures CS2. The default implementation assumes that
RAM may be connected to this chip select. It automatically
detects the RAM type and size and sets up the chip select
accordingly. The default implementation sets the timing
parameters according to the values in NANetarmInitData,
and disables the chip select if no RAM is detected.
customizeSetupCS3
Configures CS3. On development boards that support
EEPROM, the default implementation sets up the chip select to
support an 8K EEPROM. Otherwise, the default
implementation disables the chip select.
NET+Works with Green Hills BSP Porting Guide
Customization
hook
Hardware feature and default values set
customizeSetupCS4
Configures CS4. The default implementation disables the chip
select.
customizeSetupMMCR
Sets up the Memory Management Control register (MMCR).
The MMCR controls the dynamic RAM (DRAM) refresh timing
and special functions for pins A25, A26, and A27. Default
functionality for A26 and A27 is set by the hardware through
pull-down resistors on pins A23 and A24. Usually, the
software leaves the powerup settings for these pins alone.
DRAM refresh rate: The default is to refresh at 67 KHz.
Use of pins A25, A26, and A27: The default is to use
A25 as an address line, and leave pins A26 and A27 as
configured by hardware at powerup.
Address multiplexor: The default setting is to use the
internal address multiplexor and not to use GPIO port C3
to support the DRAM RAS/CAS signals.
General purpose I/O settings
The next table lists the customization hooks in gpio.c. The routines in this file set
up the NET+ARM GPIO ports. You need to change the code in these routines to
support your application hardware.
As with the code in cs.c, the customizeSetupPortX functions are called before
RAM is set up on the development board and before the C library has initialized.
Therefore, these routines cannot use global or static variables or constants created
with the C const keyword. A small amount (512 bytes) of SRAM is used to
support a stack. The routines can create local variables on this stack if the variables
are small enough to fit.
www.digi.com
27
28
Customization hook
Hardware features and default values
set
customizeSetupPortA
Sets up GPIO port A. You can use the pins on this
port for either general-purpose I/O or to support
serial port 1.
The default implementation configures port A to
support a serial port if the BSP has been configured
to support serial port 1. Otherwise, it disables the
port.
You can also use the pins on this port to support
LEDs or other hardware on some development
boards.
customizeSetupPortB
Sets up GPIO port B. (This port does not exist on the
NS7520.) For NET+50-based platforms, the default
implementation configures port B to support serial
port 2 if the BSP has been configured to support
serial port 2. Otherwise, the default implementation
disables the port.
You can use the pins on this port to support LEDs or
other hardware on some development boards.
customizeSetupPortC
Sets up GPIO port C. You can use the pins on this
port for both general-purpose I/O and to support
serial port 2 on the NS7520. On the NET+50, use
this port only for general I/O. The port is set up to
support serial port 2 on the NS7520 if the BSP has
been configured to support the serial port.
Otherwise, the default implementation disables the
port.
You can also use the pins on this port to support
LEDs or other hardware on some development
boards.
customizeSetupPortD
Sets up GPIO port D. (This port does not exist on the
NS7520.) The default implementation disables this
port on NET+50 platforms.
customizeSetupPortF
Sets up GPIO port F. (This port does not exist on the
NS7520.) The default implementation disables this
port on NET+50 platforms.
customizeSetupPortG
Sets up GPIO port G. (This port does not exist on the
NS7520.) The default implementation disables this
port on NET+50 platforms.
NET+Works with Green Hills BSP Porting Guide
Customization hook
Hardware features and default values
set
customizeSetupPortH
Sets up GPIO port H. (This port does not exist on the
NS7520.) The default implementation disables this
port on NET+50 platforms.
customizeReadPowerOnButtons
Reads the state of buttons and switches at powerup
and saves it in a RAM buffer. It is called after a hard
reset. The default implementation reads the state of
the GEN_ID bits and all GPIO ports and saves it in a
RAM buffer. The size of the RAM buffer is
determined by the linker command file used to create
the executable. NET+OS ships with linker command
files that create a 1K buffer. The information is not
overwritten by software restarts.
customizeSetupLedTable
Sets the global variables NALedTable and
NA_LED_COUNT to point to a table of LED settings and
the number of LEDs supported by the hardware. The
default implementation sets up the variables to
support the LEDs on the development board.
customizeReset
Called to reset the application hardware. The default
implementation uses the internal watchdog timer to
reset the NET+ARM. You may need to modify this
routine to reset other hardware on the application
platform before resetting the processor.
customizeRestart
Called to restart the application without resetting the
hardware. The default implementation branches to
the BSP’s initialization routines, which stops and
restarts the ThreadX kernel and all application
software. You may need to shut down some
application software in an orderly way and/or reset
some application hardware.
Ethernet PHY
The Ethernet PHY driver is located in mii.c in the platform directory. If your
hardware does not use a supported PHY, you must modify the driver to support it.
www.digi.com
29
Simple serial driver
A simple serial driver is provided for debugging the BSP before the main serial
driver is loaded. The driver is located in the simpleSerial.c file in the platform
directory. The driver assumes that serial port 1 will be used at 9600 baud. To use a
different port or baud rate, you must modify this driver.
Task 7: Modify the format of BSP arguments in NVRAM
The BSP stores some configuration arguments in NVRAM. The configuration
values are read and written by way of customization hooks in boardParams.c.
You must modify these customization hooks to support your application.
30
Customization hook
Description
customizeGetMACAddress
Determines the Ethernet MAC address used to
communicate on the network.
Each device on the network needs a unique
Ethernet MAC address. You must purchase a
block of Ethernet MAC addresses from the IEEE
and then modify this routine to return an address
from this block. The default implementation
returns a value that was stored in NVRAM.
customizeGetSerialNumber
Returns the serial number for the unit. The serial
number is used only in some sample applications
and in the startup dialog. It is not used by the API
libraries, or in any part of the BSP except the
dialog. If you rewrite the dialog, this routine can
be dropped. The default implementation returns a
9-character serial number read from NVRAM.
Many developers use the Ethernet MAC address
as the unit's serial number.
customizeSaveSerialNumber
Sets the serial number for the unit. The serial
number is used only in some sample applications
and in the startup dialog. It is not used by the API
libraries, or in any part of the BSP except the
dialog. If you rewrite the dialog, this routine can
be dropped. The default implementation stores a
9-character serial number in NVRAM.
NET+Works with Green Hills BSP Porting Guide
Customization hook
Description
customizeSetMACAddress
Sets the Ethernet MAC address for the unit. The
default implementation stores the MAC address as
a 6-byte array in NVRAM.
customizeUseDefaultParameters
Determines default configuration values and
returns them in a buffer. The default
implementation determines the default values
through constants set in appconf.h.
You need to modify this routine to support your
application.
customizeReadDevBoardParams
Reads the configuration from NVRAM into a
buffer.
You need to modify this routine to support your
application.
customizeWriteDevBoardParams
Writes the configuration to NVRAM. The default
implementation accepts the current configuration
as a buffer and writes the buffer into NVRAM.
customizeGetIPParameters
Reads the IP-related configuration values from
NVRAM.
customizeSaveIPParameters
Writes the IP-related configuration values to
NVRAM.
Task 8: Modify error and exception handlers
The errhndlr.c file in the platform directory contains customization hooks
for an error handler and an exception handler.
The error handler, customizeErrorHandler, is called by code in the BSP when
fatal errors occur. Using constants in bsp.h, you can configure the default error
handler to either report the error by blinking LEDs in a pattern or reset the unit
when a fatal error occurs. You may need to modify the error handler if you want
to report the error in some other way or take some other action.
The unexpected exception handler, customizeExceptionHandler, is called when
these exceptions occur:
www.digi.com
31
Undefined instruction
Software interrupt
Prefetch abort
Data abort
Fast interrupt
Using constants in bsp.h, you can configure the exception handler to handle these
exceptions by resetting the unit, blinking an error code on LEDs, or continuing
execution at the point at which the exception returned. Digi does not recommend
that you attempt to continue execution. You may need to modify the exception
handler to better support your application.
Task 9: Create the debugger initialization files
When you use the ICE debugger, you must initialize hardware registers on the
board that the BSP ROM startup code would normally set up. You can use
debugger initialization scripts for this task. The script contains commands that are
executed by the debugger before the application is downloaded and executed.
NET+OS ships with debugger scripts that initialize the supported development
boards. You must create one to initialize your application hardware.
Different script files have to be used to set up different ICEs. NET+Works
supports the Raven by Macraigor and, optionally, the JEENI ICE by EPI Tools. By
convention, JEENI scripts have the extension .dbs, and Raven scripts have the
extension .ocd. For example, ns7520.dbs is a script file to set up the NS7520
development board when a JEENI ICE is used.
32
NET+Works with Green Hills BSP Porting Guide
X To create a debugger initialization file:
1
Copy the debugger script for the development board closest to your
hardware platform and the ICE you are using. Give it an appropriate name.
2
Edit the debugger script with a text editor. You see several sequences of
commands like these:
m ffc00020 = 0
m ffc00024 = f3000070
m ffc00020 = 0000022d
m ffc00028 = 00000001
These commands write values to registers in the NET+ARM. The form
of these commands varies from ICE to ICE. For details on the debugger
script commands, see the Green Hills MULTI Debugger documentation
and ICE documentation.
3
You need to modify the script so that the NET+ARM is properly set up for
your application hardware. You must:
–
Set up the IP address of the JEENI, or communications port for the
Raven.
–
Configure MULTI for the correct endian mode.
–
Configure the PLL on the NET+50 to the correct clock speed by setting
PLLCR.
–
Configure the System Control register to set the correct bus speed and
endianess, and disable the watchdog timer.
–
Set the valid bit in the CS0 chip select to 0. The BSP checks this bit to
determine whether a debugger is being used. This is important because
the BSP has to know whether it should configure the RAM chip selects,
perform a memory test, and turn on cache.
–
Set up the memory controller to perform the synchronous dynamic
RAM (SDRAM) refresh functions.
–
Set up the chip selects used for RAM, because the application code will
be loaded into RAM.
www.digi.com
33
–
–
When you set up a chip select, do not set the valid bit in CSBAR until
after CSOR and CSORB have been set. Digi recommends this procedure:
a
Write 0 to the CSBAR register.
b
Write the CSOR and CSORT registers.
c
Write the CSBAR register.
Set the CPSR register to 0xd3 (the value set by hardware after a poweron reset).
You also may need to set up devices on your application hardware.
Task 10: Debug the initialization code from RAM
After you have completed your modifications and created the debugger
initialization scripts for your application hardware, you need to debug the code.
To debug code from RAM, you need to use the ICE and download the code
through the debugger into the RAM on your board. The next sections describe
this procedure.
Working with a locked-up ICE
Be aware that the ICE may lock up when it writes to the Chip Select registers,
even when the chip select is programmed correctly.
If the ICE locks up, try setting a breakpoint a few instructions past the instruction
that writes to the chip select, and restarting. Then let the program run to the
breakpoint, rather than trying to step into the instruction that writes to the chip
select.
34
NET+Works with Green Hills BSP Porting Guide
Preparing to debug
Before you start debugging, complete these tasks:
1
Rebuild the BSP with the new modifications.
2
Copy the template application and build the application with the power-on
self-test (POST) routine disabled. Disable the POST by setting the APP_POST
constant in the root.c file to 0.
3
Load the application with MULTI. Use the debugger script you created in
task 9 to initialize the hardware.
4
Set up the debugger to view assembler instructions, and then step one
instruction. This leaves the program counter (PC) at the beginning of the
startup code.
5
Verify that the debugger initialization file has configured the application
board such that:
–
The Chip Select registers for ROM and RAM are set up to support the
parts and memory map.
–
All interrupts are masked off.
–
The PLL registers are properly programmed for the crystal on your
application hardware. The PLL should be set by the debugger script on
NET+50 processors, and by pull-up and pull-down resistors on the
NS7520.
–
You can read and write RAM on your application board.
6
Check the Control Status register (0xffb0 0000) to verify that the board
came up in Big Endian mode.
7
Check the System Status register (0xffb0 0004) to verify that the GEN_ID
field reflects the bootstrap configuration values the application hardware is
trying to set.
8
Debug the initialization code by stepping through it, as described in the
next section.
www.digi.com
35
Debugging the initialization code
Debug the initialization code in stages, in the same order as presented in this
section:
1
init.s file
2
ncc_init routine
3
NABoardInit routine
4
Ethernet driver startup
Debug the init.s file
The init.s file performs initialization functions. Step through the code in init.s,
and verify that it works correctly. You usually do not need to change the code to
support custom hardware boards.
The init.s file is in the src\bsp\arm7init directory.
The code in init.s performs this process:
1
Sets the processor mode and disables all interrupts.
2
Initializes the PLL on the NET+50.
3
Sets the BSPEED field in the System Control register to enable full bus speed.
4
Executes a soft reset.
5
Places the DMA controller into test mode.
This action causes the on-chip static RAM (normally used to store DMA
context information and register values) to become available as RAM.
36
6
Sets the SVC stack pointer to point to the DMA RAM.
7
Calls the ncc_init routine to continue the initialization process.
8
Sets up stacks for all processor modes.
9
Releases the DMA controller from test modes.
10
Calls the C library startup routines. The routines do not return.
NET+Works with Green Hills BSP Porting Guide
Debug the ncc_init routine
The ncc_init routine performs most of the board-specific hardware set up by
calling a set of functions that you customize to support your specific board. After
you customize these routines (described in task 6), you need to check ncc_init
and your customized routines to verify that they are working correctly.
The ncc_init.c file is in bsp\arm7init.
The ncc_init routine performs this process:
1
Sets up the Memory Management Control register by calling
customizeSetupMMCR.
2
Sets up the System Control register by calling customizeGetScr.
3
Determines whether a software restart has occurred by examining the
contents of UNDEF mode R14.
The restart function sets this register when the system is restarted.
4
Determines whether a debugger is attached.
The debugger script files indicate the presence of a debugger by
clearing the valid bit for chip select 0 (CS0).
5
Sets up the GPIO ports by calling the customizeSetupPortX routines.
6
Sets up CS0 by calling customizeSetupCS0.
7
If a debugger is detected, calls customizeSetupCS3 to set up CS3 and
determines the amount of RAM on the system by calling
customizeGetRamSize.
8
Calls the customizeReadPowerOnButtons function to read and save the
state of buttons and jumpers.
9
Verifies that the application can fit in the available RAM.
10
Sets flags in memory, which is now set up, to indicate whether a debugger
is present and whether a software restart has occurred.
Debug the NABoardInit routine
Step through the initialization code in narmbrd.c to verify that the NVRAM APIs
are initialized to support the NVRAM on your application hardware. The
narmbrd.c file is in bsp\arm7init.
www.digi.com
37
Debug the Ethernet driver startup
X To debug the Ethernet driver startup, follow these steps:
1
Put a breakpoint on the eth_reset routine (in eth_reset.c) and let the
program run until you hit the breakpoint.
2
Perform the steps that apply to the PHY you are using (either MII
or ENDEC):
PHY
Steps
MII
1
Step into the customizeMiiReset routine (in the mii.c
file) and then into customizeMiiIdentifyPhy.
2
Verify that customizeMiiIdentifyPhy returns a value
not equal to 0xffff. Verify that mii_reset returns 0
and that customizeMiiIdentifyPhy identifies the PHY
on your application hardware.
3
Step into customizeMiiNegotiate and verify that
customizeMiiCheckSpeed determines whether you are
connected to a 100 Base-T network.
ENDEC
4
Step into customizeMiiCheckDuplex to determine if
you have a full- or half-duplex link.
1
Change #define MII_PHY(1) in the mii.h file to
#define MII_PHY(0).
2
Step into customizePhyReset in ethernet.c to make
sure the PHY reset works correctly. Then change
these functions as needed:
customizeMiiCheckSpeed
customizeMiiCheckDuplex
customizeMiiSetSpeed
customizeMiiCheckLink
38
NET+Works with Green Hills BSP Porting Guide
Task 11: Debug the initialization code from ROM
When you debug code from ROM, you use the debugger only to step through
the application code fetched from flash.
After you debug the BSP from RAM, build a ROM image (rom.bin) of the
application and program it into flash. The ROM startup is different from the
RAM startup because the initialization code needs to determine the type of RAM
on the board, size it, and set up the chip selects to support it. If you know the
board’s RAM is a fixed type and amount, you can hard-code it.
Note:
The Green Hills software components included with NET+OS do not
support a hardware breakpoint for the JEENI. The ROM debugging
instructions in this section apply only to the Raven ICE.
X To start debugging from ROM, follow these steps:
1
Connect the Raven to your board via the JTAG port. Also connect the power,
serial, and Ethernet cables.
2
Build rom.bld.
This generates a rom.bin file.
3
Build naftpapp.bld.
This downloads rom.bin into flash.
4
In the MULTI build window, open the rom.bld file that was previously
created in step 2.
5
In the build window, create a new connection by following these steps:
1
Select TargetConnect to Target.
2
Click New.
3
Give the new connection a name, and choose Macraigor OCD
connection (ocdserv) as the type.
4
Click Create.
www.digi.com
39
5
Choose Raven, and set endianness to Big and the processor type to
NetArm.
6
In the Advanced tab, click Apply to Flash/ROM Debugging Defaults
and then click OK to set the options.
7
In the Debug tab, under Other Options, type a space and then type
-rst_hard.
This will let you debug from ROM.
6
In the target window, click the TRG icon and enter these commands at the
RDI> prompt. The first one resets the board, and the second disables
interrupts.
ocd>rst
ocd>reg cpsr 0xd3
7
In the debugger window, type:
hardbrk Reset_Handler
This command places the hardware breakpoint at Reset_Handler.
8
Click Go. Notice that debugging stops when it hits this breakpoint.
9
To continue stepping through the program:
1
Remove the breakpoint.
2
Type hardbrk applicationStart.
3
Click Go.
You are returned to root.c where you can stop wherever you want.
Note:
Remember that you set only one hardware breakpoint at a time.
After stopping at the breakpoint, you should remove it and then
set another one.
Verify processor bootstrap values
The NET+ARM processor determines some configuration settings at startup by
sensing the presence of pull-up or pull-down resistors on some of the pins. (For
information on bootstrap initialization, see the hardware documentation for the
NET+ARM.)
40
NET+Works with Green Hills BSP Porting Guide
Verify that these values are set for your board:
Setting
Location
LENDIAN field
System Control register
BUSER field
IARB field
A26 bit
Memory Module Configuration register
A27 bit
ENI Mode field
ENI General Control register (not present on the NS7520)
GEN_ID field
System Status register
PSIO field
ENI Control register (not present on the NS7520)
WR_OC field
DINT2 field
I_OC field
DMAE field
EPACK field
PULINT field
PLL Settings register
on the NS7520
NS7520 board
Debug the ncc_init routine
The ncc.init routine operates differently when booting from ROM. Step through
the routine, and verify that:
1
The Memory Management Control register is set up correctly.
2
The System Control register is set up correctly.
3
The local variable software_reset is set to 0.
4
The local variable debugger is set to 0.
5
The GPIO ports are set up correctly for your board.
6
The chip select registers are set up correctly for your board.
The setup is done by the customizeSetupCSX functions that you need
to customize for your board.
7
The correct amount of RAM is detected.
www.digi.com
41
8
The jumpers and switches are read correctly.
9
The application can fit within available RAM.
10
The ncc_init routine sets flags in memory (which is now set up) to indicate
whether a debugger is present and whether a software restart has occurred.
Reading NET+ARM registers
To see the contents of the NET+ARM registers, do not use print/x *0xffc00010
or memview 0xffc00010. Instead, follow these steps:
1
Add a variable to the source; for example:
unsigned long temp=0xffc00010
2
Use print/x *temp in the debugger window to see the contents of the
NET+ARM registers.
Hardware breakpoints
After you step through the initialization code, delete the hardware breakpoint you
initially set. You can then set another hardware breakpoint to another function or
code address. You can set only one hardware breakpoint at a time.
Task 12: Modify the Startup dialog
The BSP prompts the user to change configuration settings after a reset. The dialog
implemented for the development boards prompts users to set the unit’s serial
number, Ethernet MAC address, and IP Networking parameters. The dialog code
is in the dialog.c file in the platform directory.
If you do not want a dialog, replace the code in dialog.c with an empty version
of customizeDialog that just returns.
If you intend to use the dialog in your product, change it to support your
application. The customizeDialog function calls the NAGetAppDialogPort,
NAOpenDialog, and NACloseDialog functions to determine which port to use for
the dialog and to open and close it.
42
NET+Works with Green Hills BSP Porting Guide
Generally, you do not need to customize these functions. However, to support
your application, you usually need to completely rewrite the other functions
called by customizeDialog to display the current configuration settings and
prompt. The I/O port for the dialog is set by the constant APP_DIALOG_PORT in
your application’s appconf.h file.
Task 13: Modify the POST
The BSP automatically runs the POST from main if the APP_POST constant is set.
The POST routines that ship with NET+OS test the NET+ARM. You may want to
create additional POST routines that test additional hardware on your board.
Task 14: Modify the ACE
The Address Configuration Executive (ACE) is an API that runs at startup to
acquire an IP address. The aceCallbacks.c file in the platform directory contains
a set of callback functions that are invoked by the ACE at different points in the
process. You should customize the callbacks for your application.
For example, the customizeAceLostAddress function is called when the lease for
an IP address has expired. The default implementation resets the unit. You may
want to modify the function to notify your application of the problem so that your
application can try to recover by closing and restarting all network connections.
These functions are described in detail in the online help.
The aceParams.c file in the platform directory contains the code that reads and
writes ACE configuration information in NVRAM. Generally, the only part of this
file that needs to be customized is the definition of the dhcp_desired_params
array, and the definition of NADefaultEthInterfaceConfig. The
dhcp_desired_params array contains a list of the Dynamic Host Configuration
Protocol (DHCP) options thatACE is to request. You should add any additional
DHCP options that you want the client to ask for.
www.digi.com
43
The NADefaultEthInterfaceConfig contains the configuration that ACE uses
if none is stored in NVRAM. This controls which protocols are used to get an
IP address and the options used with them. The default configuration uses all
protocols to get an IP address. You should customize this configuration as
needed.
Device Drivers
C
H
A
P
T
E
R
4
T
his chapter provides information about device drivers and device definition.
45
Overview
NET+OS integrates device drivers with the low-level I/O functions provided
in the Cygwin standard C library. Each entry in the deviceTable array of the
devices.c file defines a device that the system supports.
The rest of this chapter describes the deviceTable array and the device driver
functions.
Adding devices
To add a device, you add an entry to the deviceTable array. Application
programs can then access the device through the standard C programming
language I/O functions — open, read, write, ioctl, and close.
deviceInfo structure
The entries in deviceTable are deviceInfo structures. The ddi.h file defines
the deviceInfo structure. The fields in this structure define the device driver’s
interface to NET+OS.
The deviceInfo structure is defined as shown here:
typedef struct
{
char *name;
int channel;
devEnterFnType *deviceEnter;
devInitFnType *deviceInit;
devOpenFnType *deviceOpen;
devCloseFnType *deviceClose;
devConfigFnType *deviceConfig;
devReadFnType *deviceRead;
devWriteFnType; *deviceWrite;
devIoctlFnType *deviceIoctl;
unsigned flags;
46
NET+Works with Green Hills BSP Porting Guide
} deviceInfo;
This table defines the fields in the deviceInfo structure:
Field
Description
name
Pointer to a null-terminated string that is the device channel’s
name. The name must be unique for each device.
channel
Channel number for the device name. This number is passed to the
device driver for all I/O requests.
deviceEnter
Pointer to the driver’s first-level initialization function for the
channel. This function is called once, during initialization, when the
C library initializes its I/O library. Kernel services are not available
at this point.
deviceInit
Pointer to the driver’s second-level initialization function for the
channel. This function is called once, at startup, after the kernel
has been loaded.
deviceOpen
Pointer to the device’s open function for the channel. This function
is called whenever an application opens the channel to indicate
that a new session is starting.
The flags field indicates whether the channel:
Was opened for read, write, or read/write mode
Operates in blocking or non-blocking mode
deviceClose
Pointer to the driver’s close function for the channel. This function
is called at the end of every session.
deviceConfig
Pointer to the driver’s configure function for the channel.
deviceRead
Pointer to the driver’s read function for the channel.
deviceWrite
Pointer to the driver’s write function for the channel.
deviceIoctl
Pointer to the driver’s I/O control function for the channel.
flags
Bit field that indicates which bits are valid in the flags field of an
open call to the device.
A bit set in this field indicates that the bit also can be set in the
driver’s open function.
www.digi.com
47
Device driver functions
This table provides a summary of the device driver functions in the deviceInfo
structure. Each function is described in the next sections. For details, see the online
help.
Function
Description
deviceEnter
First-level initialization function for a device table
deviceInit
Second initialization function for the device channel
deviceOpen
Notifies the device driver that:
A new session is starting on the channel
Which I/O mode will be used during the session
48
deviceClose
Informs the device driver that the application is closing its
session
deviceConfig
Passes configuration information to the device
deviceRead
Reads data from the device to the caller’s buffer
deviceWrite
Writes a buffer of data to a device
deviceIoctl
Sends commands to the device
NET+Works with Green Hills BSP Porting Guide
deviceEnter
First-level initialization function for a device table.
When the C library initializes its I/O functions, deviceEnter is called for each
entry in the device table. This function is called only once for each channel and
performs the basic initialization that the device driver needs. Because this function
is called before the kernel has started, kernel services are not available at this time.
Format
int deviceEnter (int channel);
Arguments
Argument
Description
channel
Channel number as set in the channel’s device table entry
Return values
Value
Description
EXIT_SUCCESS
Call completed successfully.
www.digi.com
49
deviceInit
Second initialization function for the device channel.
After the kernel has loaded, the device driver table is scanned and the deviceInit
functions for each channel are called. The deviceInit function is called once for
each channel and completes any additional initialization needs for the device
driver. Kernel services are available.
Format
int deviceInit (int channel);
Arguments
Argument
Description
channel
Channel number as set in the channel’s device table entry
Return values
50
Value
Description
EXIT_SUCCESS
Call completed successfully.
NET+Works with Green Hills BSP Porting Guide
deviceOpen
Notifies the device driver that a new session is starting on the channel, and tells
the driver which I/O mode will be used during the session. This routine is called
when an application opens a channel.
When deviceOpen is called, the driver performs these steps:
1
Checks that the channel number is valid, the channel is open, and the flags
are appropriate.
If an error condition is detected, the driver returns an error without
sending any information.
2
Sets an internal flag to indicate that a session is in progress on the channel.
3
Performs any other initialization tasks required by the device.
4
Returns EXIT_SUCCESS.
Format
int deviceOpen (int channel, unsigned flags);
Arguments
Argument
Description
channel
Channel number as set in the channel’s device table entry
flags
Bit field formed by ORing together one or more of these values:
O_RDONLY
O_WRONLY
O_RDWR
O_NONBLOCK
www.digi.com
51
Return values
52
Value
Description
EBUSY
Device is busy.
EINVAL
Invalid argument.
ENOENT
No such file or directory.
ENOMEM
Out of memory.
EROFS
Read-only file system.
EXIT_SUCCESS
Call completed successfully.
NET+Works with Green Hills BSP Porting Guide
deviceClose
Informs the device driver that the application is closing its session.
When deviceClose is called, the driver performs these steps:
1
Checks that the channel is open and that the configuration is valid for the
device.
If an error condition is detected, the driver returns an error without
sending any information.
2
Either sets the channel semaphore or returns EBUSY if the semaphore is
already set.
3
Updates internal flags to indicate the session has been closed.
4
Performs any other processing tasks as necessary.
5
Clears the channel semaphore.
6
Returns EXIT_SUCCESS.
Format
int deviceClose (int channel);
Arguments
Argument
Description
channel
Channel number as set in the channel’s device table entry
Return values
Value
Description
EBADF
Bad file number.
EBUSY
Device is busy.
EXIT_SUCCESS
Call completed successfully.
www.digi.com
53
deviceConfig
Passes configuration information to the device.
When deviceConfig is called, the driver performs these steps:
1
Checks that the channel is open and the configuration is valid for the device.
If an error condition is detected, the driver returns an error without
sending any information.
2
Either sets the channel semaphore or returns EBUSY if the semaphore is
already set.
3
Reconfigures the device.
4
Releases the semaphore.
5
Returns EXIT_SUCCESS.
Format
int deviceConfig (int channel, void *config);
Arguments
Argument
Description
channel
Channel number as set in the channel’s device table entry
config
Pointer to device-dependent configuration data
Return values
54
Value
Description
EBADF
Bad file number.
EBUSY
Device is busy.
EINVAL
Invalid argument.
EXIT_SUCCESS
Call completed successfully.
NET+Works with Green Hills BSP Porting Guide
deviceRead
Reads data from the device to the caller’s buffer.
When deviceRead is called, the driver performs these steps:
1
Sets bytesRead to 0.
2
Checks that the arguments are correct and the channel is open.
3
Checks for a pending error on the device.
If an error condition is detected, the driver returns an error without
transferring any data.
4
Either sets the channel semaphore or returns EBUSY if the semaphore is
already set.
5
If no data is available, performs one of these steps:
–
In blocking mode. Waits until some data is received.
If an error condition is detected, the driver aborts the transmission
and returns an appropriate completion code.
–
In non-blocking mode. Releases the semaphore and returns EAGAIN.
6
Copies the data from the driver buffers until either all the data has been
copied or the caller’s buffer has been filled.
7
Updates bytesRead.
8
Releases the channel semaphore.
9
Returns a completion code.
Format
int deviceRead (int channel, void *buffer, int length,
int *bytesRead);
www.digi.com
55
Arguments
Argument
Description
channel
Channel number as set in the channel’s device table entry
buffer
Pointer to caller’s receive buffer
length
Length of caller’s receive buffer (number of bytes)
bytesRead
Pointer to the number of bytes actually read
Return values
56
Value
Description
EAGAIN
Unable to complete operation now; try again later.
EBADF
Bad file number.
EBUSY
Device is busy.
EINVAL
Invalid argument.
EIO
I/O error.
EXIT_SUCCESS
Call completed successfully.
NET+Works with Green Hills BSP Porting Guide
deviceWrite
Writes a buffer of data to a device.
When deviceWrite is called, the driver performs these steps:
1
Sets bytesWritten to 0.
2
Checks that the arguments are correct and the channel is open.
3
Checks for a pending error on the device.
If an error condition is detected, the driver returns an error without
transferring any data.
4
Sets the channel semaphore, or returns EBUSY if the semaphore is already
set.
5
Opens a transmit buffer and fills it with data from the caller’s buffer.
6
Starts the transmit operation for the transmit buffer.
7
This step applies only to blocking mode. If an error condition is detected, aborts
the transmission and returns an appropriate completion code.
If there is more data in the caller’s buffer and more buffers, repeats steps
5 through 7 until there is no more data.
8
Updates bytesWritten to indicate the number of bytes transmitted.
9
Releases the channel semaphore.
10
Returns a completion code.
Format
int deviceWrite (int channel, void *buffer, int length,
int *bytesWritten);
Arguments
Argument
Description
channel
Channel number as set in the channel’s device table entry
buffer
Pointer to caller’s buffer; not necessarily aligned
length
Length of caller’s receive buffer (number of bytes)
bytesWritten
Pointer to int to load with number of bytes actually written
www.digi.com
57
Return values
58
Value
Description
EAGAIN
Unable to complete operation now; try again later.
EBADF
Bad file number.
EBUSY
Device is busy.
EINVAL
Invalid argument.
EIO
I/O error.
EXIT_SUCCESS
Call completed successfully.
NET+Works with Green Hills BSP Porting Guide
deviceIoctl
Sends commands to the device.
When deviceIoctl is called, the driver peforms these steps:
1
Checks that the arguments are correct and that the channel is open.
If an error condition is detected, the driver returns an error without
sending any commands.
2
Either sets the channel semaphore or returns EBUSY if the semaphore is
already set.
3
Executes the command.
4
Releases the channel semaphore.
5
Returns EXIT_SUCCESS.
Format
int deviceIoctl (int channel, int request, char *arg);
Arguments
Argument
Description
channel
Channel number as set in the channel’s device table entry
request
Commands encoded as integers
arg
Pointer to any extra information needed or to a buffer to return
information
Return values
Value
Description
EBADF
Bad file number.
EBUSY
Device is busy.
EINVAL
Invalid argument.
EXIT_SUCCESS
Call completed successfully.
You also can define your own return values.
www.digi.com
59
Modifications to the Green Hills system library
The Green Hills system library has been modified to support NET+OS device
drivers. The changes to the system library allow applications to use standard C
I/O calls to access NET+OS devices.
The system library was modified using the Green Hills ind_io.c source file, and
then rebuilt. You can make additional modifications to ind_io.c to add support
for a file system or for additional device drivers.
Making modifications
In Green Hills version 3.6.1, the NET+OS version of the library is in the ghsghs
directory. The original Green Hills version can be in one of three directories:
GHS\arm361
NETOS60_GH361\Green Hills
GHS\arm361\libsys
60
NET+Works with Green Hills BSP Porting Guide
Updating Flash Support
C
H
A
P
T
E
R
5
T
his chapter describes how to update flash memory.
61
Overview
NET+OS includes multiple API functions for reading, writing, and erasing flash
memory. The internals of the flash memory API rely on flash_id_table in the
naflash.c file to define the known flash parts. The flash API is guaranteed to
function only with parts that are defined in the flash_id_table. If the part is not
recognized, you need to update the flash_id_table.
The rest of this chapter describes the flash_id_table and also the procedures for
updating flash. See the online help for details on the flash API functions.
Here is a sample list of the flash ROM parts that NET+OS 6.0 supports. For a
complete list, see the flash.h file in the C:\NETOS60_GH361\ directory and the
flash.c file in C:\NETOS60_GH361\src\flash.
Manufacturer
AMD
Part numbers
AM29DL323DB
AM29F800BB
AM29F800BT
Atmel
29C040
29C040A
49BV8011
49BV8011T
49BV1614A
Fujitsu
29LV800BA
Macronix
MX28F4000
Sharp
LH28F800SG
SST
28SF040
39VF800
ST Micro
M29W800AB
M29W320DB
62
NET+Works with Green Hills BSP Porting Guide
Flash table data structure
The flash_id_table_t data structure, defined in the flash.h file, is shown here.
The tables following the code present the structure’s data types and fields.
typedef struct
{
WORD8 ccode;
WORD32 ccode_addr;
} flash_cmd_t;
typedef struct
{
WORD16 mcode;
WORD16 mcode_addr;
WORD16 dcode;
WORD16 dcode_addr;
WORD16 total_sector_number;
WORD32 sector_size;
WORD16 prog_size;
WORD16 access_time;
flash_cmd_t *id_enter_cmd;
WORD16 id_enter_len;
flash_cmd_t *id_exit_cmd;
WORD16 id_exit_len;
flash_cmd_t *erase_cmd;
WORD16 erase_len;
flash_cmd_t *write_cmd;
WORD16 write_len;
flash_cmd_t *sector_erase_cmd;
WORD32 *sector_size_array;
} flash_id_table_t;
www.digi.com
63
This table lists the data types used in the flash_id_table_t structure:
Data type
Description
WORD8
Unsigned byte
WORD16
Unsigned short
WORD32
Unsigned long
This next table summarizes the fields in the flash_id_table_t data structure:
64
Field
Description
mcode
Manufacturer’s code
mcode_addr
Address of manufacturer’s code
dcode
Device code
dcode_addr
Address of device code
total_sector_number
Total number of sectors
sector_size
Size of sector (in bytes)
prog_size
Program load size (in bytes)
access_time
Access time (in nanoseconds)
id_enter_cmd
Pointer to the enter identify flash command
id_enter_len
Number of cycles for the enter identify flash command
id_exit_cmd
Pointer to the exit identify flash command
id_exit_len
Number of cycles for the exit identify flash command
erase_cmd
Pointer to the erase flash command
erase_len
Number of cycles for the erase flash command
write_cmd
Pointer to the write flash command
write_len
Number of cycles for the write flash command
sector_erase_cmd
For AMD only
sector_size_array
For non-uniform sector sizes
NET+Works with Green Hills BSP Porting Guide
Adding new flash
When you add support for new flash ROM, you need to provide definitions for
the new flash device, such as the number of flash sectors, the flash sector size, and
the program load size.
You also need to modify the ROM type value in the flash_id_table definition.
For example, to add support for ST Micro M29W800AB flash ROM, you would
edit the flash.h file as shown here:
/* ST Micro M29W800AB*/
#define STM_M29W800AB_FLASH_SECTORS 0x013U
/* We are using block instead of sector */
#define STM_M29W800AB_FLASH_SECTOR_SIZE VARIABLE_SECTOR_SIZE
#define STM_M29W800AB_PROG_SECTOR_SIZE 0x0002U
X To add support for new flash ROM, follow these steps:
1
In the flash.h file, add the definitions for the new flash device.
2
In flash.h, modify the ROM type value; for example:
#define STM_29W800AB 0x0D
3
Edit the naflash.c file and modify the flash_id_table definition.
4
Modify other command sequences such as id_enter_cmd, id_exit_cmd,
and so on. Refer to the documentation supplied by the manufacturer of the
flash device you are using.
5
Rebuild the flash driver after you finish making your modifications.
To rebuild the driver, use MULTI to build na1b.bld in the
C:\NETOS60_GH361\ directory to rebuild the NA1 library in the top-level
directory. Rebuilding this library rebuilds the flash driver.
For the STM_29W800AB, for example, add this entry to the end of the
flash_id_table, based on the ROM type value defined in step 2:
{
0x20, 0x00, 0x005B, 0x01, STM_M29W800AB_FLASH_SECTORS,
VARIABLE_SECTOR_SIZE, STM_M29W800AB_PROG_SECTOR_SIZE, 120
(flash_cmd_t *)STM_M29W800AB_flash_id_enter_cmd,
www.digi.com
65
sizeof(STM_M29W800AB_flash_id_enter_cmd) /
sizeof(flash_cmd_t), (flash_cmd_t *)
STM_M29W800AB_flash_id_exit_cmd,
sizeof(STM_M29W800AB_flash_id_exit_cmd) /
sizeof(flash_cmd_t), (flash_cmd_t *)
STM_M29W800AB_flash_erase_cmd,
sizeof(STM_M29W800AB_flash_erase_cmd) / sizeof(flash_cmd_t),
(flash_cmd_t *)STM_M29W800AB_flash_write_cmd,
sizeof(STM_M29W800AB_flash_write_cmd) / sizeof(flash_cmd_t),
(flash_cmd_t *)STM_M29W800AB_flsh_block_erase_cmd, (WORD32*)
STM_M29W800AB_flash_block_size_array
}
This table shows the definitions for the values in the example:
Value
Definition
0x20
Manufacturer’s code
0x00
Address of manufacturer’s code
0x005B
Device code
0x01
Address of device code
Supporting larger flash
If you are adding larger flash, there are additional steps you need to perform.
X To support larger flash configurations:
1
2
66
Increase these three constants in flash.h:
–
MAX_SECTORS—The maximum number of flash sectors supported
–
MAX_SECTOR_SIZE—The maximum sector size supported
–
MAX_SECTOR_SIZE—The maximum number of flash banks supported
Rebuild the NA1 library in the top-level directory, which includes
flash.bld.
NET+Works with Green Hills BSP Porting Guide
Bootloader Utility Overview
C
H
A
P
T
E
R
6
T
his chapter describes the bootloader, a utility you use to recover from a failed
download of new firmware.
67
Overview
The bootloader is a utility you use to recover after a flash download of new
firmware fails. When the download fails, the bootloader automatically downloads
a new image from a network server.
Here are some general limitations regarding the bootloader that you should keep
in mind.
The bootloader’s DHCP/BOOTP client is limited. The client supports
options for getting the IP address, subnet mask, gateway address, boot
image filename, and boot image size only. You cannot use the client to
get other options.
The bootloader's User Datagram Protocol (UDP) stack supports a
limited implementation of UDP and IP that supports only those features
needed to support DHCP/BOOTP and Trivial FTP (TFTP).
The TFTP client supports only file downloads.
The TFTP server and the DHCP/BOOTP server must be located on the
same machine (that is, must have the same IP address).
The bootloader utility consists of two application images:
ROM image
RAM image
The rest of this chapter describes these images as well as details about how the
utility functions.
Bootloader application images
This section provides a description of the ROM and RAM application images that
the bootloader utility uses.
68
NET+Works with Green Hills BSP Porting Guide
ROM image
The ROM image is located in the first sector of flash. The processor automatically
starts to execute code from the beginning of flash after a reset, and so immediately
starts to execute the bootloader ROM image. The bootloader uses the BSP
initialization code to configure the hardware.
The ROM image initializes the hardware.
After the hardware is initialized, the ROM image decompresses the RAM image
section of the bootloader to RAM and executes it.
RAM image
The RAM image is stored as an application image in flash. Like other applications,
the RAM image has a boot image header. Information in the header determines
where, in RAM, to decompress the image. The RAM image runs after it is
decompressed to RAM.
The RAM image has these requirements:
Sufficient RAM must be available to hold the RAM image portion of the
bootloader (about 128 KB), the compressed application image
downloaded from the network, and the decompressed version of the
application image. The maximum sizes of both the compressed and
decompressed versions of the application image are set in the linker
script customization file.
The application image must be built with the boothdr utility.
In normal operation, the RAM image verifies that the application image stored in
flash is correct, decompresses it to RAM, and executes it. The application image
also has a boot image header, which determines where, in RAM, to decompress it.
If the application image fails the checksum test, the RAM image attempts to
recover by downloading a replacement for it. The RAM image follows these steps
to perform the recovery:
1
Initializes the Ethernet driver.
2
Initializes the UDP stack.
3
Downloads the application image from a network server to RAM.
www.digi.com
69
4
Validates the downloaded application image by performing a CRC32
checksum.
5
Stores the image into flash.
6
Resets the unit, which restarts the process.
The application image, which this procedure replaces, passes the
checksum test and is executed.
Application image structure
An application image consists of:
An application image header, which comprises two parts:
–
A NET+OS header
–
An optional custom header
The application itself
A checksum, which is computed over the entire image, including the
headers
The next section describes each component of the application image header.
Application image header
The application image header is split into two sections of variable length. The first
part contains data that the bootloader uses, and the second part contains
application-specific data that you define. Fields at the start of a section determine
the size of the two sections.
70
NET+Works with Green Hills BSP Porting Guide
This data structure defines the application image header:
typedef struct
{
WORD32 headerSize;
WORD32 naHeaderSize;
char signature[8];
WORD32 version;
WORD32 flags;
WORD32 flashAddress;
WORD32 ramAddress;
WORD32 size;
} blImageHeaderType;
The table shown next describes how the fields are used:
Field
Description
headerSize
Set to indicate the size of the complete header, including the
application-specific section. The application starts immediately
after the end of the header.
naHeaderSize
Set to indicate the size of the NET+OS portion of the image
header in bytes, including this field.
signature
Set to the ASCII string bootHdr to identify this header as a
valid image header.
version
Set to 0 for this version of the image header.
flags
A bit field of flags.
See the next table for details about bit values.
flashAddress
If the image is to be written to flash, set this field to the
address to which the image will be written. The entire image,
including the header, is written to flash.
ramAddress
Holds the image's destination address in RAM. When an image
is written to RAM to be executed, only the application part of
the image, without the header, is written.
size
Holds the size of the image (not including the header) in bytes.
www.digi.com
71
These bit values are defined for the flags field:
Bit value
Description
BL_WRITE_TO_FLASH
If this bit is set, the image is written to the address in flash
specified in the flashAddress field.
If this bit is clear, the image is run immediately without
writing it to flash. The image is moved or decompressed to
the address in the ramAddress field before it is executed.
BL_LZSS_COMPRESSED
If this bit is set, the application portion of the image is
compressed. It is decompressed to the address in the
ramAddress field before it is executed.
BL_EXECUTE_FROM_ROM
If this bit is set, the application is executed from ROM. The
application must not be compressed.
If this bit is not set, the application is decompressed or
moved to the address in the ramAddress field before it is
executed.
Boothdr utility
The boothdr utility converts a binary image into an application image by
performing these steps:
1
Inserting a header at the beginning of the image.
The data to place inside the header is read from a configuration file.
2
Inserting a custom header.
You specify this action at the command line by providing the name of a
file that contains the custom header.
3
Calculating a CRC32 checksum for the entire image, including the header,
and placing it at the end of the file.
The boothdr utility takes this command line:
Format
boothdr config-file input-file output-file [custom-header-file]
72
NET+Works with Green Hills BSP Porting Guide
Arguments
Argument
Description
config-file
The name of the configuration file
input-file
The name of the bin file to convert
output-file
The name of the file to create
custom-header-file
The name of a file that contains your custom header as
binary data
Generating an image
The template and sample build files use these steps to automatically build
application images whenever you build an application:
1
The build file compiles and links the application.
The application is linked for its execution address in RAM or ROM, but
is linked as a ROM application. Normally, this image is set up for
debugging.
2
An image without debugging information is created.
3
(This step is optional.) The compression program that ships with NET+OS
compresses the image.
4
The build file uses the boothdr program to create an application image that
the bootloader supports.
Configuration file
The configuration file contains configuration information in the form of several
keyword/value pairs. The default configuration file, bootldr.dat, it is stored in
the src\linkerScripts directory.
www.digi.com
73
This table describes the keyword/value pairs:
Keyword
Value Description
WriteToFlash
Set to one of these options:
Yes. Sets the BL_WRITE_TO_FLASH bit in the flags field of
the header.
No. The bit is left clear.
Compressed
Set to one of these options:
Yes. Sets the BL_LZSS_COMPRESSED bit in the flags field of
the header.
No. The bit is left clear.
ExecutedFromRom
Set to one of these options:
Yes. Sets the BL_EXECUTE_FROM_ROM bit in the flags field of
the header.
No. The bit is left clear.
FlashOffset
Specifies the offset from the beginning of flash where the image
is to be written.
Set to a hexadecimal value preceded by 0x.
RamAddress
Specifies the absolute address in RAM at which to execute the
application. The application is copied or decompressed to this
location.
Set to a hexadecimal value preceded by 0x.
MaxFileSize
Specifies the maximum size of the image in bytes. The
application terminates in error if the combination of the image,
header, and checksum is larger than this value.
Set to a hexadecimal value preceded by 0x.
Here is an example of a configuration file using keyword/value pairs:
74
WriteToFlash
Yes
Compressed
Yes
ExecuteFromRom
No
FlashOffset
0x10000
RamAddress
0x8004000
MaxFileSize
0xD0000
NET+Works with Green Hills BSP Porting Guide
Customizing the Bootloader
Utility
C
H
A
P
T
E
R
7
T
his chapter describes how to customize the bootloader utility for your
specific applications. Use the bootloader to recover from a failed download of
new firmware.
75
Overview
You can modify a set of functions in the default bootloader to support your
specific applications and environments. These functions, referred to as
customization hooks, are in the blmain.c and blerror.c files in the platform
directory.
The code in blmain.c is like a template bootloader. If the current application
image is corrupt, the code uses the bootloader API to download a new application
image. To add new functionality to the bootloader, you modify the template.
The rest of the chapter describes the functions in the blmain.c file. For details
about each function, see the online help.
Customization hooks
This table provides a summary of the functions in the blmain.c file.
76
Function
Description
NABlReportError
Called whenever an error occurs
getMacAddress
Gets the Ethernet MAC address the bootloader should use
isImageValid
Determines whether an image is valid
shouldDownloadImage
Determines whether the bootloader should download a new
image
getDefaultFilename
Determines the name of the file to download
downloadImage
Downloads a new application image
NET+Works with Green Hills BSP Porting Guide
NABlReportError
Called when an error is detected.
The error is reported to the user.
Format
void NABlReportError (errorCode);
Arguments
Argument
Description
errorCode
Identifies the error type
Return values
None
Implementation
The default implementation reports an error by blinking the LEDs on the
development board in a pattern and then returns. The pattern is determined by
the value of errorCode.
Because this implementation relies on hardware (the LEDs) that may not be
present on customer boards, it is valid for only the NET+ARM development
board.
You can customize the function in a number of ways, depending on the features in
the target hardware; for example, by:
Writing an error message out the serial port
Blinking the LEDs in a loop, which effectively forces users to reset the
device manually after correcting the problem
www.digi.com
77
getMacAddress
Returns a pointer to the Ethernet MAC address that the bootloader uses.
Format
char *getMacAddress;
Arguments
None
Return values
Returns the Ethernet MAC address as an array of characters
Implementation
The default implementation uses the function customizeGetMACAddress to read
the Ethernet MAC address from NVRAM. You can use the default
implementation if the customizeGetMACAddress function has been ported to the
application hardware.
You may need to modify the default implementation if you want to get the MAC
address in a different way. Do not hard-code the MAC address; doing so prevents
more than one unit from operating on the network.
78
NET+Works with Green Hills BSP Porting Guide
isImageValid
Determines whether a downloaded image is valid.
Format
int isImageValid (blImageInfoType *imageInfo)
Arguments
Value
Description
imageInfo
Pointer to the image header
Return values
Value
Description
TRUE
Image is valid.
FALSE
Image is not valid.
Implementation
The default implementation validates the image by checking the signature in
the header and performing a cyclic redundancy check (CRC) on the image.
You should extend the default implementation to determine whether the
application can and should be run on the hardware; for example, by:
Encoding information in the custom section of the image header that
identifies the application's hardware requirements and features.
Encoding the hardware capabilities into the GEN_ID and GPIO bits.
Verifying that the hardware has the features needed to run the
application.
Verifying that the end user is allowed to run the application on this unit.
In other words, making sure the user is not trying to upgrade a low-end
unit with the firmware for a high-end unit.
If the application is to be written into flash, verifying that it fits.
Verifying that the destination address specified in the image header
is valid.
www.digi.com
79
shouldDownloadImage
Determines whether to download an application image from the network.
Format
int shouldDownloadImage(void);
Arguments
None
Return values
Value
Description
TRUE
Downloads the image from the network.
FALSE
Executes the image in flash.
Implementation
To help debug the bootloader, the default implementation returns TRUE if the
image is invalid.
BOOLEAN shouldDownloadImage(void)
{
int result = TRUE;
blImageHeaderType *imageInfo = (blImageHeaderType *)
BSP_APPLICATION_ADDRESS;
result = (isImageValid(imageInfo) == FALSE);
return result;
}
You may want the bootloader to download a new image even if the current image
is valid. For example, you may want to let the end-user force a download by
pushing a button at powerup, or by selecting an option in a configuration menu.
80
NET+Works with Green Hills BSP Porting Guide
getDefaultFilename
The DHCP client gets the name of the application image from the Dynamic Host
Configuration Protocol (DHCP) or Bootstrap Protocol (BOOTP) server. The client
can pass the server the name of the file when the server requests this information,
allowing the server to determine which file is appropriate for the client.
How the server uses the information depends on the implementation. If no
filename is specified, the server returns the name of the default image file.
This function sets the name of the file that is passed to the DHCP/BOOTP server.
The function returns a zero-length string if it wants the default file.
Format
char *getDefaultFilename(void);
Arguments
None
Return values
A null-terminated ASCII string that is the name of the file the DHCP client will
request from the DHCP/BOOTP server
Implementation
The default implementation returns a pointer to an empty string, which has the
effect of requesting the default boot image on the TFTP server.
You will probably want to modify the default implementation to pass a filename
to the DHCP/BOOTP server. Some possibilities are:
Hard-coding a filename that identifies the product
Determining the features supported by the hardware and generating a
filename that has this information encoded in it
Generating a filename that identifies the features purchased by the user
www.digi.com
81
downloadImage
Downloads an application image from the network into a memory buffer
Format
int downloadImage (char *destination, int maxLength)
Arguments
Argument
Description
destination
Pointer to the memory buffer that will hold the image
maxLength
Size of the memory buffer in bytes
Return values
Return value
Description
BL_SUCCESS
Image successfully downloaded
otherwise
Error code that identifies the failure
Implementation
The default implementation uses DHCP to get an IP address, and TFTP to
download the image. The default implementation validates the image after
downloading it.
The default implementation can be used in many applications. You may want
to extend the default implementation by:
Using information in NVRAM to determine the unit's IP address, the IP
address of the TFTP server, or the name of the application image to
download
Passing a vendor class identifier (option 60) to the DHCP server
Receiving vendor information (option 43) from the DHCP server
Downloading the image over a serial or parallel port
82
NET+Works with Green Hills BSP Porting Guide
Linker Files
C
H
A
P
T
E
R
8
T
his chapter describes the linker files provided for sample projects.
83
Overview
The linker combines one or more object modules into a single executable output
module. Executable programs are divided into several sections that contain the
code and data parts of the application. Commands in the linker files supplied with
NET+OS determine where to map the sections of applications in memory.
The linker must position sections in an application where actual ROM and RAM
will reside. So, a different linker file will be used to create images that execute
from flash ROM versus one that executes from RAM.
The rest of this chapter describes the linker files for sample projects and also
provides information on memory aliasing.
Linker files provided for sample projects
Linker files are provided in src\linkerScripts for each sample project. Most
projects use the image.lx and rom.lx linker files to create applications that
execute from RAM or ROM respectively. These linker files are provided:
Linker file
Description
customize.lx
Customization file for linker scripts
image.lx
Generates an executable file for debugging and for image.bin
rom.lx
Generates an executable file for the rom.bin image
Some sections in applications are defined for all GHS applications, and some are
specific to NET+OS.
84
NET+Works with Green Hills BSP Porting Guide
Green Hills section of the linker files
This table summarizes the Green Hills section of the linker files:
Section
Description
picbase
Base of the text sections, relocatable in -pic mode
text
Text section
syscall
Syscall section, for host I/O under MULTI
fixaddr/fixtype
For PIC/PID fixups
rodata
Read-only data
romdata
ROM image of .data
romsdata
ROM image of .sdata
secinfo
Section information section, used by the startup code
pidbase
Base of the data sections, relocatable in -pid mode
initdata
Stores jumper and button settings read at startup
nccdata
Stores NET+OS settings determined at startup
sdabase
Base of the small data area section pointer
sbss
Small BSS (zeroed data) section
sdata
Small data section
data
Non-zeroed writeable data section
bss
Zeroed data section
heap
Heap, grows upward
stack
System stack, grows downward
www.digi.com
85
NET+OS section of the linker files
This table summarizes the NET+OS section of the linker files:
Section
Description
netosstack
Stack for each processing mode; grows downward. See the
init.s file.
free_mem
Used by the kernel to create the timer thread and root thread.
Note: Do not use this section for any other purposes.
initdata
Used to store switches.
nccdata
Used to store custom variables.
The ThreadX library is hard-coded to call tx_application_define (void
*first_unused_memory) after the kernel has been loaded and just before the
kernel scheduler starts.
The free_mem function creates the root thread responsible for starting NET+OS
and the IP stack. Do not pass any other address to create the root thread.
The first_unused_memory argument points to a global variable set up by the
kernel loading.
Memory aliasing in NET+OS
NET+OS aliases physical memory to four different locations in the address map.
This means that each physical word of memory appears at four different
addresses. This aliasing is done on all platforms. NET+OS configures one aliased
copy of memory for instruction cache on platforms that support cache. Code is
executed from this area of the address map to improve performance. NET+OS
uses uncached areas for general data storage.
The next figure shows the NET+OS memory map with cache enabled. In the
figure:
Physical memory is mapped four times in logical memory.
The NET+ARM internal registers appear once.
86
NET+Works with Green Hills BSP Porting Guide
Logical page 2 is used for instruction cache.
All addresses are in hexadecimal notation.
Physical memory
f0000000 NET+ARM internal registers
Overlays
Logical memory
NET+ARM registers
f0000000
Page 3
RAM: 32 MB
ROM: 1 or 2 MB
c000000
Cacheable
region 2
3000000
NVRAM: 8 KB
2000000
ROM: 1 or 2 MB
Page 2
ROM: 1 or 2 MB
RAM: 32 MB
Cacheable
region 1
8000000
RAM: 32 MB
0
Page 1
ROM: 1 or 2 MB
RAM: 32 MB
4000000
NVRAM: 8 KB
Page 0
ROM: 1 or 2 MB
RAM: 32 MB
In the diagram, page 0 contains a slot for up to 32 MB of RAM (using CS1 and CS2)
at address 0x0 through 0x1ffffff.
Either 1 or 2 MB of flash ROM on CS0 begin at 0x2000000, and 8 KB of NVRAM
starts at 0x3000000.
www.digi.com
87
The ROM and RAM spaces are remapped on pages 1, 2, and 3. For example:
Physical address
Which is
Can be accessed at
0x100
RAM
0x4000100, 0x8000100, and 0xC000100
0x20000100
Flash ROM
0x6000100, 0xA000100, and 0xE000100
0x3000100
NVRAM
Only at 0x3000100
Remapping memory allows the NET+ARM to select which data or instructions get
placed in cache.
Address mapping
The linker command files generated for each application set up an address map
so instructions are executed from the memory region that has been set up for
instruction cache, and normal data is located in non-cache memory.
If the address map changes, you need to change:
The constants in bsp.h and nacache.h
CS0, because the ROM sizes are hard-coded in init.s
The rom.lx and image.lx files in src\linkerScripts
88
NET+Works with Green Hills BSP Porting Guide
Hardware Dependencies
C
H
A
P
T
E
R
9
T
his chapter discusses the hardware dependencies for porting NET+OS to
application hardware.
89
Overview
To port NET+OS to your application hardware, there are specific dependencies
required in these areas:
DMA channels
Ethernet PHY
ENI controller
Serial ports
Software watchdog
Big Endian mode
System clock and timers
Interrupts
The rest of the sections in this chapter describe these hardware dependencies.
DMA channels
This table describes how each of the 13 DMA channels is used in porting
NET+OS.
90
Channel
Used by
What it does
1
Ethernet driver
Moves data from the Ethernet receiver to
memory. The Ethernet driver code is in the
bsp\devices\ethernet directory.
2
Ethernet driver
Moves data from memory to the Ethernet
transmitter.
3 through 6
Parallel ports
(NET+50)
For the NET+50 only. Moves data between
the parallel port and memory.
External peripherals
(NS7250)
For the NS7250 only. Only two channels—
either 3 and 5 or 4 and 6—can be
configured at one time.
NET+Works with Green Hills BSP Porting Guide
Channel
Used by
What it does
7 and 8
HDLC/serial/SPI driver
Receives data.
9 and 10
HDLC/serial/SPI driver
Transmits data.
11 through 13
Only available on the NS7520. Moves data
from memory to memory.
Ethernet PHY
NET+OS supports PHYs that use the MII interface. The PHY driver, which is
implemented in the mii.c file, supports these PHYs:
FastCat by Lucent Technologies (also known as the 3-volt Enable PHY)
LXT970 by Level One
LXT971A and LXT972A by Intel
AM79C874 and AM79C875 by AMD
You can modify the mii.c file to support additional PHYs.
ENI controller
The BSP configures the ENI controller for IEEE 1284 host port mode, which
supports four parallel ports.
To use ENI, disable the parallel driver, using either of these methods:
Recommended method: Undefine BSP_INCLUDE_PARALLEL_DRIVER in
the bsp.h file.
Alternate method: Remove the parallel driver entries from the device
driver table in the devices.c file.
www.digi.com
91
Serial ports
The BSP normally sets up both serial ports to support asynchronous RS-232style communications.
To use the serial peripheral interface (SPI) controller, disable the serial driver,
using either of these methods:
Recommended method: Undefine BSP_INCLUDE_SERIAL_DRIVER1 and
BSP_INCLUDE_SERIAL_DRIVER2 in the bsp.h file.
Alternate method: Remove the serial driver entries from the device
driver table in the devices.c file.
You do not need to disable the serial driver to use the HDLC driver.
Software watchdog
The watchdog device driver uses the internal watchdog if BSP_WATCHDOG_TYPE is
set to BSP_WATCHDOG_INTERNAL in bsp.h.
The NAReset routine in the nareset.c file uses the software watchdog to reset
the system. NAReset is called by the default implementation of customizeReset
in gpio.c.
Big Endian mode
The BSP supports Big Endian mode only.
System clock
The BSP system clock depends on whether you are using an external crystal or an
external oscillator. The external PLLTST* signal indicates the choice. The frequency
of the selected source affects the BSP timing.
92
NET+Works with Green Hills BSP Porting Guide
The PLL setting for the NS7520 is determined by the pull-up and pull-down
resistors tied to pins on the NS7520.
The rest of this section describes the constants you need to set for the system clock
in the bsp.h file.
PLLTST_SELECT
This setting determines the clock source to be used. PLLTST_SELECT is the address
input to the SYSCLK signal multiplexer, which has two possible sources:
TTL clock input applied to the XTAL1 pin
Crystal oscillator and PLL circuit
Set PLLTST_SELECT to either of these:
SELECT_THE_XTAL1_INPUT
SELECT_THE_CRYSTAL_OSCILLATOR_INPUT
The BSP defines this directive as the usesTheInternalOscillator function in the
settings.c file. Also, the BSP references the NetarmInitData table in the
settings.c file to return a value based on the usesInternalOscillator data
marker from the appropriate table entry.
XTAL1_FREQUENCY
This setting indicates the frequency of the TTL clock input to the XTAL1 pin. If
PLLTST_SELECT is set to SELECT_THE_XTAL1_INPUT, this signal generates the
internal SYSCLK signal.
CRYSTAL_OSCILLATOR_FREQUENCY
This setting indicates the frequency of the crystal oscillator. If PLLTST_SELECT is
set to SELECT_THE_CRYSTAL_OSCILLATOR_INPUT, this signal generates an input to
the PLL, and in conjunction with PLL_CONTROL_REGISTER_N_VALUE, determines
the frequency of the internal SYSCLK signal.
www.digi.com
93
PLL_CONTROL_REGISTER_N_VALUE
This setting indicates the N factor used in the divide-by circuits of the NET+ARM
clock generation section. The N factor multiplies or divides clock sources. The
value is stored in the PLLCNT field in the PLL Control register. (See the hardware
documentation for the NET+ARM.) The range of values is 0 through 15; the
suggested values are based on device type and revision.
The BSP defines this directive as the getPllValueBasedOnChipType function in
the settings.c file, and references the NetarmInitData table in the settings.c
file to return the PLL count number from the appropriate table entry.
System timers
The code that supports the system timers is in the bsptimer.c file. There are two
timers, as described here.
Timer 1
The BSP uses Timer 1 as the system heartbeat clock. The kernel uses the system
heartbeat clock for timing and pre-emption of tasks.
The frequency of the system heartbeat clock is controlled by the
BSP_TICKS_PER_SECOND constant in the bsp.h file. This value, which determines
the heartbeat rate, should be between 1 and 1000. A value of 100, for example,
provides a heartbeat rate of one tick every ten milliseconds.
Timer 2
The BSP uses Timer 2 to support the parallel driver. If this timer is disabled, or if
its frequency is changed, the parallel driver code in the narmpara.c file is affected.
Timer 2 normally is programmed to have a period of 217 microseconds.
If BSP_SERIAL_FAST_INTERRUPT is set in bsp.h, Timer 2 will be used by the serial
driver.
94
NET+Works with Green Hills BSP Porting Guide
Interrupts
This table describes how interrupt levels are used in the BSP:
Interrupt level
Use
31 (DMA 1)
Ethernet driver receive packet interrupt
30 (DMA 2)
Ethernet driver packet done interrupt
29 (DMA 3)
ENI FIFO receive packet interrupt
28 (DMA 4)
ENI FIFO transmit packet interrupt
27 and 26 (DMA 5 and 6)
Not used
25 (DMA 7)
HDLC driver channel 1 receive frame interrupt
Serial/SPI 1 DMA mode receive interrupt
24 (DMA 8)
HDLC driver channel 1 transmit frame interrupt
Serial/SPI 1 DMA mode transmit interrupt
23 (DMA 9)
HDLC driver channel 2 receive frame interrupt
Serial/SPI 2 receive interrupt
22 (DMA 10)
HDLC driver channel 2 transmit frame interrupt
Serial/SPI 2 transmit interrupt
21–17 (ENI ports 1–4 and
ENET RX)
Not used
16 (ENET TX)
Ethernet driver transmit interrupt
15 (SER 1 RX)
Serial/SPI driver port 1 receive interrupt
14 (SER 1 TX)
Serial/SPI driver port 1 transmit interrupt
13 (SER 2 RX)
Serial/SPI driver port 2 receive interrupt
12 (SER 2 TX)
Serial/SPI driver port 2 transmit interrupt
11 through 6
Not used
5 (Timer 1)
System clock tick interrupt
4 (Timer 2)
Not used
3 through 0 (PORTC)
Not used
www.digi.com
95
Memory map
NET+OS has the same memory map on all NET+Works development boards:
Addresses from 0xf0000000 to 0xffffffff are reserved for devices
internal to the NET+ARM.
RAM on CS1 and CS2 is mapped from address 0x0 to 0x01ffffff.
ROM on CS0 is mapped from address 0x02000000 to 0x021fffff.
NVRAM on CS3 is mapped from address 0x03000000 to 0x03001fff.
The BSP assumes that RAM is located at address 0x0, and it dynamically writes
the exception vector table to this location.
96
NET+Works with Green Hills BSP Porting Guide
Index
A
C
adding devices 46
C library startup 4
adding new flash 65
main routine 5
API internals, flash_id_table 62
C runtime environment 4
appconf.h file 6
changing interrupt priorities 13
application image header 71
CRYSTAL_OSCILLATOR_FREQUENC
Y 93
ARM linker 84
customization hooks 76
customize.c file 76
B
Cygwin standard C library
and device drivers 46
Big Endian mode 92
board initialization process
C library startup 4
hardware reset 2
D
NABoardInit routine 5
data aborts 11
ROM startup 3
ddi.h file 46
board support package. See BSP
debugging code from ROM 39
boot loader 68
default interrupt priorities 13
BSP
device driver functions
updating 24
deviceClose 53
bspconf.h file 6, 91
deviceConfig 54
bsptimer.c file 94
deviceEnter 49
deviceInit 50
deviceIoctl 59
I-
Index-1
deviceOpen 51
FIRQ interrupt 15
deviceRead 55
flash
support for larger flash 66
deviceWrite 57
deviceClose function 53
supported ROM parts 62
deviceConfig function 54
updating 61–66
deviceEnter function 49
flash table data structure 63
deviceInfo structure 46
flash, adding 65
deviceInit function 50
flash.h file 63, 65
deviceIoctl function 59
flash_id_table 62
deviceOpen function 51
deviceRead function 55
devices, adding 46
G
devices.c file 46, 91
getDefaultFilename routine 81
deviceWrite function 57
getMacAddress routine 78
DHCP/BOOTP client 68
Green Hills software
dialog.c file 7
linker file section 85
DMA channels, use when porting
NET+OS 90
system library modifications 60
downloadImage 82
H
hardware breakpoints 42
E
hardware dependencies
ENI controller 91
Big Endian mode 92
configured for IEEE 1284 mode 91
DMA channels 90
parallel driver 91
ENI controller 91
Ethernet
MAC addresses. See MAC address
PHY chip 91
Ethernet
PHY chip 91
interrupts 95
serial ports 92
software watchdog 92
F
system clock 92
fast interrupts 11
hardware interrupts 10
FIRQ handler 11, 15
hardware reset 2
installing 15
Index-2
system timers 94
fatal errors 11
I
MAX_SECTORS constant 66
ICE debugger 32
locking up 34
mii.c file 91
modifying the system library 60
in-circuit emulator 19
ind_io.c source file 60
init.s file 86
and IRQ handler code 15
installing a FIRQ handler 15
Interrupt Enable register 15
interrupt mode 10
interrupt priorities, changing 12
interrupt service routines 14
interrupt sources 13
Interrupt Status register 12, 15
interrupts 95
IRQ handler 10, 11–13
isImageValid routine 79
ISR. See interrupt service routines
N
na_isr.c file 13
na_isr.c file and IRQ handler code 15
NABoardInit routine 5
netosStartup routine 6
NADialog routine 7
naflash.c file 62
NAInstallIsr routine 14
NAReset routine 92
nareset.c file 92
narmpara.c file 94
NAUninstallIsr routine 14
ncc_init routine, debugging 41
NET+ARM
address lines 2
L
instruction 10
linker files
NET+OS
BSP operating modes 10
ARM linker 84
initialization configuration settings
2
Green Hills software section 85
NET+OS section 86
linker files for sample projects 84
locked up ICE 34
M
MAC addresses 19
main routine 5
MAX_SECTOR_SIZE constant 66
linker file section 86
netosStartup routine 6
P
parallel driver
disabling 91
support 94
timer 2 94
PHY chip 91
I-
Index-3
PLL_CONTROL_REGISTER_N_VALUE
94
system timers 94
generating a FIRQ interrupt 15
PLLTST_SELECT 93
parallel driver support 94
pre-fetch aborts 11
system heartbeat clock 94
priorities for IRQ handler interrupt
scheme 12
timer 1 94
timer 2 94
processor modes 10
purchasing MAC addresses 19
T
timing 92
R
rammain.c fil 76
related documentation xiii
U
reportError 77
undefined instructions 11
reset.s file and IRQ handler code 15
ROM part manufacturers 62
ROM startup 3
updating flash support 61–66
using the ICE debugger 32
V
S
serial driver, disabling 92
serial ports 92
servicing interrupts 12
vector addresses 11
vector table 10
settings.c file 93
W
shouldDownloadImage routine 80
watchdog 92
software watchdog 92
generating a FIRQ interrupt 15
supervisor mode 10
X
supported flash parts 62
XTAL1_FREQUENCY 93
supported PHYs 91
supporting larger flash configurations
66
system clock 92
system heartbeat clock 94
Index-4