Lg Vx6000 Insanity! | developer.brewmp.com Lg Vx6000 Insanity! | developer.brewmp.com

Developer

Lg Vx6000 Insanity!

Forums:

Greetings, Salutations, and Much Warmth:

I am about ready to release a BREW App to sell ringtones and wallpapers to consumers.

My App runs like a charm on other handsets, but behaves like a SCHIZOPHRENIC on the LG VX 6000.

I developed using BREW 1.1 and I understand this handset is 2.0, but according to Qualcomm this should not be an issue as 1.1 is forward-compatible with 2.x and 3.x on the binary level.

(I use GCC as the compiler on Windows as ADS is too draconian in its licensing and we don't have the patience to deal with its restrictions on which machines can be used to compile the code.)

Anyway.. the LG VX 6000 has random screen corruption and other assorted misbehaviour when runnning my app.

My app runs perfectly on: Motorola T720 & Audiovox CDM 9500, as well as the Simulator. However on the LG VX6000 that I have it misbehaves. Namely.. it experiences erratic but non-fatal screen corruption occasionally, it refuses to display certain sized graphics, and also reproducibly refuses to draw ISTATIC text controls to the screen. It also has problems accessing ILICENSE functions.. they seem to trigger ISTATIC to misbehave and not actaully draw text to the screen. Workarounds using IDISPLAY to draw the text also refuse to draw the text. This only really happens after making calls to ILICENSE.

Which leads me to think there is a problem with the .mif file..

My .MIF file was edited with the 2.0 sdk but is saved as a 1.x .MIF. (Saving as a 2.0 .MIF causes the phone to refuse to run the module). I had to use the 2.0 SDK to create the MIF because only it allows for editing license data in the .MIF.

This handset I understand has BREW 2.0, but I am developing under BREW 1.1. I understand this should NOT be an issue.

Is possible that this particular handset that I have is actaully defective? Maybe.

Is it also possible that my code is buggy? Sure.. but we have audited, tested, and thoroughly checked this code over and over again in an attempt to get things to work OK on this handset. We are also very experienced C programmer and don't make obvious mistakes.

My questions are as follows:

1. Are there any limits to .BAR and .MOD file size?
2. Does the ARM processor always run in 16-bit addressing mode?
3. Do certain pointers and data-type have to be memory aligned? (It is possible that my app is crashing due to these subtle issues.)

I noticed on some phones if I didn't take care to align enum types to 2 bytes, then I would also get erratic behavior and crashes, even on other handsets.

I suspect that memory alignment in structures is a big possibility.. but I lack the information as I am not an ARM processor expert. The BREW docs don't talk about this stuff. They assume we are all morons and shouldn't concern ourselves with these details. I agree, we shouldn't.. but when it comes to apps not running as they should at least lower-level information might be helpful. Does anyone have access to resources other than the spartan BREW docs that could help me learn more about issues with handsets?

I also want to explore the possibility that my code accesses pointers beyond the 64kb segment size.. if there is one. Does anyone know if there is a limit on the segment size of the code or data segments on the ARM architecture?

If anyone could lend insight, I would be much obligned. I will buy you a Pizza or a Beer at the BREW conference in June if you even reply to this post with any helpful knowledge.... ;)

Cheers..

1. Are there any limits to .BAR and .MOD file size?
--- As far I know no there is none. It is limited by your target phone's memory.
2. Does the ARM processor always run in 16-bit addressing mode?
--- you can compile ARM code in TUMB(16)/ARM(32) mode. There are advantages and disadvantages in each mode.
3. Do certain pointers and data-type have to be memory aligned? (It is possible that my app is crashing due to these subtle issues.)
--- ARM requires your application to access aligned memory. Don't try to access odd memory address in ARM. You can certainly use __packed directive but it is not performance oriented stuff. If you are using CONVERTBITMAP, make sure everything is right in your buffer.
Eventhough ADS/RVCT has restrictive license, but it generates way better binary than that of GCC.
ruben

1. Are there any limits to .BAR and .MOD file size?
--- As far I know no there is none. It is limited by your target phone's memory.
2. Does the ARM processor always run in 16-bit addressing mode?
--- you can compile ARM code in TUMB(16)/ARM(32) mode. There are advantages and disadvantages in each mode.
3. Do certain pointers and data-type have to be memory aligned? (It is possible that my app is crashing due to these subtle issues.)
--- ARM requires your application to access aligned memory. Don't try to access odd memory address in ARM. You can certainly use __packed directive but it is not performance oriented stuff. If you are using CONVERTBITMAP, make sure everything is right in your buffer.
Eventhough ADS/RVCT has restrictive license, but it generates way better binary than that of GCC.
ruben

Ok thanks for answering me! I do owe you a beer... I have further questions though:
--- you can compile ARM code in TUMB(16)/ARM(32) mode. There are advantages and disadvantages in each mode.
What are the advantages and disadvantages of each mode? I would guess 16-bit mode has better power consumption characteristics, yes?
--- ARM requires your application to access aligned memory. Don't try to access odd memory address in ARM. You can certainly use __packed directive but it is not performance oriented stuff. If you are using CONVERTBITMAP, make sure everything is right in your buffer.
Then _why_ do the BREW tools that generate GCC make files use -fshort-enums.. WHY do some of the BREW headers contain PACKED directives (i had to #define these as __attribue__((packed)) in gcc.. is that bad?)??
This is so exasperating!!
Should I disable all PACKED directives when building with GCC and also should i disable -fshort-enums?
(Short enums makes enums be as short as possible -- usually 1 bytes unless there are more than 256 of them)..
Should I explicitly align all memory myself? Does BREW's MALLOC not do this for me?!?!
Do I need to ALIGN all struct members using alignment directives to GCC?
Thanks!!

Ok thanks for answering me! I do owe you a beer... I have further questions though:
--- you can compile ARM code in TUMB(16)/ARM(32) mode. There are advantages and disadvantages in each mode.
What are the advantages and disadvantages of each mode? I would guess 16-bit mode has better power consumption characteristics, yes?
--- ARM requires your application to access aligned memory. Don't try to access odd memory address in ARM. You can certainly use __packed directive but it is not performance oriented stuff. If you are using CONVERTBITMAP, make sure everything is right in your buffer.
Then _why_ do the BREW tools that generate GCC make files use -fshort-enums.. WHY do some of the BREW headers contain PACKED directives (i had to #define these as __attribue__((packed)) in gcc.. is that bad?)??
This is so exasperating!!
Should I disable all PACKED directives when building with GCC and also should i disable -fshort-enums?
(Short enums makes enums be as short as possible -- usually 1 bytes unless there are more than 256 of them)..
Should I explicitly align all memory myself? Does BREW's MALLOC not do this for me?!?!
Do I need to ALIGN all struct members using alignment directives to GCC?
Thanks!!

-- THUMB instruction set is an extension of 32bit ARM instruction set and it increases code density there by reducing your binary size.
-- THUMB instructions are subset of ARM instruction, compressed to 16 bit wide opcode, on execution, these instructions are decoded to enable the same functionalities as of 32 bit mode.
-- On average you may get 30% code density at the expense of performance.
-- Relationship with respect to power consumption is not very straight forward. When you use more efficient instruction set in ARM mode, your system will consume less power. Also high code density (in thumb mode) helps to reduce power consumption.
Unfortunately, I don't use GCC at this point of time, so I may not be able to provide you all the tweaks of GCC for BREW compilation. :(
BREW MALLOC ensures that you get aligned memory.
ruben

-- THUMB instruction set is an extension of 32bit ARM instruction set and it increases code density there by reducing your binary size.
-- THUMB instructions are subset of ARM instruction, compressed to 16 bit wide opcode, on execution, these instructions are decoded to enable the same functionalities as of 32 bit mode.
-- On average you may get 30% code density at the expense of performance.
-- Relationship with respect to power consumption is not very straight forward. When you use more efficient instruction set in ARM mode, your system will consume less power. Also high code density (in thumb mode) helps to reduce power consumption.
Unfortunately, I don't use GCC at this point of time, so I may not be able to provide you all the tweaks of GCC for BREW compilation. :(
BREW MALLOC ensures that you get aligned memory.
ruben