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.

Copyright 2006 QUALCOMM Incorporated

Proprietary Statement
Updated: December 7, 2006

Page 2

BREW Device Primer 3.1

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 Windows-based Simulator

Required files for ARM Processor-based device Module Information File (MIF) BREW Applet Resource File (BAR) n/a Test Signature File (SIG)

Generated by BREW MIF Editor Module Information File (MIF) Generated by BREW Resource BREW Applet Resource File Editor (BAR) Visual Studio Generated by Test Signature Generator for the device and renamed Compiled and linked with ARM Compiler Dynamic Link Library (DLL) n/a

n/a

Module File (MOD)

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

Copyright 2006 QUALCOMM Incorporated

Proprietary Statement
Updated: December 7, 2006

Page 4

BREW Device Primer 3.1

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.

Copyright 2006 QUALCOMM Incorporated

Proprietary Statement
Updated: December 7, 2006

Page 5

BREW Device Primer 3.1

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

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 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 aeemod~1.o c:\PROGRA~1\BREW31~1.5\sdk\src\aeemod~1.c ----------------------------------------------------------------------------------------------------------------------------OBJECT MYFIRS~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 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.

Copyright 2006 QUALCOMM Incorporated

Proprietary Statement
Updated: December 7, 2006

Page 7

BREW Device Primer 3.1

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. 2. 3. Connect your device to your PC using a data cable. Ensure the device is powered on. 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 devices 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. 2. 3. 4. In Windows Explorer, create a subfolder within the myfirstapp folder, named appfiles. Copy the SIG file for your device into this folder, and rename it as myfirstapp.sig. Copy the myfirstapp.bar, myfirstapp.mif and myfirstapp.mod files to this folder. 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.

Copyright 2006 QUALCOMM Incorporated

Proprietary Statement
Updated: December 7, 2006

Page 11

BREW Device Primer 3.1

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.

Copyright 2006 QUALCOMM Incorporated

Proprietary Statement
Updated: December 7, 2006

Page 12

BREW Device Primer 3.1

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.

Copyright 2006 QUALCOMM Incorporated

Proprietary Statement
Updated: December 7, 2006

Page 13

BREW Device Primer 3.1

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.

Copyright 2006 QUALCOMM Incorporated

Proprietary Statement
Updated: December 7, 2006

Page 15

BREW Device Primer 3.1

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.

Copyright 2006 QUALCOMM Incorporated

Proprietary Statement
Updated: December 7, 2006

Page 17

BREW Device Primer 3.1

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. 2. 3. 4. 5. Right click on My Computer. Select Properties, then select the Hardware tab. Select Device Manager. Expand Modems and right-click on any specific modem's properties. 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. 2. Select the correct port and the BTIL interface. 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 devices 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.

Copyright 2006 QUALCOMM Incorporated

Proprietary Statement
Updated: December 7, 2006

Page 19

BREW Device Primer 3.1

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

Copyright 2006 QUALCOMM Incorporated

Proprietary Statement
Updated: December 7, 2006

Page 21