device primer

BREW® Device Primer 3.1

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 onthe first primer, the BREW Programming Primer. In the BREW Programming Primer you learned how todevelop and run a BREW application on the BREW Simulator. In this primer you will build on that BREWapplication by learning how to compile your BREW application into ARM code, download the BREWapplication to the device, and run and debug your application on the device. It is not necessary to havecompleted the BREW Programming Primer, but it is recommended if you are not familiar with BREWprogramming.

Copyright© 2006 QUALCOMM IncorporatedProprietary Statement

Updated: December 7, 2006


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 aBREW 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 yourmachine. The ARM Makefile Generator and the GNU Makefile Generator are installed as partof the BREW Add-ins for Microsoft Visual Studio in the BREW SDK Tools. If the MakefileGenerators are not visible on the toolbar, see the BREW SDK Tools User Docs (Using BREWadd-in toolbar buttons for 6.0) included with the BREW Tools package for instructions onenabling the Add-ins.

Install the BREW Tools Suite. The BREW Tools Suite is a group of tools, including the BREWApplication 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). TheTestSig Generator provides a digital signature that allows a developer to test an application ona 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 onthe device.

Debug your application.

NOTE: Most of the tools mentioned in the Device Primer are available at the BREW 3.1 Developer's Technicalweb site under BREW Devices.

Test-Enabling

BREW devices running versions of BREW preceding 3.1 needed to be physically modified (test-enabled) toenable developers to upload files to the device. BREW 3.1 devices are test-enabled by default, thereforetest-enabling is no longer necessary for BREW 3.1 devices and newer.



https://brewx.qualcomm.com/brew/sdk/download.jsp?page=dx/en/brew31/ad/do/sample_myfirstapp

https://brewx.qualcomm.com/brew/sdk/download.jsp?page=dx/en/brew31/ad/do/programming_primer

https://brewx.qualcomm.com/brew/sdk/download.jsp?page=dx/en/brew31/bd/tl/toolssuite

https://brewx.qualcomm.com/brew/sdk/download.jsp?page=dx/en/brew31/bd/tl/overview


Device Compilers

To run your application on a BREW device, your source code needs to be compiled for the device ARMprocessor. The ARM linker produces an ARM ELF format executable file, which the BREW Elf2modpost-linker tool converts to a BREW module (MOD) file. A MOD file is a native binary executable file loaded tothe device to run your application.

When developing your application, you build modules in two ways. Initially you use Microsoft Visual Studio tobuild Dynamically Linked Libraries (DLL) you invoke through the BREW Simulator. You then build yourmodules 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 anapplication on a device. The DLL used to run the application on the Simulator is not used by the device, theDLL is replaced by the MOD file.

File source Required files forWindows-based Simulator

Required files for ARMProcessor-based device

Generated by BREW MIF Editor Module Information File (MIF) Module Information File (MIF)

Generated by BREW ResourceEditor

BREW Applet Resource File(BAR)

BREW Applet Resource File (BAR)

Visual Studio Dynamic Link Library (DLL) n/a

Generated by Test SignatureGenerator for the device andrenamed

n/a Test Signature File (SIG)

Compiled and linked with ARMCompiler

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 forARM architecture. The ARM Developer Suite ships as part of the RealView Development Suite, whichis a complete solution for software development that supports all ARM processors and ARM debugtechnology.

RealView Compilation Tools for BREW is based on the popular compiler, linker, and assemblercomponents of the ARM Developer Suite version, but are specifically designed to target the BREWenvironment. Both the ARM Developer Suite and RVCT for BREW can be obtained from the ARMweb site.

The GNU Cross Compiler for ARM is a free, open-source compiler that is available, but not officiallysupported by BREW technical support.

This primer focuses solely on compiling the application for the device using the ARM compiler. For moreinformation about the different available compilers visit the BREW 3.1 Developer's Technical web site. There isalso a compiler forum provided by QUALCOMM for developers.

NOTE: The ARM compiler should be installed in a path that doesn't contain any spaces.

https://brewx.qualcomm.com/brew/sdk/download.jsp?page=dx/en/brew31/bd/tl/compilation

http://brewforums.qualcomm.com/forumdisplay.php?s=&forumid=43


BREW Elf2mod

BREW Developers should be aware that as of BREW 3.1, you are unable to use static and global data inBREW applications without the latest release of BREW Elf2mod. The Elf2mod tool is a post-linker tool thatconverts ARM Executable Linking Format (ELF) files to self-relocatable BREW module (MOD) files. Thelatest release of Elf2mod enables the use of static and global data in BREW applications by producingself-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 formatused by ARM, generated by the ARM object producing tools such as armcc and armasm. ELF isplatform-independent and includes among its capabilities dynamic linking and loading, imposing runtimecontrol 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 packagedwith the installation includes information on implementation and error messages.



https://brewx.qualcomm.com/brew/sdk/download.jsp?page=dx/en/brew31/bd/tl/elf2mod


Compile and Link Application

Before you can load your application to the device, your source code needs to be compiled using the ARMcompiler. Compilation with the ARM compiler requires an appropriate makefile, which can be generated usingthe automated makefile wizard in the BREW Add-ins for Microsoft Visual Studio. A makefile defines thelocation 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, andautomates the task of finding and fixing errors during the compilation. For more information see the BREWVisual Studio Addins document included with the BREW SDK Tools User Docs included with the BREWSDK Tools package.

1. To avoid errors be sure that you have setup the environment variables necessary for makefile beforestarting 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 themyfirstapp directory, and enter nmake /f myfirstapp.mak all. This invokes the nmake utility withyour makefile and compiles the application for ARM. Nmake is a utility that comes with Visual Studio thatreads 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 /fmyfirstapp.mak all

P a g e 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 -oaeeapp~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 -oaeemod~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 -oMYFIRS~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 -entry0x8000AEEAPP~1.o AEEMOD~1.o MYFIRS~1.o -first AEEMod_Load

---------------------------------------------------------------

TARGET myfirstapp.mod

C:\Apps\ADS120\Bin\fromelf myfirstapp.elf -omyfirstapp.modC:\Program Files\BREW 3.1.5\sdk\examples\myfirstapp>

Some steps you can take to resolve linking errors encountered during the compilation process includereading 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 headerfiles for each interface. If header files are not included, the compiler cannot recognize the symbols specifiedin the code. Ensure that linking is performed against the proper library versions by properly specifying yourBREWDIR environment variable for the targeted version of BREW.




Load Application Files

You will be using the AppLoader to load your application files to the device. If your device does not have atest signature file (SIG) in the device file system, you will need to use the BREW TestSig Generator togenerate the SIG file.

BREW Test Signature file

The TestSig Generator is a web-based tool that generates a digital signature file necessary to start yourapplication on a device. Each device you develop for requires a test signature that uniquely identifies thedevice. One test signature can be used for multiple applications on the same device. When you transfer theapplication files you can transfer the SIG file as part of the module, which also includes the MOD, MIF andBAR 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 EquipmentIDentifier (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 selectthe port your device is connected to and the BREW version of your device.

https://brewx.qualcomm.com/brew/sdk/download.jsp?page=dx/en/brew31/bd/tl/testsiggen

NOTE: If you are connecting to your device using the BREW Tools Interface Layer (BTIL), you will beconnecting to the device with a different interface and port. For more information please see theappendix.

If you are unable to connect to the device you may have selected an incorrect device connection. Fortroubleshooting tips refer to the Troubleshooting section of the BREW Apploader Help guide includedwith 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 rootdirectory.

NOTE: Some versions of BREW require the names of all files and folders in lower case and no spaces withinthe 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

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 specifymyfirstapp 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.

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 thedevice, or selecting Device > Reset from the AppLoader menu. After resetting your device, start yourapplication within the BREW environment.

Warning: You must have a valid test signature in your application directory, or your application is deletedwhen you power-cycle the phone.

Warning: For security reasons the AppLoader cannot rename files directly on the handset or copy certainfile types to your PC.




Run Application

To run your application after loading the application to the device, you will need to reset the device. This canbe done using the reset button in AppLoader, or you can reset the device manually by power cycling thedevice.

After resetting the device start the application through the BREW Application Manager interface on yourdevice. The BREW Application Manager is used by subscribers to purchase and manage BREW applicationson the device. Your carrier may have given the BREW Application Manager a proprietary name. Theprocedure to invoke the BREW Application Manager varies between device models and carriers; check yourdevice manual if you have questions on the proper sequence. Due to the characteristics of the mobileenvironment, your application may not work as anticipated.

See the appendix for information on troubleshooting and error codes.




Debugging Overview

It is strongly recommended that you properly test your application before submitting it for TRUE BREWTesting. BREW provides a number of options for debugging your application on the device. The Device Primerprovides a general overview of some device debugging tools. Testing and debugging are discussed in moredetail in the third primer in this series, the BREW Test and Automation Primer. Three tools discussed herefor 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() messageson your PC while debugging on the device. With the Logger, you can configure a message log, logmessages and view to a log file. For more information, refer to the BREW Logger Help documentincluded 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 tosend log items to a file, the serial port, and the BREW Simulator output window. ILogger provides astandardized 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 thatallows 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 differentways on different platforms, and is helpful for inspecting the value of variables and debugging theapplication flow of control. You can use the Debugger to output text either to the Visual Studio outputpane if you are running in the Debugger, or to a window in the Simulator. See the BREW APIReference for more details.




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, andprovides 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 beconnecting 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 seenbelow.

The BREW Logger dialog box opens, showing the DBGPRINTF messages.

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, facilitatingthe debugging process. Certain features of the BREW Logger are scriptable with Perl. For more informationand troubleshooting tips see the BREW Logger Help guide, included with the BREW Tools Docs in theBREW Tools Suite installation.




Device Problems

While some applications may run on the Simulator, they may have different results on the device itself. Thedevice runs on ARM architecture which poses some limitations that the developer needs to be aware of whendeveloping BREW applications. Here we briefly discuss some of those limitations and explore some solutionsto those limitations.

Floating point operations in BREW

BREW hardware does not support a floating-point unit, therefore BREW applications cannot use floating pointdata types or operations. Attempting to use floating point operations within BREW will cause an ARM linkererror.

To work around this issue it is possible to define callouts with the ARM compiler used to determine thelocation 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 thefloats.o object file (which performs these tasks) into the project. the Floating Point Operations in BREWonline 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 pointbehavior 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). Thismethod 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-timelibraries. 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 andmacros. There are functions for string manipulation, file I/O, memory allocation, and most other commonoperations normally found in the Standard C Library. Use AEE Memory Services and Standard Librarymacros (in AEEStdLib.h). For example, use MALLOC() to allocate memory, WSTRCPY() to make a copy ofUnicode (wide) string. See the BREW API reference for more information. BREW does not offer support fordevelopers using the standard C library.

Watchdog timer

The BREW device environment limits the amount of time any process may run without yielding through awatchdog timer. If your application trips this watchdog timer, the application terminates, and the handset maypower-cycle. Many factors can cause your application to trigger the watchdog timer, though the mostcommon culprit is improper looping within your application. BREW uses an event-driven application model, soa program should never implement busy-waiting or perform loops that are likely to monopolize the processorfor extended periods.

Memory alignment

Improperly aligned memory accesses on the ARM processor cause a performance penalty. In the ARMenvironment, 16-bit quantities must be at even addresses, and 32-bit quantities must be at addressesdivisible by 4. Members of structures must be properly aligned as well; the ARM compiler automatically padsstructures to ensure that all members are correctly aligned. Generally the best way to conserve space in a

https://brewx.qualcomm.com/bws/content/gi/common/appseng/en/knowledgebase/docs/floats.zip

https://brewx.qualcomm.com/brew/sdk/download.jsp?page=dx/en/brew31/ad/do/api_reference

structure is to declare the members in order of decreasing size; this minimizes the amount of paddinginserted by the compiler while retaining proper member alignment. For more information see the onlineknowledge base article on memory alignment.

Heap usage

Applications running in BREW may fail if proper precautions are not taken to verify that heap memoryallocations complete successfully. BREW applications should always inspect the return value of anydynamic memory operations to ensure that the result is valid, and the application should exit gracefully afterdetecting an error. For more information see the online knowledge base article on failing to optimize code toavoid heap fragmentation.

Stack usage

Care should be taken to minimize the stack usage on the BREW device. Most devices have a relatively smallstack 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, whichcan quickly fill the stack.

Minimize the use of large automatic variables. If possible, shift local buffers and automatic variablesused across multiple methods to the applet structure. This relocates the allocated memory from thestack to the heap. Use pointers to pass structures to methods; this prevents the structure from beingcopied 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 theprogram as a global can be stored in the application's internal structure. Static data can be emulated usingthe Applet Data structure. The applications should be built without static or global data and generateposition-independent code. Since it's possible for the compiler libraries to introduce globals of their own, youshould check the map file after building your application to make sure there aren't any data segments flaggedas 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 recommendationsinclude allocating as little memory as possible, make sure the MIF has permissions set correctly, andprepare for any bizarre usage case by handling every possible error.



https://brewx.qualcomm.com/bws/content/gi/common/appseng/en/knowledgebase/docs/kb95.html

https://brewx.qualcomm.com/brew/sdk/download.jsp?page=appseng/en/knowledgebase




BREW Tools Interface Layer (BTIL)

The BREW Tools Interface Layer (BTIL) is a packet-based transport protocol that allows communicationbetween a host PC and one or more client BREW devices. It was designed as a foundation for testautomation and provides a published C and C++ API set that developers can use to write custom PCapplications 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 onthe device. A shortcut to the BTIL Development Kit is placed in the Start menu. To open the BTIL ClientInstaller navigate to start > BTIL Development Kit > Client Installer. Be sure that you are connecting withthe 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 towhich is in the Start Menu under the BTIL folder. The naming convention for signature files in this folder is thedevice serial number (ESN, IMEI, or MEID) without a leading "0x", for example "12345678.sig". During theinitial connection process with BTIL, the BTIL client running on the device will request a test signature fromthe BTIL server, which checks for the signature file in the Test Signature Repository. If the required testsignature 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.

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 TestSignature 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 aboutconnecting to your device using BTIL.




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 followingmessage: "Application Digital Signature Failure ####".

Any errors in your test signature result in a digital signature failure when you launch your application. Someof the common causes for signature failures are:

Signature file missing - No signature file was found. Ensure that a signature file is generated andplaced within the application directory.

Expired signature - Try generating a new signature file. The lifetime on the previous signature mayhave 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 madeduring 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 theAEEError.h file included with the BREW SDK to figure out the meaning for a given value. The error codes aredefined 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 ahexadecimal base error code. To find the actual error code value, you may need to perform a conversionbetween 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 programpointer 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 thiserror 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 objectson 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 ofallocated 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 specifiedin the MIF.

For more troubleshooting information refer to the BREW 3.1 Developer's Technical web site.

https://brewx.qualcomm.com/brew/sdk/download.jsp?page=dx/en/brew31/ad/kb/running_apps/trouble

device primer

Documents