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

Developer

Forums

Forums:

I've got an app that works fine on the T720 and LGVX4400.

But, it keeps crashing on the A530 with the same message:

dog.c 0695

22F287FE

24E

0

---

Does anyone know what this means?

As far I know this happens when your watchdog timer resets your phone. It is possible that application is taking longer time, causing watchdog timer to reset the phone.
regards
ruben

As far I know this happens when your watchdog timer resets your phone. It is possible that application is taking longer time, causing watchdog timer to reset the phone.
regards
ruben

Ah, hence dog.c.
Anyone have any idea what kind of execution time ticks off the watchdog?
Seems the dog is more forgiving on the T720 and LGVX4000 I guess.
What BREW really needs is a profiler.

Ah, hence dog.c.
Anyone have any idea what kind of execution time ticks off the watchdog?
Seems the dog is more forgiving on the T720 and LGVX4000 I guess.
What BREW really needs is a profiler.

This is ridiculous. The watchdog is going off all over the place--at totally random times in the game.
If I put a sleep or a post message or whatever at various points in the main timer loop, I dunno...I guess I can try that.
What exactly are the conditions for a watchdog hang? How does it know how long someting is taking to execute? If the app has not accepted a message in awhile or something will it fire off?
Can someone go into detail about how exactly the watchdog determines if something has taken too long to execute?

This is ridiculous. The watchdog is going off all over the place--at totally random times in the game.
If I put a sleep or a post message or whatever at various points in the main timer loop, I dunno...I guess I can try that.
What exactly are the conditions for a watchdog hang? How does it know how long someting is taking to execute? If the app has not accepted a message in awhile or something will it fire off?
Can someone go into detail about how exactly the watchdog determines if something has taken too long to execute?

I got involved in a couple threads about the watchdog: in the emulator, with an extension, using a timer. But you probably won't glean too much from those threads.
Are you compiling a debug build? If so, it might be running much more slowly than the optimized version, causing your problem.

I got involved in a couple threads about the watchdog: in the emulator, with an extension, using a timer. But you probably won't glean too much from those threads.
Are you compiling a debug build? If so, it might be running much more slowly than the optimized version, causing your problem.

From the time control enters in your application watchdog timer starts and usually it is around 60 sec when watchdog timer fires (provided your application does not return control to BREW).
Couple of random thoughts:
1. Are compiling different versions of BREW than one present in the phone?
2. Did you assume something very specific to any particular handset, like bitdepth of screen?
3. Are you trying write big files(as far I know file writing speed can vary from handset to handset)?
regards
ruben

From the time control enters in your application watchdog timer starts and usually it is around 60 sec when watchdog timer fires (provided your application does not return control to BREW).
Couple of random thoughts:
1. Are compiling different versions of BREW than one present in the phone?
2. Did you assume something very specific to any particular handset, like bitdepth of screen?
3. Are you trying write big files(as far I know file writing speed can vary from handset to handset)?
regards
ruben

Quote:Originally posted by ruben
From the time control enters in your application watchdog timer starts and usually it is around 60 sec when watchdog timer fires (provided your application does not return control to BREW). Hmmm, do you mean 6 seconds? or 600 millliseconds? I don't know about on a handset, but the emulator doesn't give me more than a second or so of processing before it says the event handler took too long.

Quote:Originally posted by ruben
From the time control enters in your application watchdog timer starts and usually it is around 60 sec when watchdog timer fires (provided your application does not return control to BREW). Hmmm, do you mean 6 seconds? or 600 millliseconds? I don't know about on a handset, but the emulator doesn't give me more than a second or so of processing before it says the event handler took too long.

I'm compiling for 1.1. So, that should be kosher for this handset I guess.
There's no way anything I am doing is taking longer than 60 seconds to execute. It's just totally impossible.
I'm not writing to any files at all.
Basically I have a main timer loop that draws the screen, does all the game updating etc., and then sets itself go fire off again in the future.
The timer's duration is very short, about 10 ms--but the execution of the timer might take like 150-200ms to finish.
I've tried increasing the duration of this timer to 15 ms--still crashes.
Again, this works fine on the T720 and LGVX4400. The T720 actually is a slower device too, as far as I know.

I'm compiling for 1.1. So, that should be kosher for this handset I guess.
There's no way anything I am doing is taking longer than 60 seconds to execute. It's just totally impossible.
I'm not writing to any files at all.
Basically I have a main timer loop that draws the screen, does all the game updating etc., and then sets itself go fire off again in the future.
The timer's duration is very short, about 10 ms--but the execution of the timer might take like 150-200ms to finish.
I've tried increasing the duration of this timer to 15 ms--still crashes.
Again, this works fine on the T720 and LGVX4400. The T720 actually is a slower device too, as far as I know.

In lieu of a profiler, you could write your own instrumentation to see what's taking so long.
Or, the trial 'n' error method: Try commenting out a bug chunk of processing until it runs ok. Then uncomment pieces until it crashes again. This doesn't give you the task durations, but maybe you can isolate a single task that's eating up all the time.

In lieu of a profiler, you could write your own instrumentation to see what's taking so long.
Or, the trial 'n' error method: Try commenting out a bug chunk of processing until it runs ok. Then uncomment pieces until it crashes again. This doesn't give you the task durations, but maybe you can isolate a single task that's eating up all the time.

Well, there is no accurate way to time your code and get proper results because printlns consume like 5 zillion cycles, so does writing to the file system.
I guess I could display it on the screen though.
My miracle solution is going to be breaking up my main timer game loop into like 2 or 3 different timers that all fire off within 2-3 ms of eachother. That gives time to breathe and lets this ridiculous hyper sensitive watchdog feel good about himself.
Yet another thing that needs to be standardized in BREW--watchdog timers.
Add that to MIDI instrument tables, screen resolution, palettes, key layouts, and a host of other things in my wishlist.

Well, there is no accurate way to time your code and get proper results because printlns consume like 5 zillion cycles, so does writing to the file system.
I guess I could display it on the screen though.
My miracle solution is going to be breaking up my main timer game loop into like 2 or 3 different timers that all fire off within 2-3 ms of eachother. That gives time to breathe and lets this ridiculous hyper sensitive watchdog feel good about himself.
Yet another thing that needs to be standardized in BREW--watchdog timers.
Add that to MIDI instrument tables, screen resolution, palettes, key layouts, and a host of other things in my wishlist.

Yep, breaking up the loop into 2 or 3 different timer callbacks works. But now the frame rate sucks. I can tweak it though, and I think I can get it working half-decently.
But the watchdog should really not be that sensitive.

Yep, breaking up the loop into 2 or 3 different timer callbacks works. But now the frame rate sucks. I can tweak it though, and I think I can get it working half-decently.
But the watchdog should really not be that sensitive.

I'm getting the same error on the same handset, also at unpredictable times.
(And this is an entirely different set of problems than the ones I'm having with network-disabled phones.)
Sometimes I can finish the entire game without an error. Other times I get the error before the game even gets started. Most of the time, though, it shows up about 30-60 seconds into the game.
I'll reply here if I find anything, but right now I have higher priority tasks.

I'm getting the same error on the same handset, also at unpredictable times.
(And this is an entirely different set of problems than the ones I'm having with network-disabled phones.)
Sometimes I can finish the entire game without an error. Other times I get the error before the game even gets started. Most of the time, though, it shows up about 30-60 seconds into the game.
I'll reply here if I find anything, but right now I have higher priority tasks.

The Samsung SCH A530
LCD has a theoretical MAX refresh rate of 4fps.
(This is if the brew docs are correct)
From what I've seen the phone is generally slow all around.
I normally run my callback timers at 200-500ms
I have NEVER had a problem w/ the watch dog.
I do a couple things to keep the game short and sweet during an update.
Buffer all input. (Currently using a circular queue, but many options) and do the input calculations all at once, then do one draw to screen and one flip.
In other words, do react to key presses until ur update comes around.
Also, you shouldn't be calling flip more often then every 250ms on this phone(when u do an update). Otherwise, your creating a backlog of updates, slowing everything down, until your app is so ahead of the phone that the watchdog goes off. Or something of that nature.
Sum all this up, SCH A530, is not a prime choice for real time games. I know we're not planning to put anything intenese on it.

The Samsung SCH A530
LCD has a theoretical MAX refresh rate of 4fps.
(This is if the brew docs are correct)
From what I've seen the phone is generally slow all around.
I normally run my callback timers at 200-500ms
I have NEVER had a problem w/ the watch dog.
I do a couple things to keep the game short and sweet during an update.
Buffer all input. (Currently using a circular queue, but many options) and do the input calculations all at once, then do one draw to screen and one flip.
In other words, do react to key presses until ur update comes around.
Also, you shouldn't be calling flip more often then every 250ms on this phone(when u do an update). Otherwise, your creating a backlog of updates, slowing everything down, until your app is so ahead of the phone that the watchdog goes off. Or something of that nature.
Sum all this up, SCH A530, is not a prime choice for real time games. I know we're not planning to put anything intenese on it.

Profiling:
Try using Brew Logger DBGPRINTF and GETUPTIMEMS. Start new thread if you have questions.
Callbacks/Processing:
Warnings regarding callback taking too much time can be ignored, but you should follow the concept of breaking up the processing. Watchdog is 60 seconds typically ( all devices I have seen ) Callback warning is 500 ms. 200ms timer callbacks are safe, but still avoiding excessive blocking in the callback is a good idea.

Profiling:
Try using Brew Logger DBGPRINTF and GETUPTIMEMS. Start new thread if you have questions.
Callbacks/Processing:
Warnings regarding callback taking too much time can be ignored, but you should follow the concept of breaking up the processing. Watchdog is 60 seconds typically ( all devices I have seen ) Callback warning is 500 ms. 200ms timer callbacks are safe, but still avoiding excessive blocking in the callback is a good idea.

How come the A530 has such a ridiculous watchdog though? It's like 100 ms, not 60 seconds :)

How come the A530 has such a ridiculous watchdog though? It's like 100 ms, not 60 seconds :)

I know the thing is crapping out in dog.c, but something about this just doesn't sound right to me.
I don't think the watchdog is 100ms, but instead I think something is preventing the dog from being kicked where it normally would. Or even more likely, there's another condition that is triggering a dog style timer, or maybe there's multiple watchdogs with different timeouts and kick locations.
What I don't know is what this could be, and it concerns me that so many others have run into it. I've been relying on others to do cursory testing of the A530 so far, and I haven't had any reports of problems with dog.c, even though there are a few places where my code is running for 250ms or maybe even longer.
That said, there hasn't been extensive testing on my app yet, but it will be coming soon. I'll post if I have anything more to add.
One thing that I've been thinking is that maybe the A530 kicks the dog in the screen update routine, and given the screwy queue behaviour of IDISPLAY_Update(), the actual update might not be happening for a long time. Maybe try using IDISPLAY_UpdateEx() with FALSE so the update happen immediately instead of being queued and see if that helps at all.
Tom

I know the thing is crapping out in dog.c, but something about this just doesn't sound right to me.
I don't think the watchdog is 100ms, but instead I think something is preventing the dog from being kicked where it normally would. Or even more likely, there's another condition that is triggering a dog style timer, or maybe there's multiple watchdogs with different timeouts and kick locations.
What I don't know is what this could be, and it concerns me that so many others have run into it. I've been relying on others to do cursory testing of the A530 so far, and I haven't had any reports of problems with dog.c, even though there are a few places where my code is running for 250ms or maybe even longer.
That said, there hasn't been extensive testing on my app yet, but it will be coming soon. I'll post if I have anything more to add.
One thing that I've been thinking is that maybe the A530 kicks the dog in the screen update routine, and given the screwy queue behaviour of IDISPLAY_Update(), the actual update might not be happening for a long time. Maybe try using IDISPLAY_UpdateEx() with FALSE so the update happen immediately instead of being queued and see if that helps at all.
Tom

Set all timers with >= 150ms . It will solve your problem.

Set all timers with >= 150ms . It will solve your problem.

Unless you want to write a half decent game with a good frame rate.

Unless you want to write a half decent game with a good frame rate.

Yes, if there is a bug on the phone that prevents you from using timers faster than 150ms, then that is a serious problem with that phone. Is this the type of thing that could be fixed with an OTA patch or something?
I'm sure you guys know that simply saying you have to set all timers greater than 150ms isn't really a viable option for a lot of apps.
Can Qualcomm give us any additional information about possible work arounds, or what (if anything) is going to be done to fix this problem on the phones?
Tom

Yes, if there is a bug on the phone that prevents you from using timers faster than 150ms, then that is a serious problem with that phone. Is this the type of thing that could be fixed with an OTA patch or something?
I'm sure you guys know that simply saying you have to set all timers greater than 150ms isn't really a viable option for a lot of apps.
Can Qualcomm give us any additional information about possible work arounds, or what (if anything) is going to be done to fix this problem on the phones?
Tom

I think that basically there's a major disconnect between the handset manufacturers and the developers. The OEMs largely don't care because the carriers are their customers--and we'll develop for whatever crap they put out. But I really wish they'd talk to some of us before finalizing the firmware. There are some manufacturers that are really good about this, by the way.

I think that basically there's a major disconnect between the handset manufacturers and the developers. The OEMs largely don't care because the carriers are their customers--and we'll develop for whatever crap they put out. But I really wish they'd talk to some of us before finalizing the firmware. There are some manufacturers that are really good about this, by the way.

What is needed is some sort of process/forum/mechanism whereby issues, as well as suggestions for improvement, with BREW implementations are recorded and:
- fed back to OEMs
- fed back to Qualcomm
- available to all BREW developers and carriers.
This does not seem to be the case now. Issues are reported ad-hoc, and there is no visibility into the issue reporting process.

What is needed is some sort of process/forum/mechanism whereby issues, as well as suggestions for improvement, with BREW implementations are recorded and:
- fed back to OEMs
- fed back to Qualcomm
- available to all BREW developers and carriers.
This does not seem to be the case now. Issues are reported ad-hoc, and there is no visibility into the issue reporting process.

Issues should be submitted to brew-support with sample code and an explanation of what the problem is. We test the code and verify that the problem is in fact a handset problem. The OEM is then informed of the issue and any handsets that they are currently porting are checked to ensure the problem does not exist. We document the issue in the DDS, and add test cases to the porting evaluation kit to ensure that the issues do not arise on future handsets.
Often the issues can lie outside of "BREW" By this I mean that the Carrier is often responsible for the handset requirements. Keys, display, battery, audio, ext can all be carrier requirements. When this is the case we escalate the issue to the carrier relations person. The carrier then chooses to adopt or ignore the request. You can contact your carrier directly if you have concerns for future handset requirements, or can email to brew-support with an explanation of what you require and why.

Issues should be submitted to brew-support with sample code and an explanation of what the problem is. We test the code and verify that the problem is in fact a handset problem. The OEM is then informed of the issue and any handsets that they are currently porting are checked to ensure the problem does not exist. We document the issue in the DDS, and add test cases to the porting evaluation kit to ensure that the issues do not arise on future handsets.
Often the issues can lie outside of "BREW" By this I mean that the Carrier is often responsible for the handset requirements. Keys, display, battery, audio, ext can all be carrier requirements. When this is the case we escalate the issue to the carrier relations person. The carrier then chooses to adopt or ignore the request. You can contact your carrier directly if you have concerns for future handset requirements, or can email to brew-support with an explanation of what you require and why.

I remember when BREW as in Beta, I found a bug in the Z800 firmware where it wouldn't let you use -1 as an argument for the width or height in a bitblt. I reported it to BREW tech support, adn they told me it was a Sharp issue. Well duh. But I figured that maybe they'd at least tell Sharp about it and they would fix it. But when I got the retail version of the phone, the same horrific bug was present. After that I figured reporting firmware bugs to Qualcomm was useless. It seems like they test the applications more than the actual firmware on the handset.

I remember when BREW as in Beta, I found a bug in the Z800 firmware where it wouldn't let you use -1 as an argument for the width or height in a bitblt. I reported it to BREW tech support, adn they told me it was a Sharp issue. Well duh. But I figured that maybe they'd at least tell Sharp about it and they would fix it. But when I got the retail version of the phone, the same horrific bug was present. After that I figured reporting firmware bugs to Qualcomm was useless. It seems like they test the applications more than the actual firmware on the handset.

This process was formalized after the z-800 was released. Please do report discrepancies and bugs to us. It will help your fellow developers and ensure the stability of future devices.
TBT does do extensive testing of apps. This is a carrier requirement. There are no requirements for independent testing of handsets. The PEK is a test suite developed by Qualcomm, and executed by any combination of QC, Carrier, and/or OEM.

This process was formalized after the z-800 was released. Please do report discrepancies and bugs to us. It will help your fellow developers and ensure the stability of future devices.
TBT does do extensive testing of apps. This is a carrier requirement. There are no requirements for independent testing of handsets. The PEK is a test suite developed by Qualcomm, and executed by any combination of QC, Carrier, and/or OEM.

It'd seem like it'd make a lot more sense to force the handset makers to pass a conformance test than the Apps, like OpenGL for instance. Obviously testing both is best, but not forcing the makers to test the phones seems a lot worse, after all a badly behaving app can be deleted a badly behaved firmware in a phone is a different story.
Case in point the VX6000.

It'd seem like it'd make a lot more sense to force the handset makers to pass a conformance test than the Apps, like OpenGL for instance. Obviously testing both is best, but not forcing the makers to test the phones seems a lot worse, after all a badly behaving app can be deleted a badly behaved firmware in a phone is a different story.
Case in point the VX6000.

Charliex,
The OEMS have to pass the PEK (Porting Evaluation Kit) tests and a few others before a device is released. The PEK is getting more thorough with each new release, but issues still exist that PEK does not pick up.
Qualcomm needs to be more proactive in coordinating the reporting and fault resolution of these bugs, as well as pushing the OEMS to institute better quality assurance measures duing the handset development cycle.

Charliex,
The OEMS have to pass the PEK (Porting Evaluation Kit) tests and a few others before a device is released. The PEK is getting more thorough with each new release, but issues still exist that PEK does not pick up.
Qualcomm needs to be more proactive in coordinating the reporting and fault resolution of these bugs, as well as pushing the OEMS to institute better quality assurance measures duing the handset development cycle.

Given the state of the LGE VX6000 i find it difficult to believe the conformance tests are worthwhile, one of the biggest gotchas in brew is the 100ms or so timer watchdog, which is trival to test, yet the A530 slips through.
Given the reluctance to allow end users to upgrade firmware on phones, and the time involved it'd be a lot better to get it down.
The sheer number of brew API releases can't be helping much either, it'd be nicer to see more time in maturing the API fleshing out the stuff we really need and have less releases.

Given the state of the LGE VX6000 i find it difficult to believe the conformance tests are worthwhile, one of the biggest gotchas in brew is the 100ms or so timer watchdog, which is trival to test, yet the A530 slips through.
Given the reluctance to allow end users to upgrade firmware on phones, and the time involved it'd be a lot better to get it down.
The sheer number of brew API releases can't be helping much either, it'd be nicer to see more time in maturing the API fleshing out the stuff we really need and have less releases.

Just curious, what did you find wrong with the VX6000? I ported a couple titles to the VX6000, and it didn't seem so bad. The problems I noticed were differences between BREW 1.1 and 2.0.

Just curious, what did you find wrong with the VX6000? I ported a couple titles to the VX6000, and it didn't seem so bad. The problems I noticed were differences between BREW 1.1 and 2.0.

Quote:Originally posted by tamoghna
Set all timers with >= 150ms . It will solve your problem.
Thanks tamoghna for a definitive answer, albeit not the greatest answer for someone trying to make an action game.
I presently set my timer when I'm done processing and drawing. I note the time at the beginning and then calculate what to set the timer to, to achieve my desired rate. The history of why I do that goes back to a J2ME version of the game that was having inputs starved on a particular phone so I set it at the end and if the timeout would be smaller than a couple milliseconds I set it to some small, but non-zero, value, to prevent starving the system.
Anyway, I don't know if it is possible to starve inputs on BREW or not, but will it work to set the timer for 150 at the beginning of the timer callback, then process for 100+ msec and return? Does there need to be 150 msec between calls or from beginning of timer to beginning of timer (regardless of how long the timer callback runs)? What happens if processing takes more than 150msec, will the system get starved in some way?
Thanks,
Paul

Quote:Originally posted by tamoghna
Set all timers with >= 150ms . It will solve your problem.
Thanks tamoghna for a definitive answer, albeit not the greatest answer for someone trying to make an action game.
I presently set my timer when I'm done processing and drawing. I note the time at the beginning and then calculate what to set the timer to, to achieve my desired rate. The history of why I do that goes back to a J2ME version of the game that was having inputs starved on a particular phone so I set it at the end and if the timeout would be smaller than a couple milliseconds I set it to some small, but non-zero, value, to prevent starving the system.
Anyway, I don't know if it is possible to starve inputs on BREW or not, but will it work to set the timer for 150 at the beginning of the timer callback, then process for 100+ msec and return? Does there need to be 150 msec between calls or from beginning of timer to beginning of timer (regardless of how long the timer callback runs)? What happens if processing takes more than 150msec, will the system get starved in some way?
Thanks,
Paul

Each handset has an internal watchdog timer.
The default value of this timer is around 60 seconds.
If an application continuously runs within a function for more
than this value then the watchdog timer kicks in and it will reset
the phone.
To prevent your application from triggering the watchdog timer it
should give up control to the BREW system periodically.
For example take a look at the following code e.g.
app_Handle_event()
{
switch(wParam)
{
case EVT_COMMAND:
for (a large number of iterations)
{
//Do some processing
}
}

Here the “for” loop is a tight loop. It does not give up control till
all the iterations are done. On the handset, when control enters
app_handleEvent(), the watchdog timer starts. If control is still
within app_handleEvent() when the timer times out
(approximately 60 seconds) then the phone will reset.
The application should break up such processes into batches as follows(only an example):
app_Handle_event()
{
switch(wParam)
{
case EVT_COMMAND:
ISHELL_SetTimer( 200 msec);
}

Timer_CallBack_function()
{
//Do a bit of processing which will not exceed the watchdog timer
// After this processing set timer again
ISHELL_SetTimer(200 msec);

This is the method in which most applications (specifically games
with animation) are developed. The value of the timer that
the application sets through ISHELL_SetTimer should not be too
small (< 150ms) . This again might trigger the watchdog
timer. If the timers are set too small, the BREW layer event queue
would have a tight sequence of events ( to fire the timers). Due
to this, the watchdog timer doesn't get a chance to reset itself.
The watchdog timer sees this as a tight loop and resets the
handset. On some handsets, the watchdog seems to be more
sensitive in this scenario (OEM dependent!)
The timer should be after (and not before) a particular block of
processing is done as shown above.

Each handset has an internal watchdog timer.
The default value of this timer is around 60 seconds.
If an application continuously runs within a function for more
than this value then the watchdog timer kicks in and it will reset
the phone.
To prevent your application from triggering the watchdog timer it
should give up control to the BREW system periodically.
For example take a look at the following code e.g.
app_Handle_event()
{
switch(wParam)
{
case EVT_COMMAND:
for (a large number of iterations)
{
//Do some processing
}
}

Here the “for” loop is a tight loop. It does not give up control till
all the iterations are done. On the handset, when control enters
app_handleEvent(), the watchdog timer starts. If control is still
within app_handleEvent() when the timer times out
(approximately 60 seconds) then the phone will reset.
The application should break up such processes into batches as follows(only an example):
app_Handle_event()
{
switch(wParam)
{
case EVT_COMMAND:
ISHELL_SetTimer( 200 msec);
}

Timer_CallBack_function()
{
//Do a bit of processing which will not exceed the watchdog timer
// After this processing set timer again
ISHELL_SetTimer(200 msec);

This is the method in which most applications (specifically games
with animation) are developed. The value of the timer that
the application sets through ISHELL_SetTimer should not be too
small (< 150ms) . This again might trigger the watchdog
timer. If the timers are set too small, the BREW layer event queue
would have a tight sequence of events ( to fire the timers). Due
to this, the watchdog timer doesn't get a chance to reset itself.
The watchdog timer sees this as a tight loop and resets the
handset. On some handsets, the watchdog seems to be more
sensitive in this scenario (OEM dependent!)
The timer should be after (and not before) a particular block of
processing is done as shown above.

Hmm, for games, the 25fps (or the closest :cool: ) is required, i thought also using timers.. but i wanted to set a timer according to the amount of time required by the main routine, with of course a minimum value..
But according to http://www.qualcomm.com/brew/developer/resources/ds/faq/techfaq14.html#T1J we cannot get the time in ms.. wow..
So i decided to use a brute ISHELL_Resume(shell, &callback); which works fine.. (btw slow key events, dunno if it is because of the phone of because of the Resume callback, but still ok..)
Is it a correct way?
/kUfa

Hmm, for games, the 25fps (or the closest :cool: ) is required, i thought also using timers.. but i wanted to set a timer according to the amount of time required by the main routine, with of course a minimum value..
But according to http://www.qualcomm.com/brew/developer/resources/ds/faq/techfaq14.html#T1J we cannot get the time in ms.. wow..
So i decided to use a brute ISHELL_Resume(shell, &callback); which works fine.. (btw slow key events, dunno if it is because of the phone of because of the Resume callback, but still ok..)
Is it a correct way?
/kUfa

Quite simply, 150ms of time between frames is unacceptable for games.
Fortunately, it also isn't the complete story and doesn't seem to be necessary at all. I've been waiting for confirmation on a title I know uses faster timers before posting.
I've got a title running on the A530 with a 10ms timer between frames without hitting the dog.c problem.
A previous version of the code would hit the dog.c error in some conditions, but after making two code changes (they were made for a different phone and not intended to fix this problem) things started working correctly on the A530. I don't know which solved things, but here's what I did.
1. I use IDISPLAY_UpdateEx(m_pDisplay, FALSE) instead of IDISPLAY_Update(). This causes the screen to be updated immediately instead of the update being inserted as an event into the queue.
2. I trap the 0x0405 event and return TRUE. This is meant to disable the screen saver type functionality (see other threads), but doesn't seem to do that on the A530. I haven't confirmed or denied that the A530 actually gets this event.
I'd suggest those of you having problems try one or both of those things and see if it has any useful effect. Please post back here if you have some more data ;)
Tom

Quite simply, 150ms of time between frames is unacceptable for games.
Fortunately, it also isn't the complete story and doesn't seem to be necessary at all. I've been waiting for confirmation on a title I know uses faster timers before posting.
I've got a title running on the A530 with a 10ms timer between frames without hitting the dog.c problem.
A previous version of the code would hit the dog.c error in some conditions, but after making two code changes (they were made for a different phone and not intended to fix this problem) things started working correctly on the A530. I don't know which solved things, but here's what I did.
1. I use IDISPLAY_UpdateEx(m_pDisplay, FALSE) instead of IDISPLAY_Update(). This causes the screen to be updated immediately instead of the update being inserted as an event into the queue.
2. I trap the 0x0405 event and return TRUE. This is meant to disable the screen saver type functionality (see other threads), but doesn't seem to do that on the A530. I haven't confirmed or denied that the A530 actually gets this event.
I'd suggest those of you having problems try one or both of those things and see if it has any useful effect. Please post back here if you have some more data ;)
Tom

That is very interesting Vexxed.
Here is what I was considering doing, but it may not be necessary based upon your findings.
Since, according to tamoghna, you just need to delay for 150ms once every 60 seconds (to keep the watchdog happy), I was going to have my wrapper for the timer set function keep track of when I delay for >=150 and only in the case that I don't delay >=150 for about 40 seconds, it will set the timer for 150 (indepdent of what delay I wanted) to keep the watchdog happy. This will give me a small hiccup every 40 seconds, but in my case there are times when the screen isn't scrolling, so I can request timer delays of 150 at some times (resetting my 40 second timer at times when it won't be so noticeable). So it is only in periods that lack such a condition for 40 seconds that I must resort to forcing a single slow update.
I am, however, first going to try the UpdateEx as Vexxed has suggested.
Paul

That is very interesting Vexxed.
Here is what I was considering doing, but it may not be necessary based upon your findings.
Since, according to tamoghna, you just need to delay for 150ms once every 60 seconds (to keep the watchdog happy), I was going to have my wrapper for the timer set function keep track of when I delay for >=150 and only in the case that I don't delay >=150 for about 40 seconds, it will set the timer for 150 (indepdent of what delay I wanted) to keep the watchdog happy. This will give me a small hiccup every 40 seconds, but in my case there are times when the screen isn't scrolling, so I can request timer delays of 150 at some times (resetting my 40 second timer at times when it won't be so noticeable). So it is only in periods that lack such a condition for 40 seconds that I must resort to forcing a single slow update.
I am, however, first going to try the UpdateEx as Vexxed has suggested.
Paul

DBGPRINTF is so slow with the Logger that it will probably get in the way of assessing your problem. Better to write your 'printf's to a file, then look at after your process runs.

DBGPRINTF is so slow with the Logger that it will probably get in the way of assessing your problem. Better to write your 'printf's to a file, then look at after your process runs.

I'm using GETUPTIMEMS(), not GETTIMEMS(), in an application and it seems to be working ok for me. Its probably what you want anyway, because its based on an internal clock, not one that is occasionally updated by the base station. Perfect for seeing how long since the last event loop.

I'm using GETUPTIMEMS(), not GETTIMEMS(), in an application and it seems to be working ok for me. Its probably what you want anyway, because its based on an internal clock, not one that is occasionally updated by the base station. Perfect for seeing how long since the last event loop.

Paul -
Did the UpdateEx() stuff change anything for you?
Tom

Paul -
Did the UpdateEx() stuff change anything for you?
Tom

Yes Vexxed, it apparently fixed my problems (I say apparently because I haven't done extensive testing, but it would crash very often before and I have left it running over night without a failure now). I set a 5ms timer (at least) after I'm done painting and after the UpdateEx and I don't lock up any more.
Thanks for the tip.
Paul

Yes Vexxed, it apparently fixed my problems (I say apparently because I haven't done extensive testing, but it would crash very often before and I have left it running over night without a failure now). I set a 5ms timer (at least) after I'm done painting and after the UpdateEx and I don't lock up any more.
Thanks for the tip.
Paul

Same for me, I replaced all my updates with updateex and broke my main loop into 2 timers. The timers still get called every 2 ms or so, but now there's 2 of them so it 'breathes' inbetween the game update logic and drawing. Seems to have worked.
Of course, the LCD can still only reliably do 4 fps, so the game still smears a bit--but there's nothing you can do about that. It's too bad--this phone actually is pretty fast...but the screen is horrible, and the watchdog thing cripples it. Not to mention the godawful color palette on this one.

Same for me, I replaced all my updates with updateex and broke my main loop into 2 timers. The timers still get called every 2 ms or so, but now there's 2 of them so it 'breathes' inbetween the game update logic and drawing. Seems to have worked.
Of course, the LCD can still only reliably do 4 fps, so the game still smears a bit--but there's nothing you can do about that. It's too bad--this phone actually is pretty fast...but the screen is horrible, and the watchdog thing cripples it. Not to mention the godawful color palette on this one.

Btw using the resume stuff i mentioned before, i do not need timers for my game, and it s not rebooting (lg4400 and t720)
/kUfa

Btw using the resume stuff i mentioned before, i do not need timers for my game, and it s not rebooting (lg4400 and t720)
/kUfa

I'm not in agreement about the 4fps. Pixels can go from dark to light at a much faster rate than that, but bright to dark is very slow. I do see the smearing (around bright areas) like you're talking about, flarb.
I have a meter in my game which sweeps up and then down again. On "normal" phones, I have it go dim to bright on the way up and then bright to dim on the way down. On this phone the way up is wonderful, very nice and smooth, but on the way down it is terrible due to the slow fading out of the pixels. So my solution is that once the meter gets to the top (for this phone only) I invert back to dim and then go dim to bright on the way down again. (Sure enough the meter is like a quarter of the way down before all the pixels dim, so I need to delay at the top for a while too).
I don't know what this is worth to most people since bright and dark pixels exist, but in my case I was able avoid the problem when it matters the most.
Good luck,
Paul

I'm not in agreement about the 4fps. Pixels can go from dark to light at a much faster rate than that, but bright to dark is very slow. I do see the smearing (around bright areas) like you're talking about, flarb.
I have a meter in my game which sweeps up and then down again. On "normal" phones, I have it go dim to bright on the way up and then bright to dim on the way down. On this phone the way up is wonderful, very nice and smooth, but on the way down it is terrible due to the slow fading out of the pixels. So my solution is that once the meter gets to the top (for this phone only) I invert back to dim and then go dim to bright on the way down again. (Sure enough the meter is like a quarter of the way down before all the pixels dim, so I need to delay at the top for a while too).
I don't know what this is worth to most people since bright and dark pixels exist, but in my case I was able avoid the problem when it matters the most.
Good luck,
Paul

Just for information, i had the same problems (doggy) this morning when porting my apps for the a530..
I just add a separate timer for the repaint, and moved to UpdateEx.. Now with timers of 10ms it works fine! :cool:
/kUfa

Just for information, i had the same problems (doggy) this morning when porting my apps for the a530..
I just add a separate timer for the repaint, and moved to UpdateEx.. Now with timers of 10ms it works fine! :cool:
/kUfa