BREW Device Primer: Running Your BREW Application On A Device

BREW® Device Primer 3.
BREW Device Primer: Running Your BREW Application on a Device

The BREW Device Primer is the second in a series of primers teaching how to develop in BREW, building on
the first primer, the BREW Programming Primer. In the BREW Programming Primer you learned how to
develop and run a BREW application on the BREW Simulator. In this primer you will build on that BREW
application by learning how to compile your BREW application into ARM code, download the BREW
application to the device, and run and debug your application on the device. It is not necessary to have
completed the BREW Programming Primer, but it is recommended if you are not familiar with BREW
programming.
Copyright© 2006 QUALCOMM Incorporated

Proprietary Statement
Updated: December 7, 2006
Page 1
BREW® Device Primer 3.1
BREW Setup
The following steps must be completed to run your application on a BREW device.
 Setup your device environment:
Obtain a BREW 3.1 device, data cable, and driver.
Become an authenticated BREW developer.
Obtain the myfirstapp files at the BREW 3.1 Developer's Technical web site. Myfirstapp is a
BREW application developed in the BREW Programming Primer.
For the purposes of this primer, it is assumed you are using Visual Studio .NET 2003.
You should have the BREW SDK® 3.1 and the BREW SDK Tools 1.0.1 installed on your
machine. The ARM Makefile Generator and the GNU Makefile Generator are installed as part
of the BREW Add-ins for Microsoft Visual Studio in the BREW SDK Tools. If the Makefile
Generators are not visible on the toolbar, see the BREW SDK Tools User Docs (Using BREW
add-in toolbar buttons for 6.0) included with the BREW Tools package for instructions on
enabling the Add-ins.
Install the BREW Tools Suite. The BREW Tools Suite is a group of tools, including the BREW
Application Loader (AppLoader), BREW Logger, and BREW Application Signer (AppSigner),
used to test your BREW applications and prepare them for commercialization.
Generate a test signature file using the BREW TestSig Generator (TestSig Generator). The
TestSig Generator provides a digital signature that allows a developer to test an application on
a BREW device.
 Install an ARM compiler to compile and link your application into native code for the BREW device.
 Load the application files to a BREW device using the BREW AppLoader and run the application on
the device.
 Debug your application.
NOTE: Most of the tools mentioned in the Device Primer are available at the BREW 3.1 Developer's Technical
web site under BREW Devices.
Test-Enabling
BREW devices running versions of BREW preceding 3.1 needed to be physically modified (test-enabled) to
enable developers to upload files to the device. BREW 3.1 devices are test-enabled by default, therefore
test-enabling is no longer necessary for BREW 3.1 devices and newer.

Page 2
Device Compilers
To run your application on a BREW device, your source code needs to be compiled for the device ARM
processor. The ARM linker produces an ARM ELF format executable file, which the BREW Elf2mod
post-linker tool converts to a BREW module (MOD) file. A MOD file is a native binary executable file loaded to
the device to run your application.
When developing your application, you build modules in two ways. Initially you use Microsoft Visual Studio to
build Dynamically Linked Libraries (DLL) you invoke through the BREW Simulator. You then build your
modules using the ARM compiler, resulting in MOD files that you transfer to the device.
The following table shows the files used to run an application on the Simulator versus the files used to run an
application on a device. The DLL used to run the application on the Simulator is not used by the device, the
DLL is replaced by the MOD file.
File source Required files for Required files for ARM

Windows-based Simulator Processor-based device
Generated by BREW MIF Editor Module Information File (MIF) Module Information File (MIF)
Generated by BREW Resource BREW Applet Resource File BREW Applet Resource File
Editor (BAR) (BAR)
Visual Studio Dynamic Link Library (DLL) n/a
Generated by Test Signature n/a Test Signature File (SIG)

Generator for the device and
renamed
Compiled and linked with ARM n/a Module File (MOD)

Compiler
The following three compilers are compatible with BREW devices.
 The ARM Developer Suite is a complete software development solution for creating applications for
ARM architecture. The ARM Developer Suite ships as part of the RealView Development Suite, which
is a complete solution for software development that supports all ARM processors and ARM debug
technology.
 RealView Compilation Tools for BREW is based on the popular compiler, linker, and assembler
components of the ARM Developer Suite version, but are specifically designed to target the BREW
environment. Both the ARM Developer Suite and RVCT for BREW can be obtained from the ARM
web site.
 The GNU Cross Compiler for ARM is a free, open-source compiler that is available, but not officially
supported by BREW technical support.
This primer focuses solely on compiling the application for the device using the ARM compiler. For more
information about the different available compilers visit the BREW 3.1 Developer's Technical web site. There is
also a compiler forum provided by QUALCOMM for developers.
NOTE: The ARM compiler should be installed in a path that doesn't contain any spaces.
Page 3
Page 4
BREW Elf2mod
BREW Developers should be aware that as of BREW 3.1, you are unable to use static and global data in
BREW applications without the latest release of BREW Elf2mod. The Elf2mod tool is a post-linker tool that
converts ARM Executable Linking Format (ELF) files to self-relocatable BREW module (MOD) files. The
latest release of Elf2mod enables the use of static and global data in BREW applications by producing
self-relocatable BREW modules. Elf2mod works with GNU and ARM tool chains.
Executable Linking Format (ELF)
ELF object-format represents control data in an object file. ELF is the industry standard binary file format
used by ARM, generated by the ARM object producing tools such as armcc and armasm. ELF is
platform-independent and includes among its capabilities dynamic linking and loading, imposing runtime
control on a program, and an improved method for creating libraries.
The use of Elf2mod is out of the scope of the Device Primer. The Elf2mod usage documentation packaged
with the installation includes information on implementation and error messages.

Page 5
Compile and Link Application

Before you can load your application to the device, your source code needs to be compiled using the ARM
compiler. Compilation with the ARM compiler requires an appropriate makefile, which can be generated using
the automated makefile wizard in the BREW Add-ins for Microsoft Visual Studio. A makefile defines the
location of source files and how they will be compiled and linked to create the executable.
Generate makefile with Visual Studio Add-in
The BREW Add-in for Visual Studio allows you to generate a makefile for your BREW application, and
automates the task of finding and fixing errors during the compilation. For more information see the BREW
Visual Studio Addins document included with the BREW SDK Tools User Docs included with the BREW
SDK Tools package.
1. To avoid errors be sure that you have setup the environment variables necessary for makefile before
starting Visual Studio and opening up the command prompt.
 BREWDIR should be set to the desired BREW SDK installation directory.
 ARMHOME and ADSHOME should be set to the ARM installation directory.
2. Load the myfirstapp application in a Visual Studio .NET 2003 workspace.
3. Click the Generate ARM Makefile toolbar button to generate the makefile.
A dialog box appears informing you that the makefile has been generated.
Generate the MOD file
To create the ARM executable myfirstapp.mod file, open a MS-DOS command prompt. Navigate to the
myfirstapp directory, and enter nmake /f myfirstapp.mak all. This invokes the nmake utility with
your makefile and compiles the application for ARM. Nmake is a utility that comes with Visual Studio that
reads and executes makefiles and automates repetitive tasks.
You can clean the directory by typing nmake /f myfirstapp.mak clean.
Sample Output
The following is sample compiler output from the nmake utility, using the ARM Developer Suite 1.2.
C:\Program Files\BREW 3.1.5\sdk\examples\myfirstapp>nmake /f

myfirstapp.mak all
Page 6
Microsoft (R) Program Maintenance Utility Version 6.00.8168.0
Copyright (C) Microsoft Corp 1988-1998. All rights reserved.
---------------------------------------------------------------
OBJECT aeeapp~1.o
C:\Apps\ADS120\Bin\armcc -c -DDYNAMIC_APP -cpu ARM7TDMI -apcs

/ropi/interwork/norwpi -littleend -zo -fa -g -Ospace -O2 -I.
-IC:\PROGRA~1\BREW31~1.5\sdk\inc -I C:\PROGRA~1\BREW31~1.5\sdk\inc -o
aeeapp~1.o c:\PROGRA~1\BREW31~1.5\sdk\src\aeeapp~1.c
---------------------------------------------------------------
---------------------------------------------------------------
OBJECT aeemod~1.o

aeemod~1.o c:\PROGRA~1\BREW31~1.5\sdk\src\aeemod~1.c
---------------------------------------------------------------
---------------------------------------------------------------
OBJECT MYFIRS~1.o

MYFIRS~1.o c:\PROGRA~1\BREW31~1.5\sdk\examples\MYFIRS~1\MYFIRS~1.c
---------------------------------------------------------------
---------------------------------------------------------------
TARGET myfirstapp.elf
C:\Apps\ADS120\Bin\armlink -o myfirstapp.elf -ropi -rwpi -entry

0x8000AEEAPP~1.o AEEMOD~1.o MYFIRS~1.o -first AEEMod_Load
---------------------------------------------------------------
TARGET myfirstapp.mod
C:\Apps\ADS120\Bin\fromelf myfirstapp.elf -o
myfirstapp.modC:\Program Files\BREW 3.1.5\sdk\examples\myfirstapp>
Some steps you can take to resolve linking errors encountered during the compilation process include
reading the BREW API reference to verify that you are using the correct names for BREW constants,
methods, interfaces and structure members. The API reference also contains a listing of the required header
files for each interface. If header files are not included, the compiler cannot recognize the symbols specified
in the code. Ensure that linking is performed against the proper library versions by properly specifying your
BREWDIR environment variable for the targeted version of BREW.

Page 7
Load Application Files

You will be using the AppLoader to load your application files to the device. If your device does not have a
test signature file (SIG) in the device file system, you will need to use the BREW TestSig Generator to
generate the SIG file.
BREW Test Signature file
The TestSig Generator is a web-based tool that generates a digital signature file necessary to start your
application on a device. Each device you develop for requires a test signature that uniquely identifies the
device. One test signature can be used for multiple applications on the same device. When you transfer the
application files you can transfer the SIG file as part of the module, which also includes the MOD, MIF and
BAR files.
You will need the hexadecimal ESN corresponding to the device. The ESN is of the format 0xaabbccdd.
Alternatively, you can use the 15-digit International Mobile Equipment Identifier (IMEI) or a Mobile Equipment
IDentifier (MEID) to generate the test signature.
NOTE: Once you have generated your test signature file, remember to click Download.
Connecting to the device using AppLoader
1. Connect your device to your PC using a data cable.
2. Ensure the device is powered on.
3. Open AppLoader, installed with the BREW Tools Suite. A dialog box opens prompting you to select
the port your device is connected to and the BREW version of your device.
Page 8
NOTE: If you are connecting to your device using the BREW Tools Interface Layer (BTIL), you will be
connecting to the device with a different interface and port. For more information please see the
appendix.
If you are unable to connect to the device you may have selected an incorrect device connection. For
troubleshooting tips refer to the Troubleshooting section of the BREW Apploader Help guide included
with the BREW Tools Suite package.
After connecting to the device, the AppLoader shows the device’s BREW file system.
NOTE: The BREW root directory may vary on some devices, this primer uses brew/mod/ as the root
directory.
NOTE: Some versions of BREW require the names of all files and folders in lower case and no spaces within
the device's file system.
Module Loading
When loading files to the device you can load them as a module, as this primer demonstrates. You can also
Page 9
load the files individually by dragging them from your directory into the device directory.
To load the entire application module to the device using AppLoader:
1. In Windows Explorer, create a subfolder within the myfirstapp folder, named appfiles.
2. Copy the SIG file for your device into this folder, and rename it as myfirstapp.sig.
3. Copy the myfirstapp.bar, myfirstapp.mif and myfirstapp.mod files to this folder.
4. Within Apploader select Module > New.
A dialog box opens prompting you to browse for the Module Directory you would like to load to the device,
and the Module Name.
5. Within the dialog box browse to the folder containing the MIF, MOD, BAR and SIG file, and specify
myfirstapp as the Module Name.
6. Click OK.
AppLoader creates a myfirstapp folder in the module directory containing the MOD, SIG and BAR file.
AppLoader places myfirstapp.mif within the brew/mif file.
Page 10
NOTE: See the appendix for more information on BREW file extensions.
The device must be reset before you can run your application. This can be done by either power-cycling the
device, or selecting Device > Reset from the AppLoader menu. After resetting your device, start your
application within the BREW environment.
Warning: You must have a valid test signature in your application directory, or your application is deleted
when you power-cycle the phone.
Warning: For security reasons the AppLoader cannot rename files directly on the handset or copy certain
file types to your PC.

Page 11
Run Application
To run your application after loading the application to the device, you will need to reset the device. This can
be done using the reset button in AppLoader, or you can reset the device manually by power cycling the
device.
After resetting the device start the application through the BREW Application Manager interface on your
device. The BREW Application Manager is used by subscribers to purchase and manage BREW applications
on the device. Your carrier may have given the BREW Application Manager a proprietary name. The
procedure to invoke the BREW Application Manager varies between device models and carriers; check your
device manual if you have questions on the proper sequence. Due to the characteristics of the mobile
environment, your application may not work as anticipated.
See the appendix for information on troubleshooting and error codes.

Page 12
Debugging Overview
It is strongly recommended that you properly test your application before submitting it for TRUE BREW
Testing. BREW provides a number of options for debugging your application on the device. The Device Primer
provides a general overview of some device debugging tools. Testing and debugging are discussed in more
detail in the third primer in this series, the BREW Test and Automation Primer. Three tools discussed here
for device debugging include the BREW Debugger, DBGPRINTF and the BREW Logger.
 The BREW Logger is part of the BREW Tools Suite. It allows you to see DBGPRINTF() messages
on your PC while debugging on the device. With the Logger, you can configure a message log, log
messages and view to a log file. For more information, refer to the BREW Logger Help document
included with the BREW Tools Docs as part of the BREW Tools Suite download.
 ILogger is a module that provides the general logging interface for the AEE layer. It enables you to
send log items to a file, the serial port, and the BREW Simulator output window. ILogger provides a
standardized data logging interface for logging using a range of transport mechanisms
 The BREW Debugger is comprised of a client running on the device and a Windows-based GUI that
allows developers to execute classical debugging commands on code running on the target.
 DBGPRINTF() is a function used to output debugging information. It can be implemented different

ways on different platforms, and is helpful for inspecting the value of variables and debugging the
application flow of control. You can use the Debugger to output text either to the Visual Studio output
pane if you are running in the Debugger, or to a window in the Simulator. See the BREW API
Reference for more details.

Page 13
BREW Logger
The BREW Logger allows you to record and filter DBGPRINTF() data, record and filter ILogger binary data,
view log information at runtime, save log information to file, manage log file size, record time and format, and
provides Perl support via BREW Perl interfaces.
Running BREW Logger
1. Navigate to your location of the BREW Tools Suite and open the BREW Logger.
You are automatically prompted with a connection window.
2. Select the port the device is connected to and click OK.
NOTE: If you are connecting to your device using the BREW Tools Interface Layer (BTIL), you will be
connecting to the device with a different interface and port. For more information please see the appendix.
3. To begin logging select Configure > Start Logging, or select the icon on the toolbar as seen
below.
The BREW Logger dialog box opens, showing the DBGPRINTF messages.
Page 14
To pause the logging output in the Log Output dialog box, click Pause Display.
A Resume Window dialog box appears. Click it to start the logging again.
To stop the logging output in the Log Output dialog box, click Configure > Stop Logging.
A dialog box opens asking if you wish to continue. Click OK.
This process displays information printed using DBGPRINTF() while running on the BREW device, facilitating
the debugging process. Certain features of the BREW Logger are scriptable with Perl. For more information
and troubleshooting tips see the BREW Logger Help guide, included with the BREW Tools Docs in the
BREW Tools Suite installation.

Page 15
Device Problems
While some applications may run on the Simulator, they may have different results on the device itself. The
device runs on ARM architecture which poses some limitations that the developer needs to be aware of when
developing BREW applications. Here we briefly discuss some of those limitations and explore some solutions
to those limitations.
Floating point operations in BREW
BREW hardware does not support a floating-point unit, therefore BREW applications cannot use floating point
data types or operations. Attempting to use floating point operations within BREW will cause an ARM linker
error.
To work around this issue it is possible to define callouts with the ARM compiler used to determine the
location of a writable area of memory in lieu of the floating point status register and errno address.
Applications may use floating point data types without the floating point helper functions by linking the
floats.o object file (which performs these tasks) into the project. the Floating Point Operations in BREW
online knowledge base article contains the floats.o file.
The ARM methods for controlling the floating-point environment are listed in the fenv.h and rt_fp.h header files
(found under the ARMINC directory). These methods allow the application to modify such floating point
behavior as rounding mode used in calculations, and inspect the status word for error conditions.
Before performing any floating point operations, the application should call _fp_init() (found in rt_fp.h). This
method initializes the floating point status register with known values.
For more information go to the online knowledge base for the floating point operations in BREW article.
Using STDLIB functions
C library functions in BREW may not function as expected unless the developer initializes the C run-time
libraries. BREW does not initialize the C run-time libraries for dynamically loaded modules.
BREW substitutes the functionality for the standard C library functions with BREW-specific functions and
macros. There are functions for string manipulation, file I/O, memory allocation, and most other common
operations normally found in the Standard C Library. Use AEE Memory Services and Standard Library
macros (in AEEStdLib.h). For example, use MALLOC() to allocate memory, WSTRCPY() to make a copy of
Unicode (wide) string. See the BREW API reference for more information. BREW does not offer support for
developers using the standard C library.
Watchdog timer
The BREW device environment limits the amount of time any process may run without yielding through a
watchdog timer. If your application trips this watchdog timer, the application terminates, and the handset may
power-cycle. Many factors can cause your application to trigger the watchdog timer, though the most
common culprit is improper looping within your application. BREW uses an event-driven application model, so
a program should never implement busy-waiting or perform loops that are likely to monopolize the processor
for extended periods.
Memory alignment
Improperly aligned memory accesses on the ARM processor cause a performance penalty. In the ARM
environment, 16-bit quantities must be at even addresses, and 32-bit quantities must be at addresses
divisible by 4. Members of structures must be properly aligned as well; the ARM compiler automatically pads
structures to ensure that all members are correctly aligned. Generally the best way to conserve space in a
Page 16
structure is to declare the members in order of decreasing size; this minimizes the amount of padding
inserted by the compiler while retaining proper member alignment. For more information see the online
knowledge base article on memory alignment.
Heap usage
Applications running in BREW may fail if proper precautions are not taken to verify that heap memory
allocations complete successfully. BREW applications should always inspect the return value of any
dynamic memory operations to ensure that the result is valid, and the application should exit gracefully after
detecting an error. For more information see the online knowledge base article on failing to optimize code to
avoid heap fragmentation.
Stack usage
Care should be taken to minimize the stack usage on the BREW device. Most devices have a relatively small
stack space, so overrunning the stack is very possible if proper programming techniques are not used.
 Avoid deep recursive chains. Each recursive call has the overhead of an additional stack frame, which
can quickly fill the stack.
 Minimize the use of large automatic variables. If possible, shift local buffers and automatic variables
used across multiple methods to the applet structure. This relocates the allocated memory from the
stack to the heap. Use pointers to pass structures to methods; this prevents the structure from being
copied on the resulting stack frame.
For more information see the online knowledge base article on stack usage.
Static constants
There should be no static or global data in the application. Variables and data that need to be available to the
program as a global can be stored in the application's internal structure. Static data can be emulated using
the Applet Data structure. The applications should be built without static or global data and generate
position-independent code. Since it's possible for the compiler libraries to introduce globals of their own, you
should check the map file after building your application to make sure there aren't any data segments flagged
as read/write.
NOTE: The latest release (1.0.2.) of BREW Elf2mod permits the use of static data in BREW modules.
Unexpected behavior on a particular device
Some devices have known issues that cause undesirable behavior in BREW. General recommendations
include allocating as little memory as possible, make sure the MIF has permissions set correctly, and
prepare for any bizarre usage case by handling every possible error.

Page 17
BREW Tools Interface Layer (BTIL)

The BREW Tools Interface Layer (BTIL) is a packet-based transport protocol that allows communication
between a host PC and one or more client BREW devices. It was designed as a foundation for test
automation and provides a published C and C++ API set that developers can use to write custom PC
applications to test their BREW applications.
BTIL Client Installer
The BTIL Client Installer can be used to verify whether BTIL is installed on your device, and to install BTIL on
the device. A shortcut to the BTIL Development Kit is placed in the Start menu. To open the BTIL Client
Installer navigate to start > BTIL Development Kit > Client Installer. Be sure that you are connecting with
the correct port. For more information refer to the ReadMeFirst.txt document included with the BTIL package.
Test Signature Repository
Test signatures for the device used with BTIL should be placed in the Test Signature Repository, a shortcut to
which is in the Start Menu under the BTIL folder. The naming convention for signature files in this folder is the
device serial number (ESN, IMEI, or MEID) without a leading "0x", for example "12345678.sig". During the
initial connection process with BTIL, the BTIL client running on the device will request a test signature from
the BTIL server, which checks for the signature file in the Test Signature Repository. If the required test
signature is not found, a connection failure will occur.
Locating the port
Connecting to a device with BTIL uses a different port than connecting with the QCOMOEM DLL.
To check which port;
1. Right click on My Computer.
2. Select Properties, then select the Hardware tab.
3. Select Device Manager.
4. Expand Modems and right-click on any specific modem's properties.
5. Click on the Modem tab. You should see the port listed at the top.
Connecting to the device using BTIL
Upon connection to a BREW device, you are prompted to select a port and an interface.
1. Select the correct port and the BTIL interface.
2. Click OK.
Page 18
NOTE: If you are unable to connect to the device using BTIL, you may be missing your test signature file.
BTIL requires a valid test signature to run on the device. Test Signatures for the device should be in the Test
Signature Repository.
After connecting to the device the AppLoader shows the device’s BREW file system.
Refer to the ReadMeFirst.txt document included with the BTIL installation package for more information about
connecting to your device using BTIL.

Page 19
Troubleshooting
Some common issues BREW developers run into may include signature failures, error codes and messages.
Signature failures
When launching your application on the device a problem with the test signature will generate the following
message: "Application Digital Signature Failure ####".
Any errors in your test signature result in a digital signature failure when you launch your application. Some
of the common causes for signature failures are:
 Signature file missing - No signature file was found. Ensure that a signature file is generated and
placed within the application directory.
 Expired signature - Try generating a new signature file. The lifetime on the previous signature may
have expired. Also verify that your handset has the proper date and time set.
 Invalid ESN - Check that your signature was generated using the proper ESN. If an error was made
during signature generation, you must generate a new signature with the correct ESN.
Interpreting error codes
When an application returns a specific error code to indicate the cause of the failure, you must refer to the
AEEError.h file included with the BREW SDK to figure out the meaning for a given value. The error codes are
defined in the header of AEEError.h.
NOTE: Error values in the AEEError.h file are given in the form of a decimal offset number added to a
hexadecimal base error code. To find the actual error code value, you may need to perform a conversion
between decimal and hexadecimal before performing the addition. For example,
AEE_NET_ECONNREFUSED is defined as NET_ERROR_BASE+17, where NET_ERROR_BASE is 0x200.
In this case, the actual error code would be 0x211 = 529, NOT 0x217 = 535.
Common error messages
"Undef Inst Exception" stands for "Undefined instruction exception". The message means that the program
pointer has jumped to a code segment containing an undefined instruction. Memory corruption, stack overrun,
or version-related incompatibilities between applet code and the BREW image on the phone can cause this
error message. Remove the battery to clear the phone.
"Re-entrant Data Abort" exception may be the result of stack overrun. Reduce the size or number of objects
on the stack, and use objects allocated on the heap instead of automatic variables.
"Pref Abort Exception" exception may be the result of data corruption and stack overrun.
"SWI Exception" exception may be the result of heap memory corruption by overwriting the bounds of
allocated arrays, freeing objects more than once, or writing to wild or NULL pointers.
"Unknown Error (1)" occurs when the ClassID in the application code does not match the Class ID specified
in the MIF.
For more troubleshooting information refer to the BREW 3.1 Developer's Technical web site.
Page 20
Page 21

BREW Device Primer: Running Your BREW Application On A Device

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

BREW Device Primer: Running Your BREW Application On A Device

Uploaded by

Copyright:

Available Formats

BREW® Device Primer 3.

BREW Device Primer: Running Your BREW Application on a Device

Copyright© 2006 QUALCOMM Incorporated

 Setup your device environment:

Obtain a BREW 3.1 device, data cable, and driver.

Become an authenticated BREW developer.

 Debug your application.

Copyright© 2006 QUALCOMM Incorporated

File source Required files for Required files for ARM

Visual Studio Dynamic Link Library (DLL) n/a

Generated by Test Signature n/a Test Signature File (SIG)

Compiled and linked with ARM n/a Module File (MOD)

The following three compilers are compatible with BREW devices.

Executable Linking Format (ELF)

Copyright© 2006 QUALCOMM Incorporated

Compile and Link Application

Generate makefile with Visual Studio Add-in

 BREWDIR should be set to the desired BREW SDK installation directory.

 ARMHOME and ADSHOME should be set to the ARM installation directory.

2. Load the myfirstapp application in a Visual Studio .NET 2003 workspace.

Generate the MOD file

You can clean the directory by typing nmake /f myfirstapp.mak clean.

C:\Program Files\BREW 3.1.5\sdk\examples\myfirstapp>nmake /f

Copyright (C) Microsoft Corp 1988-1998. All rights reserved.

C:\Apps\ADS120\Bin\armcc -c -DDYNAMIC_APP -cpu ARM7TDMI -apcs

C:\Apps\ADS120\Bin\armcc -c -DDYNAMIC_APP -cpu ARM7TDMI -apcs

C:\Apps\ADS120\Bin\armcc -c -DDYNAMIC_APP -cpu ARM7TDMI -apcs

C:\Apps\ADS120\Bin\armlink -o myfirstapp.elf -ropi -rwpi -entry

Copyright© 2006 QUALCOMM Incorporated

Load Application Files

BREW Test Signature file

Connecting to the device using AppLoader

1. Connect your device to your PC using a data cable.

2. Ensure the device is powered on.

To load the entire application module to the device using AppLoader:

3. Copy the myfirstapp.bar, myfirstapp.mif and myfirstapp.mod files to this folder.

4. Within Apploader select Module > New.

AppLoader places myfirstapp.mif within the brew/mif file.

Copyright© 2006 QUALCOMM Incorporated

See the appendix for information on troubleshooting and error codes.

Copyright© 2006 QUALCOMM Incorporated

 DBGPRINTF() is a function used to output debugging information. It can be implemented different

Copyright© 2006 QUALCOMM Incorporated

Running BREW Logger

You are automatically prompted with a connection window.

2. Select the port the device is connected to and click OK.

A dialog box opens asking if you wish to continue. Click OK.

Copyright© 2006 QUALCOMM Incorporated

Floating point operations in BREW

Using STDLIB functions

Unexpected behavior on a particular device

Copyright© 2006 QUALCOMM Incorporated

BREW Tools Interface Layer (BTIL)

BTIL Client Installer

Test Signature Repository

Locating the port

1. Right click on My Computer.

2. Select Properties, then select the Hardware tab.

3. Select Device Manager.

4. Expand Modems and right-click on any specific modem's properties.

Connecting to the device using BTIL

1. Select the correct port and the BTIL interface.

Copyright© 2006 QUALCOMM Incorporated