phone is rebooting at startup

[MyrddinEmrys]

I just started a small c++ app for my z-800, and I wanted to test it on the phone first to see if it worked. Thing is that when I lauch it, the phone reboots.

The app works well on the emulator (it always does). I do not use too much heap, float, global or static variables.

I was wondering is anyone else experienced this problem, and if so, how you solved it.

I read all of the knowledge base and FAQ, and didnt see anything concerning that particular problem.

thanks

[charliex]

The emulator isn't really an indication of it working on the phone, its pretty much just a 90% of making sure the API calls are correct, so there are lots of vital differences. Calling it an emulator is quite a stretch, its a simulator, but i digress.

Check the map file for RW data sections on the ARM build.
Check for alignment problems, 32 bit aligned etc.
Memory size, stack and heap.

Other than that, its the slog of commenting out bits of code
and checking return values etc.

The map file is your friend when it comes down to tracking the wrong type of code, floats, global non const etc, its possible to
miss something, also memory usage.

I've noticed on memory errors, if you run it a dozen times, 3/4 of the time it displays a memory error, the rest it reboots.

Also theres a watchdog that might force a reboot on a stuck condition.

You may also consider adding some sort of indicator, that uses the minimum possible dependancys, i use various things
( making it beep etc ) just to see where program flow is, though it sounds like yours is way earlier.


best of luck
charlie.

Added:

Also consider buying numega/compuwares boundschecker for Visual C++ if it is a memory overrun/logic problem, it might help you track it down. Its a useful tool to add to any programmers arsenal.

Just in case,
this is how i add the map file to one of standard brew makefiles

-LIST $(TARGET).MAP -MAP

Add it to the $(LD) line

$(LD) -LIST $(TARGET).MAP -MAP

You could remove the $(TARGET) to make it into a fixed filename, or use your rule.

Arm compiler is a bit wierd that it always spits out to stdout, using the -LIST redirects all output, you can also use normal dos redirection if you liked.

[lising]

many reasons can lead to that reboot problem. That may lie on the things you do in your application. In my own experience, I met the same problem in Z-800 because i use the IGRAPHICS_StretchBlt() function that are not supported in Z-800, and something like resource release though it hasn't been created, etc.

I suggest you try to test your program part by part. Something like comment all the sentences to let your app. work normally and then activate sentence after sentence before you finnally find the one that makes the bad... ... this maybe hard work but help.

[MyrddinEmrys]

Wow, thanks for your help. I'll get right on it!

[Murray Bonner]

The first thing I'd look for is an attempt to perform a floating point operation without using the floating point helper functions.

e.g.
double a=3.0, b=2.5, c=0.0;
int x = 0;

c = a + b; // ok on emulator but crashes phone
// should be c = FADD(a,b);

if(a>b) // condition should be FCMP_G(a,b)
// ...

x = (int) a; // works on emulator, crashes phone.

To cast a to an int:
AECHAR *wbuf = (AECHAR*)MALLOC(20);
char *buf = (char*)MALLOC(10);
FLOAT_TO_WSTR(a, wbuf, 20);
WSTR_TO_STR(wbuf,buf,10);
x = (int) STRTOUL(buf, NULL, 10);

Hope this helps.
MB

[MyrddinEmrys]

thanks, but I used fixed point math everywhere in my code. No floating point :)

[charliex]

If it was floating point (which in this case it isnt) just add

-fpu none

to the compiler switches, it won't compile any FPU stuff , giving an error, which helps track down any uses of floating point code.

How big is the EXE are you getting above 50K ?


The other thing you can do is to add the ability to trace the functions visually, this helps track down at least how far its getting.

theres a handy routine called xStatus in the example code , pull that out modify it so it uses the helper function to get the applet address, add a variable in the applet structure for the current line, then increment it everytime you call the xStatus routine, it'll take care of the wrap.

Also use IGRAPHICS_UpdateEx instead of IGRAPHICS_Update in that routine.


Add a few tests to the xStatus routine to make sure the various ptrs to applets graphics etc are valid so that if its called before the ptrs are setup it wont crash.

then setup a macro like this

#define _FUNC( name ) xStatus( name " " )

and prototype xStatus with this is a global header make sure its callable from C and C++ if you use both

now for the hard part, you have to go through all your code and at at the very start of each function add a _FUNC("");

void foo( void )
{
_FUNC("foo"); // any text you like as long as its tells you where it is.
}


Now when you run it you'll get a console style print that wraps around printing out each function call, i added a short delay to xStatus it so i could watch what it was doing.

When you don't want the macro just #define it away.

Its a very useful thing to have as a lot of compilers have __FILE__ __LINE__ but not __FUNC__ , you could also change the marco to accept __FILE__ __LINE__ etc and print it out too, but space is limited.

This is also a useful macro for profiling, memory checking etc ,as it can allow you to keep the names of the functions in the the profile data etc.

You get into the habit of adding that _FUNC macro to each call .

As i say some compilers can automate the process, but most can't

This does change the program size when its switched on , and its possible to alter results if its an alignment or such error ,but it still should help track down stuff.

It could also be use to write the log to a file or to a serial port, hardware trap logger etc etc. The key is *having* the _FUNC macro at the start of every function..

Also some compilers allow __penter __pexit for profilers etc, you can use those to print out the address of the function instead, it uses less memory and is less intrusive and easier to add.

However not all compilers support it, and you dont get the name unless they support the __FUNC__ predefined macro.

You could go all the way and add a
__PENTER("func");
__PEXIT("func");

to the start and end of each function, then you can see it go in and out, it also allows you to do flow coverage, profiling and a whole host of other things.. With a log file or serial output (key being line width here ) you can add a TAB for each __PENTER and remove it with each __PEXIT that way you'd see a nicely indented program flow.

the best would be able to get direct access to the graphics framebuffer and write a custom font routine that just printed it directly to the screen ( HINT HINT Qualcomm :) ) , with no reliance on any OS or Brew function. That way even if the OS or Brew gets screwed up you might still get some data out to the screen.

If I wasn't clear enough here, or you need some more information or implementation help, feel free to ask.

best regards,
charlie.

[MyrddinEmrys]

Nice post !

Although I fixed my problem last thursday :)

I think the problem was because I was loading a invert row ordered bitmap that was too big. The phone must have tried to flip the row back into his normal format (requires alot of memcpy), so the phone restarted because the loop took too long. I did test it with the 1.1 speed emulator, but didnt experience any problem.

And again, thanks to all for your help.