Forums | developer.brewmp.com Forums | developer.brewmp.com

Developer

Forums

Hi,

when I am compiling my code with the ARM Compiler I am getting back the following errors

Error: L6265E: Non-RWPI Section aciDES.o(.data) cannot be assigned to PI Exec re
gion ER_RW.
Error: L6265E: Non-RWPI Section aciSHA.o(.data) cannot be assigned to PI Exec re
gion ER_RW.
Error: L6265E: Non-RWPI Section aciTool.o(.data) cannot be assigned to PI Exec r
egion ER_RW.
Error: L6265E: Non-RWPI Section libspace.o(.bss) cannot be assigned to PI Exec r
egion ER_ZI.

I am not sure what this mean. Can someone help me with this problem.

thanks

another strange problem that I am getting is that after I build the mak file in visual studio and go to the command prompt and type the following
nmake /f all
I would get the following errors
Microsoft (R) Program Maintenance Utility Version 6.00.8168.0
Copyright (C) Microsoft Corp 1988-1998. All rights reserved.
mid.mak(260) : fatal error U1034: syntax error : separator missing
Stop.

another strange problem that I am getting is that after I build the mak file in visual studio and go to the command prompt and type the following
nmake /f all
I would get the following errors
Microsoft (R) Program Maintenance Utility Version 6.00.8168.0
Copyright (C) Microsoft Corp 1988-1998. All rights reserved.
mid.mak(260) : fatal error U1034: syntax error : separator missing
Stop.

1. You have static/global variables, which cann't be used in BREW. There are many posts on this topic. In BREW 1.1 forums there is a thread on Do's and Don'ts, try to read that thread.
2. Possibly you have problem in your make file.

1. You have static/global variables, which cann't be used in BREW. There are many posts on this topic. In BREW 1.1 forums there is a thread on Do's and Don'ts, try to read that thread.
2. Possibly you have problem in your make file.

Hi,
I am getting the following error when I use the ARM compiler:
Your will end at: Fri Jul 02 23:59:59 2004
Error: L6265E: Non-RWPI Section aciDES.o(.data) cannot be assigned to PI Exec re
gion ER_RW.
Error: L6265E: Non-RWPI Section aciSHA.o(.data) cannot be assigned to PI Exec re
gion ER_RW.
Error: L6265E: Non-RWPI Section aciTool.o(.data) cannot be assigned to PI Exec r
egion ER_RW.
Error: L6265E: Non-RWPI Section libspace.o(.bss) cannot be assigned to PI Exec r
egion ER_ZI.
Can someone assist me with this problem is it because I am not using BREW best practice?

Hi,
I am getting the following error when I use the ARM compiler:
Your will end at: Fri Jul 02 23:59:59 2004
Error: L6265E: Non-RWPI Section aciDES.o(.data) cannot be assigned to PI Exec re
gion ER_RW.
Error: L6265E: Non-RWPI Section aciSHA.o(.data) cannot be assigned to PI Exec re
gion ER_RW.
Error: L6265E: Non-RWPI Section aciTool.o(.data) cannot be assigned to PI Exec r
egion ER_RW.
Error: L6265E: Non-RWPI Section libspace.o(.bss) cannot be assigned to PI Exec r
egion ER_ZI.
Can someone assist me with this problem is it because I am not using BREW best practice?

Do you have any global variables? If so, eliminate them.

Do you have any global variables? If so, eliminate them.

I too seem to have this exact problem
nle wrote:another strange problem that I am getting is that after I build the mak file in visual studio and go to the command prompt and type the following
nmake /f all
I would get the following errors
Microsoft (R) Program Maintenance Utility Version 6.00.8168.0
Copyright (C) Microsoft Corp 1988-1998. All rights reserved.
mid.mak(260) : fatal error U1034: syntax error : separator missing
Stop.
I am just trying to compile the helloworld example, so I think I can presume there are no statics/globals
there was no specific reply to this query in the forums - can anyone help?
- Dave

I too seem to have this exact problem
nle wrote:another strange problem that I am getting is that after I build the mak file in visual studio and go to the command prompt and type the following
nmake /f all
I would get the following errors
Microsoft (R) Program Maintenance Utility Version 6.00.8168.0
Copyright (C) Microsoft Corp 1988-1998. All rights reserved.
mid.mak(260) : fatal error U1034: syntax error : separator missing
Stop.
I am just trying to compile the helloworld example, so I think I can presume there are no statics/globals
there was no specific reply to this query in the forums - can anyone help?
- Dave

The problem you are having its in the Makefile. Check the syntax.
HTH
EDIT: From the Microsoft website:
NMAKE Fatal Error U1034
syntax error : separator missing
The colon (:) that separates targets and dependents is missing.

The problem you are having its in the Makefile. Check the syntax.
HTH
EDIT: From the Microsoft website:
NMAKE Fatal Error U1034
syntax error : separator missing
The colon (:) that separates targets and dependents is missing.

Hi,
I managed to fix it - the generated makefile was wrong:

# --------------------------------------------
# DEPENDENCY LIST, DO NOT EDIT BELOW THIS LINE
# --------------------------------------------
licence found.
aeeapp~1.o: $(BREWDIR)\src\aeeapp~1.c
aeeapp~1.o: $(BREWDIR)\inc\aee.h
aeeapp~1.o: $(BREWDIR)\inc\aeeclassids.h

The line ‘license found’ is produced uncommented. This results in a fatal error
Commenting out the line fixes this. There are other examples of this further down the makefile.
Also, the -fa switch was enabled, resulting in the error:
Error: C0000U: Unrecognized option '-fa'.
NMAKE : fatal error U1077: 'C:\arm\RVD\Tools\ADS\bin\armcc' : return code '0x1'
Stop.
I tried again with --fa, but no good, so I commented it out, and I get a sucessfull build.
Any ideas as to why these errors are in the makefile?
- Dave

Hi,
I managed to fix it - the generated makefile was wrong:

# --------------------------------------------
# DEPENDENCY LIST, DO NOT EDIT BELOW THIS LINE
# --------------------------------------------
licence found.
aeeapp~1.o: $(BREWDIR)\src\aeeapp~1.c
aeeapp~1.o: $(BREWDIR)\inc\aee.h
aeeapp~1.o: $(BREWDIR)\inc\aeeclassids.h

The line ‘license found’ is produced uncommented. This results in a fatal error
Commenting out the line fixes this. There are other examples of this further down the makefile.
Also, the -fa switch was enabled, resulting in the error:
Error: C0000U: Unrecognized option '-fa'.
NMAKE : fatal error U1077: 'C:\arm\RVD\Tools\ADS\bin\armcc' : return code '0x1'
Stop.
I tried again with --fa, but no good, so I commented it out, and I get a sucessfull build.
Any ideas as to why these errors are in the makefile?
- Dave

Hi,
I am using the ARM tools to compile an application which is known to work since it was compiled with the GNU compiler and tested on an LG VX7000. The project compiles but when I install and try to run it, instead of starting the application, the device reboots. I suspect that it is a problem with the entry point yet I have tried everything with regards to the entry point to no avail. Here is the command line sytax used:
armcc -c -DDYNAMIC_APP -cpu ARM7TDMI -apcs /ropi/interwork/rwpi -littleend -zo -fa -Ospace -O2 -I. -I -o
armcpp -c -DDYNAMIC_APP -cpu ARM7TDMI -apcs /ropi/interwork/rwpi -littleend -zo -fa -Ospace -O2 -I. -I -o
armlink -o -ropi -rwpi -reloc -entry AEEMod_Load -ro-base 0x0 -first AEEMod_Load
fromelf -bin
Here are other specs:
- BREWSDK 2.1.3
- LG VX7000
- RealView Compilation Tools for BREW v1.2
Has anyone else run into this problem and if so, what was the problem? Could someone please offer some insight.
Rick

Hi,
I am using the ARM tools to compile an application which is known to work since it was compiled with the GNU compiler and tested on an LG VX7000. The project compiles but when I install and try to run it, instead of starting the application, the device reboots. I suspect that it is a problem with the entry point yet I have tried everything with regards to the entry point to no avail. Here is the command line sytax used:
armcc -c -DDYNAMIC_APP -cpu ARM7TDMI -apcs /ropi/interwork/rwpi -littleend -zo -fa -Ospace -O2 -I. -I -o
armcpp -c -DDYNAMIC_APP -cpu ARM7TDMI -apcs /ropi/interwork/rwpi -littleend -zo -fa -Ospace -O2 -I. -I -o
armlink -o -ropi -rwpi -reloc -entry AEEMod_Load -ro-base 0x0 -first AEEMod_Load
fromelf -bin
Here are other specs:
- BREWSDK 2.1.3
- LG VX7000
- RealView Compilation Tools for BREW v1.2
Has anyone else run into this problem and if so, what was the problem? Could someone please offer some insight.
Rick

gcc handles some global data differently to arm, so while its possible to get away with it on gcc, not always so on armcc
change rwpi to norwpi see what it spits out

gcc handles some global data differently to arm, so while its possible to get away with it on gcc, not always so on armcc
change rwpi to norwpi see what it spits out

charliex wrote:gcc handles some global data differently to arm, so while its possible to get away with it on gcc, not always so on armcc
change rwpi to norwpi see what it spits out
Thanks for the quick reply charliex.
I get the same result with norwpi. I keep reading that you can't have static variables in BREW!? I do have some static variables in my code, yet when I compile with arm-elf-gcc, the application runs smoothly. Is this only true when using the RealView ARM compiler? If this is the case, then I'm losing a huge feature of OOP, and I might as well forget about RV-ARM and stick with gcc.
Is this really the case? Why don't I get errors during compilation? What techniques do BREW programmers use to work around this problem?

charliex wrote:gcc handles some global data differently to arm, so while its possible to get away with it on gcc, not always so on armcc
change rwpi to norwpi see what it spits out
Thanks for the quick reply charliex.
I get the same result with norwpi. I keep reading that you can't have static variables in BREW!? I do have some static variables in my code, yet when I compile with arm-elf-gcc, the application runs smoothly. Is this only true when using the RealView ARM compiler? If this is the case, then I'm losing a huge feature of OOP, and I might as well forget about RV-ARM and stick with gcc.
Is this really the case? Why don't I get errors during compilation? What techniques do BREW programmers use to work around this problem?

you cant have global variables in brew, theres some confusion on the use of the static keyword vs static location.
basically any variable thats got more than a function level scope isn't allowed and that includes local function variables with a static keyword to modify their storage scope.
gcc does some pokery with some variables, using a base pointer to make them relative vs absolute, however i have noticed some phones will appear to work ok with global data, but when you load it on another it'll crash, without knowing more about what the firmware can do my best guess on that is that its using memory that doesn't belong to the app and getting away with it.
consts are ok
get around it by defining a class or struct with all the globals data in it storing it in the Applet and referring to that.
GETAPPLET() will return the base applet address so you can fetch your structs pointer

you cant have global variables in brew, theres some confusion on the use of the static keyword vs static location.
basically any variable thats got more than a function level scope isn't allowed and that includes local function variables with a static keyword to modify their storage scope.
gcc does some pokery with some variables, using a base pointer to make them relative vs absolute, however i have noticed some phones will appear to work ok with global data, but when you load it on another it'll crash, without knowing more about what the firmware can do my best guess on that is that its using memory that doesn't belong to the app and getting away with it.
consts are ok
get around it by defining a class or struct with all the globals data in it storing it in the Applet and referring to that.
GETAPPLET() will return the base applet address so you can fetch your structs pointer

Quote:gcc does some pokery with some variables, using a base pointer to make them relative vs absolute, however i have noticed some phones will appear to work ok with global data, but when you load it on another it'll crash, without knowing more about what the firmware can do my best guess on that is that its using memory that doesn't belong to the app and getting away with it.
That's good to know, I had never run into this problem before since gcc works around it (I've never had a problem on any phone). I'm assuming that objects with a global scope fall under the same category!? I still find it strange that the compiler does not return an error if globals aren't aloud, it could have spared me the wasted time and frustration.
Quote:get around it by defining a class or struct with all the globals data in it storing it in the Applet and referring to that.
GETAPPLET() will return the base applet address so you can fetch your structs pointer
If you know any good links on storing a class or struct it would be greatly appreciated. Thanks for the help!

Quote:gcc does some pokery with some variables, using a base pointer to make them relative vs absolute, however i have noticed some phones will appear to work ok with global data, but when you load it on another it'll crash, without knowing more about what the firmware can do my best guess on that is that its using memory that doesn't belong to the app and getting away with it.
That's good to know, I had never run into this problem before since gcc works around it (I've never had a problem on any phone). I'm assuming that objects with a global scope fall under the same category!? I still find it strange that the compiler does not return an error if globals aren't aloud, it could have spared me the wasted time and frustration.
Quote:get around it by defining a class or struct with all the globals data in it storing it in the Applet and referring to that.
GETAPPLET() will return the base applet address so you can fetch your structs pointer
If you know any good links on storing a class or struct it would be greatly appreciated. Thanks for the help!

all you need to is something like this
typedef struct UserData_tag {
int mydata;
// etc
} UserData;
typedef struct Applet_t {
AEEApplet a;
UserData *data;
} MyApplet;
then add that to the Applet you pass into to the Create
if(AEEApplet_New( sizeof( MyApplet ), //remember this one // Size of our private class
ClsId, // Our class ID
pIShell, // Shell interface
pMod, // Module instance
(IApplet**)ppObj, // Return object
(AEEHANDLER)Lib_HandleEvent, // Our event handler
(PFNFREEAPPDATA)NULL)) // No special "cleanup" function
{
then in the code
pMe->data= (UserData *) MALLOC ( sizeof( data ) );
//access the data
pMe->data->mydata = 1;
dont use super large UserData, some of it may have to be malloc'd in some brew SDKS the sizeof is a signed value, so it fails on large applet structs
and either pass in the applet pointer or get it from the base class, or use GETAPPLET()
i hate the TAB key in browsers!! ;)

all you need to is something like this
typedef struct UserData_tag {
int mydata;
// etc
} UserData;
typedef struct Applet_t {
AEEApplet a;
UserData *data;
} MyApplet;
then add that to the Applet you pass into to the Create
if(AEEApplet_New( sizeof( MyApplet ), //remember this one // Size of our private class
ClsId, // Our class ID
pIShell, // Shell interface
pMod, // Module instance
(IApplet**)ppObj, // Return object
(AEEHANDLER)Lib_HandleEvent, // Our event handler
(PFNFREEAPPDATA)NULL)) // No special "cleanup" function
{
then in the code
pMe->data= (UserData *) MALLOC ( sizeof( data ) );
//access the data
pMe->data->mydata = 1;
dont use super large UserData, some of it may have to be malloc'd in some brew SDKS the sizeof is a signed value, so it fails on large applet structs
and either pass in the applet pointer or get it from the base class, or use GETAPPLET()
i hate the TAB key in browsers!! ;)

Quote:
I still find it strange that the compiler does not return an error if globals aren't aloud
yeah me too, it picks them up sometimes and not others i've noticed, especially 1.2, there may be a valid reason that i don't know yet.
i've found using compile via assembly -S picks up some that armcc/link won't
-norwpi should get them though.
but its entirely possible the phones are letting you get away with it, i saw an app recently that passed TBT with it, but it'd crash other phones. the fixup offset isn't applied so its just lucking out that the memory isn't used where it happens to appear i guess. Its like some phones crash on a NULL pointer and some don't

Quote:
I still find it strange that the compiler does not return an error if globals aren't aloud
yeah me too, it picks them up sometimes and not others i've noticed, especially 1.2, there may be a valid reason that i don't know yet.
i've found using compile via assembly -S picks up some that armcc/link won't
-norwpi should get them though.
but its entirely possible the phones are letting you get away with it, i saw an app recently that passed TBT with it, but it'd crash other phones. the fixup offset isn't applied so its just lucking out that the memory isn't used where it happens to appear i guess. Its like some phones crash on a NULL pointer and some don't

charliex wrote:basically any variable thats got more than a function level scope isn't allowed and that includes local function variables with a static keyword to modify their storage scope.
After reading this again, my heart skipped a beat! Are you saying that class member variables are not permitted!? I'll have nightmares for days, maybe weeks if that's the case! I'm assuming all this applies to object variables too. I feel like Jim Carrey in The Truman Show, gcc's been hiding the truth from me all this time (ignorance is bliss). Anyway, is there some complete documentation on these BREW limitations, because I've searched and come up empty.
Thanks again for your time and patience charliex, greatly appreciated

charliex wrote:basically any variable thats got more than a function level scope isn't allowed and that includes local function variables with a static keyword to modify their storage scope.
After reading this again, my heart skipped a beat! Are you saying that class member variables are not permitted!? I'll have nightmares for days, maybe weeks if that's the case! I'm assuming all this applies to object variables too. I feel like Jim Carrey in The Truman Show, gcc's been hiding the truth from me all this time (ignorance is bliss). Anyway, is there some complete documentation on these BREW limitations, because I've searched and come up empty.
Thanks again for your time and patience charliex, greatly appreciated

class member variables don't have global scope, and generally the compiler makes the relative vs absolute, since functions, members are relative to the class itself, not the global memory.
assume each of thse is the complete source
ok , relative to class
class {
int foo ;
;
not ok,variable with global scope
int foo;
not ok, local variable but has global storage scope, so that its value is remembered across functioms,
func()
{
static int foo;

ok, constant value with global scope
const int foo =1;
hopefully this doesn't confuse you more.

class member variables don't have global scope, and generally the compiler makes the relative vs absolute, since functions, members are relative to the class itself, not the global memory.
assume each of thse is the complete source
ok , relative to class
class {
int foo ;
;
not ok,variable with global scope
int foo;
not ok, local variable but has global storage scope, so that its value is remembered across functioms,
func()
{
static int foo;

ok, constant value with global scope
const int foo =1;
hopefully this doesn't confuse you more.

Hi rickholt, I experienced the same crash on the 7000 phone (at starting the app) yesterday. Just wondering if (and how) you resolved the problem.
I havent yet tried on it other phones.
I am not using "static"s, put I am using "const static" - which shouldn't really matter.
Thanks in advance

Hi rickholt, I experienced the same crash on the 7000 phone (at starting the app) yesterday. Just wondering if (and how) you resolved the problem.
I havent yet tried on it other phones.
I am not using "static"s, put I am using "const static" - which shouldn't really matter.
Thanks in advance

startup crashes can usually be attributed to
global data, fixups
compiling aeemodgen/aeeappgen in thumb instead of arm (use armcc)
heap
NULL pointers ( LGs are sensitive to NULL references)

startup crashes can usually be attributed to
global data, fixups
compiling aeemodgen/aeeappgen in thumb instead of arm (use armcc)
heap
NULL pointers ( LGs are sensitive to NULL references)

Thanks for your quick responce.
I have no global data. But what do you mean by fixups?
I am using the gcc compiler (not armcc) - but with a thumb option.
The heap is defo ok, as are the pointers - like I said the code doesn't get ANYWHERE.
Thanks again

Thanks for your quick responce.
I have no global data. But what do you mean by fixups?
I am using the gcc compiler (not armcc) - but with a thumb option.
The heap is defo ok, as are the pointers - like I said the code doesn't get ANYWHERE.
Thanks again

When using thumb, you must make sure you're using thumb-interworking and also, IIRC, AEEModGen.c/AEEAppGen.c should be compiled on ARM and not THUMB.

When using thumb, you must make sure you're using thumb-interworking and also, IIRC, AEEModGen.c/AEEAppGen.c should be compiled on ARM and not THUMB.

Hi, thanks for the reply. I know my problem is defo not with the code, so yeah its probably the way I'm compiling.
My mak file is as follow, if you can see anything stupidly wrong with it :)
BREW_HOME = $(BREWDIR)
BREW_ADDINS = $(BREWADDINS)
GCC_HOME = $(GCCHOME)
GCC_LIBPATH = $(GCCLIBPATH)
GCC = c:\gnude\bin\arm-elf-gcc.exe
LD = c:\gnude\bin\arm-elf-ld.exe
ELF2MODTOOL = c:\gnude\bin\BrewElf2Mod.exe
GCCHOMEPATH = c:\gnude
TARGET = objects\tyson
OBJS = objects\GCCResolver.o objects\AEEAppGen.o objects\AEEModGen.o objects\startup.o objects\tyson.o
APP_INCLUDES =-Ic:\BrewProj\temp\MikeTysonBoxingBrew\tyson\
DUMPTOOL = $(GCC_HOME)\bin\arm-elf-objdump
ELF2MODTOOLPATH = $(BREW_ADDINS)\common\bin
ELF2MODTOOL = $(ELF2MODTOOLPATH)\BREWelf2mod.exe
GCCRESOLVEPATH = $(BREW_ADDINS)\common\templates\src
#-------------------------------------------------------------------------------
# Target file name and type definitions
#-------------------------------------------------------------------------------
EXETYPE = elf # Target image file format
MODULE = mod # Downloadable module extension
#-------------------------------------------------------------------------------
# Target compile time symbol definitions
#
# Tells the SDK source stuffs that we're building a dynamic app.
#-------------------------------------------------------------------------------
DEFINES = -DDYNAMIC_APP
#-DUSEGCC
#-----------------------------------------------------------
# Fix the path here to location of AEEAppGen.c and AEEModGen.c
#-----------------------------------------------------------
AEESRCPATH = $(BREWDIR)\src
#-----------------------------------------------------------
# Fix the path here to location of BREW header files
#-----------------------------------------------------------
AEEINCPATH = $(BREWDIR)\inc
#-------------------------------------------------------------------------------
# Processor architecture options
#-------------------------------------------------------------------------------
CPU = -mcpu=arm7tdmi
#-------------------------------------------------------------------------------
# ARM Procedure Call Standard (APCS) options
#-------------------------------------------------------------------------------
ROPI =
INTRWK = -mthumb-interwork
APCS = -mapcs-frame $(ROPI) $(INTRWK)
#-------------------------------------------------------------------------------
# Additional compile time error checking options
#-------------------------------------------------------------------------------
CHK = -fa # Check for data flow anomolies
#-------------------------------------------------------------------------------
# Compiler output options
#-------------------------------------------------------------------------------
OUT = -c # Object file output only
#-------------------------------------------------------------------------------
# Compiler/assembler debug options
#-------------------------------------------------------------------------------
#DBG = -g # Enable debug
DBG =
#-------------------------------------------------------------------------------
# Compiler optimization options
#-------------------------------------------------------------------------------
OPT = -O2 # Full compiler optimization for space
#-------------------------------------------------------------------------------
# Compiler code generation options
#-------------------------------------------------------------------------------
END =-mlittle-endian
TARG = -mthumb
CODE = $(END) -fshort-enums -fno-builtin
#-------------------------------------------------------------------------------
# Include file search path options
#-------------------------------------------------------------------------------
INC = -I$(AEEINCPATH) -I$(GCCHOMEPATH)\lib\gcc-lib\arm-elf\3.3.1\include -I$(GCCHOMEPATH)\arm-elf\include $(APP_INCLUDES)
LIBDIRS = -L$(GCCHOMEPATH)\lib\gcc-lib\arm-elf\3.3.1
#-------------------------------------------------------------------------------
# Compiler pragma emulation options
#-------------------------------------------------------------------------------
#-------------------------------------------------------------------------------
# Linker options
#-------------------------------------------------------------------------------
LINK_CMD = -o #Command line option to specify output file
#on linking
ROPILINK = -ropi #Link image as Read-Only Position Independent
#-------------------------------------------------------------------------------
# HEXTOOL options
#-------------------------------------------------------------------------------
BINFORMAT = -O binary
#-------------------------------------------------------------------------------
# Compiler flag definitions
#-------------------------------------------------------------------------------
CFLAGS0 = $(OUT) $(DEFINES) $(CPU) $(APCS) $(CODE) $(DBG) -fno-exceptions
CFLAGS = $(CFLAGS0) $(INC) $(OPT)
#-----------------------------------------------------------------------
# Linker Options
# -o sets the output filename
#-----------------------------------------------------------------------
LINK_CMD = -Ttext 0 --emit-relocs -entry AEEMod_Load -o
LIBS = -lgcc
#-----------------------------------------------------------------------
# Linker flag definitions
#-----------------------------------------------------------------------
LDFLAGS = $(LIBDIRS)
#----------------------------------------------------------------------------
# Default target
#----------------------------------------------------------------------------
all : $(TARGET).$(MODULE)
#----------------------------------------------------------------------------
# Clean target
#----------------------------------------------------------------------------
# The object subdirectory, target image file, and target hex file are deleted.
clean :
@echo ---------------------------------------------------------------
@echo CLEAN
-del /f $(OBJS)
-del /f $(TARGET).$(EXETYPE)
-del /f $(TARGET).$(MODULE)
@echo ---------------------------------------------------------------
#============================================================================
# DEFAULT SUFFIX RULES
#============================================================================
# The following are the default suffix rules used to compile all objects that
# are not specifically included in one of the module specific rules defined
# in the next section.
# The following macros are used to specify the output object file, MSG_FILE
# symbol definition and input source file on the compile line in the rules
# defined below.
SRC_CPP_FILE = $(@F:.o=.cpp) # Input source file specification
SRC_C_FILE = $(@F:.o=.c) # Input source file specification
OBJ_FILE = $(OBJ_CMD) $(@F) # Output object file specification
.SUFFIXES :
.SUFFIXES : .o .dep .c .cpp
#===============================================================================
# MODULE SPECIFIC RULES
#===============================================================================
APP_OBJS = $(OBJS)
#----------------------------------------------------------------------------
# Lib file targets
#----------------------------------------------------------------------------
$(TARGET).$(MODULE) : $(TARGET).$(EXETYPE)
$(ELF2MODTOOL) $(TARGET).$(EXETYPE) $(TARGET).$(MODULE)
$(TARGET).$(EXETYPE) : $(APP_OBJS)
$(LD) $(LINK_CMD) $(TARGET).$(EXETYPE) $(LDFLAGS) \
$(APP_OBJS) $(LIBS) $(LINK_ORDER)
#-----------------------------------------------------------------------
# Object File Dependencies
# You may well want to add more dependencies here.
#-----------------------------------------------------------------------
objects\AEEAppGen.o:
$(GCC) $(CFLAGS) -o objects\AEEAppGen.o $(AEESRCPATH)\AEEAppGen.c
objects\AEEModGen.o:
$(GCC) $(CFLAGS) -o objects\AEEModGen.o $(AEESRCPATH)\AEEModGen.c
objects\GCCResolver.o:
$(GCC) $(CFLAGS) -o objects\GCCResolver.o $(GCCHOMEPATH)\GCCResolver.c
objects\startup.o:
$(GCC) $(CFLAGS) -o objects\startup.o C:\BREWProj\temp\MikeTysonBoxingBrew\tyson\startup.cpp
objects\tyson.o:
$(GCC) $(CFLAGS) -o objects\tyson.o C:\BREWProj\temp\MikeTysonBoxingBrew\tyson\tyson.cpp

Hi, thanks for the reply. I know my problem is defo not with the code, so yeah its probably the way I'm compiling.
My mak file is as follow, if you can see anything stupidly wrong with it :)
BREW_HOME = $(BREWDIR)
BREW_ADDINS = $(BREWADDINS)
GCC_HOME = $(GCCHOME)
GCC_LIBPATH = $(GCCLIBPATH)
GCC = c:\gnude\bin\arm-elf-gcc.exe
LD = c:\gnude\bin\arm-elf-ld.exe
ELF2MODTOOL = c:\gnude\bin\BrewElf2Mod.exe
GCCHOMEPATH = c:\gnude
TARGET = objects\tyson
OBJS = objects\GCCResolver.o objects\AEEAppGen.o objects\AEEModGen.o objects\startup.o objects\tyson.o
APP_INCLUDES =-Ic:\BrewProj\temp\MikeTysonBoxingBrew\tyson\
DUMPTOOL = $(GCC_HOME)\bin\arm-elf-objdump
ELF2MODTOOLPATH = $(BREW_ADDINS)\common\bin
ELF2MODTOOL = $(ELF2MODTOOLPATH)\BREWelf2mod.exe
GCCRESOLVEPATH = $(BREW_ADDINS)\common\templates\src
#-------------------------------------------------------------------------------
# Target file name and type definitions
#-------------------------------------------------------------------------------
EXETYPE = elf # Target image file format
MODULE = mod # Downloadable module extension
#-------------------------------------------------------------------------------
# Target compile time symbol definitions
#
# Tells the SDK source stuffs that we're building a dynamic app.
#-------------------------------------------------------------------------------
DEFINES = -DDYNAMIC_APP
#-DUSEGCC
#-----------------------------------------------------------
# Fix the path here to location of AEEAppGen.c and AEEModGen.c
#-----------------------------------------------------------
AEESRCPATH = $(BREWDIR)\src
#-----------------------------------------------------------
# Fix the path here to location of BREW header files
#-----------------------------------------------------------
AEEINCPATH = $(BREWDIR)\inc
#-------------------------------------------------------------------------------
# Processor architecture options
#-------------------------------------------------------------------------------
CPU = -mcpu=arm7tdmi
#-------------------------------------------------------------------------------
# ARM Procedure Call Standard (APCS) options
#-------------------------------------------------------------------------------
ROPI =
INTRWK = -mthumb-interwork
APCS = -mapcs-frame $(ROPI) $(INTRWK)
#-------------------------------------------------------------------------------
# Additional compile time error checking options
#-------------------------------------------------------------------------------
CHK = -fa # Check for data flow anomolies
#-------------------------------------------------------------------------------
# Compiler output options
#-------------------------------------------------------------------------------
OUT = -c # Object file output only
#-------------------------------------------------------------------------------
# Compiler/assembler debug options
#-------------------------------------------------------------------------------
#DBG = -g # Enable debug
DBG =
#-------------------------------------------------------------------------------
# Compiler optimization options
#-------------------------------------------------------------------------------
OPT = -O2 # Full compiler optimization for space
#-------------------------------------------------------------------------------
# Compiler code generation options
#-------------------------------------------------------------------------------
END =-mlittle-endian
TARG = -mthumb
CODE = $(END) -fshort-enums -fno-builtin
#-------------------------------------------------------------------------------
# Include file search path options
#-------------------------------------------------------------------------------
INC = -I$(AEEINCPATH) -I$(GCCHOMEPATH)\lib\gcc-lib\arm-elf\3.3.1\include -I$(GCCHOMEPATH)\arm-elf\include $(APP_INCLUDES)
LIBDIRS = -L$(GCCHOMEPATH)\lib\gcc-lib\arm-elf\3.3.1
#-------------------------------------------------------------------------------
# Compiler pragma emulation options
#-------------------------------------------------------------------------------
#-------------------------------------------------------------------------------
# Linker options
#-------------------------------------------------------------------------------
LINK_CMD = -o #Command line option to specify output file
#on linking
ROPILINK = -ropi #Link image as Read-Only Position Independent
#-------------------------------------------------------------------------------
# HEXTOOL options
#-------------------------------------------------------------------------------
BINFORMAT = -O binary
#-------------------------------------------------------------------------------
# Compiler flag definitions
#-------------------------------------------------------------------------------
CFLAGS0 = $(OUT) $(DEFINES) $(CPU) $(APCS) $(CODE) $(DBG) -fno-exceptions
CFLAGS = $(CFLAGS0) $(INC) $(OPT)
#-----------------------------------------------------------------------
# Linker Options
# -o sets the output filename
#-----------------------------------------------------------------------
LINK_CMD = -Ttext 0 --emit-relocs -entry AEEMod_Load -o
LIBS = -lgcc
#-----------------------------------------------------------------------
# Linker flag definitions
#-----------------------------------------------------------------------
LDFLAGS = $(LIBDIRS)
#----------------------------------------------------------------------------
# Default target
#----------------------------------------------------------------------------
all : $(TARGET).$(MODULE)
#----------------------------------------------------------------------------
# Clean target
#----------------------------------------------------------------------------
# The object subdirectory, target image file, and target hex file are deleted.
clean :
@echo ---------------------------------------------------------------
@echo CLEAN
-del /f $(OBJS)
-del /f $(TARGET).$(EXETYPE)
-del /f $(TARGET).$(MODULE)
@echo ---------------------------------------------------------------
#============================================================================
# DEFAULT SUFFIX RULES
#============================================================================
# The following are the default suffix rules used to compile all objects that
# are not specifically included in one of the module specific rules defined
# in the next section.
# The following macros are used to specify the output object file, MSG_FILE
# symbol definition and input source file on the compile line in the rules
# defined below.
SRC_CPP_FILE = $(@F:.o=.cpp) # Input source file specification
SRC_C_FILE = $(@F:.o=.c) # Input source file specification
OBJ_FILE = $(OBJ_CMD) $(@F) # Output object file specification
.SUFFIXES :
.SUFFIXES : .o .dep .c .cpp
#===============================================================================
# MODULE SPECIFIC RULES
#===============================================================================
APP_OBJS = $(OBJS)
#----------------------------------------------------------------------------
# Lib file targets
#----------------------------------------------------------------------------
$(TARGET).$(MODULE) : $(TARGET).$(EXETYPE)
$(ELF2MODTOOL) $(TARGET).$(EXETYPE) $(TARGET).$(MODULE)
$(TARGET).$(EXETYPE) : $(APP_OBJS)
$(LD) $(LINK_CMD) $(TARGET).$(EXETYPE) $(LDFLAGS) \
$(APP_OBJS) $(LIBS) $(LINK_ORDER)
#-----------------------------------------------------------------------
# Object File Dependencies
# You may well want to add more dependencies here.
#-----------------------------------------------------------------------
objects\AEEAppGen.o:
$(GCC) $(CFLAGS) -o objects\AEEAppGen.o $(AEESRCPATH)\AEEAppGen.c
objects\AEEModGen.o:
$(GCC) $(CFLAGS) -o objects\AEEModGen.o $(AEESRCPATH)\AEEModGen.c
objects\GCCResolver.o:
$(GCC) $(CFLAGS) -o objects\GCCResolver.o $(GCCHOMEPATH)\GCCResolver.c
objects\startup.o:
$(GCC) $(CFLAGS) -o objects\startup.o C:\BREWProj\temp\MikeTysonBoxingBrew\tyson\startup.cpp
objects\tyson.o:
$(GCC) $(CFLAGS) -o objects\tyson.o C:\BREWProj\temp\MikeTysonBoxingBrew\tyson\tyson.cpp

Hi just letting you guys know - I got it working - and it runs like a dream!
I this thread:
http://brewforums.qualcomm.com/showthread.php?t=8855
and the supplied attachment. - Basically actually creates a mak file from VS that works! Shock horror!

Hi just letting you guys know - I got it working - and it runs like a dream!
I this thread:
http://brewforums.qualcomm.com/showthread.php?t=8855
and the supplied attachment. - Basically actually creates a mak file from VS that works! Shock horror!

I get this exact error 23 times when compiling:
Error: L6248E: util.o(.constdata) in PI region 'ER_RO' cannot have address type relocation to .constdata$1 in PI region 'ER_RO'
It seems that it is trying to relocate constant data inside the same region. I don't understand what this means and how to remedy the problem. Anyone have a clue?

I get this exact error 23 times when compiling:
Error: L6248E: util.o(.constdata) in PI region 'ER_RO' cannot have address type relocation to .constdata$1 in PI region 'ER_RO'
It seems that it is trying to relocate constant data inside the same region. I don't understand what this means and how to remedy the problem. Anyone have a clue?

gafman99 wrote:Hi rickholt, I experienced the same crash on the 7000 phone (at starting the app) yesterday. Just wondering if (and how) you resolved the problem.
I havent yet tried on it other phones.
I am not using "static"s, put I am using "const static" - which shouldn't really matter.
My problem was with global variables in my code and I fixed that by gathering all my globals into a struct and inserting it into the applet structure.
const statics are acceptable and shouldn't cause a problem.
Your crash may be caused by another type of bug, it seems to be quite common for the 7000 to reboot when it experiences a crash. My best advice to you would be to debug with the emulator first and see if the same thing happens.
Good luck

gafman99 wrote:Hi rickholt, I experienced the same crash on the 7000 phone (at starting the app) yesterday. Just wondering if (and how) you resolved the problem.
I havent yet tried on it other phones.
I am not using "static"s, put I am using "const static" - which shouldn't really matter.
My problem was with global variables in my code and I fixed that by gathering all my globals into a struct and inserting it into the applet structure.
const statics are acceptable and shouldn't cause a problem.
Your crash may be caused by another type of bug, it seems to be quite common for the 7000 to reboot when it experiences a crash. My best advice to you would be to debug with the emulator first and see if the same thing happens.
Good luck

rickholt wrote:My problem was with global variables in my code and I fixed that by gathering all my globals into a struct and inserting it into the applet structure.
const statics are acceptable and shouldn't cause a problem.
Your crash may be caused by another type of bug, it seems to be quite common for the 7000 to reboot when it experiences a crash. My best advice to you would be to debug with the emulator first and see if the same thing happens.
Good luck
I did actually fix this (see my last post), (and it was every phone not just the 7000) it turned out that I wasn't compiling it correctly.
See my last post for the fix.

rickholt wrote:My problem was with global variables in my code and I fixed that by gathering all my globals into a struct and inserting it into the applet structure.
const statics are acceptable and shouldn't cause a problem.
Your crash may be caused by another type of bug, it seems to be quite common for the 7000 to reboot when it experiences a crash. My best advice to you would be to debug with the emulator first and see if the same thing happens.
Good luck
I did actually fix this (see my last post), (and it was every phone not just the 7000) it turned out that I wasn't compiling it correctly.
See my last post for the fix.

Hi all,
I can run the Hello on the simulator but when I use BREW Application 'Make' to build mod file but i cant and the output window show the error as bellow. Can anyone help to solve my problem. Many thanks,
====================================== Output from CMD
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
C:\Documents and Settings\QUANG NGUYEN>cd D:\workspace\working\brew_project\proj
ects\Hello
C:\Documents and Settings\QUANG NGUYEN>d:
D:\workspace\working\brew_project\projects\Hello>nmake /f Hello.mak all
Microsoft (R) Program Maintenance Utility Version 6.00.9782.0
Copyright (C) Microsoft Corp 1988-1998. All rights reserved.
---------------------------------------------------------------
OBJECT AEEAppGen.o
C:\Program Files\ARM\ADS12\bin\armcc -c -DDYNAMIC_APP -cpu ARM7TDMI -apc
s /ropi/interwork/norwpi -littleend -zo -fa -g -Ospace -O2 -I. -IC:\PROGRA~1\BRE
W315\sdk\inc -I "C:\PROGRA~1\BREW315\sdk\inc" -o AEEAppGen.o C:\PROGRA~1\BREW315
\sdk\src\AEEAppGen.c
'C:\Program' is not recognized as an internal or external command,
operable program or batch file.
NMAKE : fatal error U1077: 'C:\Program' : return code '0x1'
Stop.
D:\workspace\working\brew_project\projects\Hello>
====================================== Output from MVC6
Building d:\worksp~1\working\brew_p~1\projects\hello\hello using D:\WORKSPACE\WORKING\BREW_PROJECT\PROJECTS\Hello\Hello.mak
Microsoft (R) Program Maintenance Utility Version 6.00.9782.0
Copyright (C) Microsoft Corp 1988-1998. All rights reserved.
---------------------------------------------------------------
OBJECT AEEAppGen.o
C:\Program Files\ARM\ADS12\bin\armcc -c -DDYNAMIC_APP -cpu ARM7TDMI -apcs /ropi/interwork/norwpi -littleend -zo -fa -g -Ospace -O2 -I. -IC:\PROGRA~1\BREW315\sdk\inc -I "C:\PROGRA~1\BREW315\sdk\inc" -o AEEAppGen.o C:\PROGRA~1\BREW315\sdk\src\AEEAppGen.c
'C:\Program' is not recognized as an internal or external command,
operable program or batch file.
NMAKE : fatal error U1077: 'C:\Program' : return code '0x1'
Stop.
Tool returned code: 0
=============================END.
Thanks again,

Hi all,
I can run the Hello on the simulator but when I use BREW Application 'Make' to build mod file but i cant and the output window show the error as bellow. Can anyone help to solve my problem. Many thanks,
====================================== Output from CMD
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
C:\Documents and Settings\QUANG NGUYEN>cd D:\workspace\working\brew_project\proj
ects\Hello
C:\Documents and Settings\QUANG NGUYEN>d:
D:\workspace\working\brew_project\projects\Hello>nmake /f Hello.mak all
Microsoft (R) Program Maintenance Utility Version 6.00.9782.0
Copyright (C) Microsoft Corp 1988-1998. All rights reserved.
---------------------------------------------------------------
OBJECT AEEAppGen.o
C:\Program Files\ARM\ADS12\bin\armcc -c -DDYNAMIC_APP -cpu ARM7TDMI -apc
s /ropi/interwork/norwpi -littleend -zo -fa -g -Ospace -O2 -I. -IC:\PROGRA~1\BRE
W315\sdk\inc -I "C:\PROGRA~1\BREW315\sdk\inc" -o AEEAppGen.o C:\PROGRA~1\BREW315
\sdk\src\AEEAppGen.c
'C:\Program' is not recognized as an internal or external command,
operable program or batch file.
NMAKE : fatal error U1077: 'C:\Program' : return code '0x1'
Stop.
D:\workspace\working\brew_project\projects\Hello>
====================================== Output from MVC6
Building d:\worksp~1\working\brew_p~1\projects\hello\hello using D:\WORKSPACE\WORKING\BREW_PROJECT\PROJECTS\Hello\Hello.mak
Microsoft (R) Program Maintenance Utility Version 6.00.9782.0
Copyright (C) Microsoft Corp 1988-1998. All rights reserved.
---------------------------------------------------------------
OBJECT AEEAppGen.o
C:\Program Files\ARM\ADS12\bin\armcc -c -DDYNAMIC_APP -cpu ARM7TDMI -apcs /ropi/interwork/norwpi -littleend -zo -fa -g -Ospace -O2 -I. -IC:\PROGRA~1\BREW315\sdk\inc -I "C:\PROGRA~1\BREW315\sdk\inc" -o AEEAppGen.o C:\PROGRA~1\BREW315\sdk\src\AEEAppGen.c
'C:\Program' is not recognized as an internal or external command,
operable program or batch file.
NMAKE : fatal error U1077: 'C:\Program' : return code '0x1'
Stop.
Tool returned code: 0
=============================END.
Thanks again,

take the spaces out of the path for the arm compiler enviroment variables, use the short name versions

take the spaces out of the path for the arm compiler enviroment variables, use the short name versions

charliex wrote:take the spaces out of the path for the arm compiler enviroment variables, use the short name versions
Thanks, for your reply but I still don't understand your instruction so can you please tell me more details for solve the problem ?

charliex wrote:take the spaces out of the path for the arm compiler enviroment variables, use the short name versions
Thanks, for your reply but I still don't understand your instruction so can you please tell me more details for solve the problem ?