Building an EZ-Host/OTG Project From Start to Finish
2
The most important portion of our start-up file is the _start
routine. This routine is intended to be run before main and is
loaded at the ORG location specified in the BAL.ld file. In its
simplest form, the _start code is just a jump to main. Code at
this location or the start of main will generally determine how
the task or main function interacts with the BIOS.
BAL.ld File Description
BAL.ld is a modified version of the default linker script. The
linker script contains commands for the linker to execute and
describes how the sections in the input files should map into
the output file. For example, the linker script tells where the
base address for code should reside.
A default linker script can be automatically generated by
typing “cy16-elf-ld --verbose > BAL.ld.” This command will
generate a default linker script file called BAL.ld that contains
everything our project needs and more. There are a few
simple changes that must be made to this default script for
our project (and other EZ-Host/OTG projects). These small
changes are listed below.
1. Change the base address for our code to start at. This can
be done by changing the “. =” statement following
SECTIONS to 0x1000. The 0x1000 location ensures that
we allow enough room for the GDB stub to be loaded when
in debug mode.
2. Anything that is not code in the file must be commented
out, because otherwise a parse error will occur when
linking. This includes the GNU version information in the
top of the default file and the “=======” lines at the top
and bottom of the file.
Buttons and Lights Without BIOS
The StartupNoBIOS.s file never returns control of the
processor to the BIOS. The BIOS first executes some initial-
ization routines such as setting up the stack and loading the
program. Then program execution begins at “_start” as
defined in the StartupNoBIOS.s file. StartupNoBIOS.s
contains a jump to main at “_start” where main is just a
“while(1)” loop that never returns.
Buttons and Lights With BIOS
Our Buttons and Lights example does not require the BIOS
to be running in the background (except initialization).
However, there are still some debug benefits to having the
BIOS running. When the BIOS is running, we can use some
simple Cypress-developed utility programs such as
qtsdump/qtudump to dump memory and qtsarena/qtuarena
to give memory usage information.
If BIOS is not running in the background, the BIOS IDLE chain
will not to execute. This means BIOS will never look for any
SCAN vectors on the UART or USB port. It is a requirement
for the BIOS to execute and look for SCAN vectors over the
UART or USB in order to use qtuload/qtsload or
qtuarena/qtsarena (see Binary Utilities Reference for more
information on these utilities).
There are many different ways to design our Buttons and
Lights application to run concurrently with BIOS running in the
background. Most of the suggested ways such as adding the
Buttons and Lights task into the IDLE chain are described in
USB Multi-Role Device Design by Example. We execute the
BIOS IDLE Task in a periodic Timer0 Interrupt.
To allow Timer0 to properly interrupt at a given interval and
vector to the proper ISR code, StartupWithBIOS.s makes the
appropriate initialization in “_start” before returning to BIOS
to complete initialization. In this example, we return to BIOS
instead of jumping directly to main. This is required so that
BIOS will finish initialization of the UART and USB. Instead of
jumping to main, our start-up code replaces the IDLER ISR
vector address with main. The IDLER ISR (now main) is
automatically called by BIOS upon finishing initialization.
Building the Example for Running with the
Debugger (GDB)
If a program is built to run with the debugger, then the build
process is different from code being built to run out of an
EEPROM.
Running code with GDB will allow for breakpoints, single
stepping, and other standard debug activities, in addition to
running Insight, the graphical user interface for GDB. To run
code with GDB, an Executable Linker Format (ELF) must be
generated. This is the default format of the GCC compiler and
is file-extension-independent. The only requirement is that
debug symbols need to be turned on. The following command
line instruction will generate a proper ELF file for use with
GDB. It is assumed that the CY3663 CD has been installed
and that BASH_ENV.BAT has been invoked to create a bash
shell environment. In addition, change the working directory
to that containing the Buttons and Lights files. Full details of
how to actually run the debugger are listed in both the
CY16.PDF and the USB Multi-Role Device Design by
Example book.
It should be noted that even though StartupNoBIOS.s is used,
the GDB stub that is loaded for debug will still execute the
BIOS IDLE chain. This is required to allow debug communi-
cation over USB or the UART.
[cy]$ cy16-elf-gcc -nostartfiles -g -TBAL.ld
StartupNoBIOS.s BAL.c -o BAL
• The above command will generate a file called “BAL” in the
ELF format. This file can then be used as an input when
invoking GDB.
• The “-nostartfiles” parameter tells the compiler/linker not to
use the default start-up code. Instead, we will supply
StartupWithBIOS.s as the start-up code to be used.
• The “-g” parameter instructs the compiler to turn on debug
symbols.
• The “-T” parameter tells the linker to use our supplied linker
script instead of the default.
• The “-o” parameter is followed by the output file name.
Building the Example for Running out of the
EEPROM
The build process is slightly more involved to create an image
that is ready to run out of an EEPROM. All of the steps are
listed below and can be entered at the command line in a
bash shell, or included in a script or Makefile. Since this
project is so small, a Makefile is not needed. For a Makefile
