LG VX4400 watchdog timer problems | developer.brewmp.com LG VX4400 watchdog timer problems | developer.brewmp.com

Developer

LG VX4400 watchdog timer problems

Forums:

When running an application that does only an increment on an int32 and DBGPRINTF it on emulator I get as expected:
1
2
3
4
... and so on

But when running it on the phone (using BREW Logger) I get:
1
3
3
2
4
5
4
6
... and all sorts of things that make me go boom :O

So I figure out that the watchdog timer stops my humble routine and gives it a chance later on while running my next routine. This is contrary to all good sense but I know an workaround has been found because I've seen apps working on this phone.

The problem is how to work it around if you cannot be sure on the execution order due to the watchdog timer.

I don't think it's a watchdog. It's a circular buffer for DBGPRITNF() stuff, and async output to it from your DBGPRINTFs on the device to the serial port. There is a key combination to make DBGPRINTFs synchronous, but it may still not work well for your phone (###7, see thread http://brewforums.qualcomm.com/showthread.php?t=3979). Just have to live with that (or write your own logging into a file).
Watchdog would kill (reset) your phone in case your event handler routine takes too long, and not suspend and then resume the execution of your event handler. Those devices have very simple RTOS, they don't preempt your thread :)

I don't think it's a watchdog. It's a circular buffer for DBGPRITNF() stuff, and async output to it from your DBGPRINTFs on the device to the serial port. There is a key combination to make DBGPRINTFs synchronous, but it may still not work well for your phone (###7, see thread http://brewforums.qualcomm.com/showthread.php?t=3979). Just have to live with that (or write your own logging into a file).
Watchdog would kill (reset) your phone in case your event handler routine takes too long, and not suspend and then resume the execution of your event handler. Those devices have very simple RTOS, they don't preempt your thread :)

I also suffered with this problem 3 months ago, on working with three different game I used an array and filled that array through for loop but the loop does not run in proper sequence and most of the value of my array was garbage.
till now the problem is with me if got any solution please put on the forum

I also suffered with this problem 3 months ago, on working with three different game I used an array and filled that array through for loop but the loop does not run in proper sequence and most of the value of my array was garbage.
till now the problem is with me if got any solution please put on the forum

if your function takes too much time the watchdog resets the phone, if you call the timer with faster than 100ms on the 4400 it resets the phone
if the first posters just sat in a loop inside the function, itll time out
the 3rd posters problem seems unrelated and most likely just bad code

if your function takes too much time the watchdog resets the phone, if you call the timer with faster than 100ms on the 4400 it resets the phone
if the first posters just sat in a loop inside the function, itll time out
the 3rd posters problem seems unrelated and most likely just bad code

I've got an app which is rebooting the phone constantly, and I've unrolled numerous nested loops into callbacks which are fired by timers (I've tried 1, 10 and 100ms). Both the VX7000 and VX6000 reboot, though the VX6000 seems far more sensitive.
How many MS can I be doing tight-loop stuff before I have to give up to the watchdog? Lemme guess... depends on the phone. :P
-bill!

I've got an app which is rebooting the phone constantly, and I've unrolled numerous nested loops into callbacks which are fired by timers (I've tried 1, 10 and 100ms). Both the VX7000 and VX6000 reboot, though the VX6000 seems far more sensitive.
How many MS can I be doing tight-loop stuff before I have to give up to the watchdog? Lemme guess... depends on the phone. :P
-bill!

billkendrick wrote:I've got an app which is rebooting the phone constantly, and I've unrolled numerous nested loops into callbacks which are fired by timers (I've tried 1, 10 and 100ms). Both the VX7000 and VX6000 reboot, though the VX6000 seems far more sensitive.
How many MS can I be doing tight-loop stuff before I have to give up to the watchdog? Lemme guess... depends on the phone. :P
-bill!
I would say yielding every 250ms or so is neccesary in my
experience to keep BREW happy.

billkendrick wrote:I've got an app which is rebooting the phone constantly, and I've unrolled numerous nested loops into callbacks which are fired by timers (I've tried 1, 10 and 100ms). Both the VX7000 and VX6000 reboot, though the VX6000 seems far more sensitive.
How many MS can I be doing tight-loop stuff before I have to give up to the watchdog? Lemme guess... depends on the phone. :P
-bill!
I would say yielding every 250ms or so is neccesary in my
experience to keep BREW happy.

in my experiences of the the 7000 the watchdog is practically non existant, i run my timers at 1ms , however i have noticed that in some apps sometimes causes some jitter, probably due to some racing, so i experimented a bit and found 40ms ( for this particular app ) to be frame rate stable, other apps i run at 1ms with no issues, and the load is pretty heavy.
for instance on one game one i couldnt split up the loader so it has upwards 90 seconds in a load/save routine and no watchdog,though it is inside a brew system call, so i don't know if that overrides the behaviour offhand
lg's are way more sensitive to NULL pointers and accidently using globals than other phones

in my experiences of the the 7000 the watchdog is practically non existant, i run my timers at 1ms , however i have noticed that in some apps sometimes causes some jitter, probably due to some racing, so i experimented a bit and found 40ms ( for this particular app ) to be frame rate stable, other apps i run at 1ms with no issues, and the load is pretty heavy.
for instance on one game one i couldnt split up the loader so it has upwards 90 seconds in a load/save routine and no watchdog,though it is inside a brew system call, so i don't know if that overrides the behaviour offhand
lg's are way more sensitive to NULL pointers and accidently using globals than other phones

charliex wrote:in my experiences of the the 7000 the watchdog is practically non existant, i run my timers at 1ms
Yeah, it behaves reasonably well if I re-fire my routine via a 1ms timer. 10ms seems good on the 7000 and 6000 both. It's this random crashing I don't like.
Quote:lg's are way more sensitive to NULL pointers and accidently using globals than other phones
Explain "accidentally using globals"? :^)
Thx. I'm beginning to think the bug no longer lies in the realm of watchdog or stack overusage rebooting, which were my first problems. (We're porting some code from non-C to C, then specifically BREW.)
Thx!
-bill!

charliex wrote:in my experiences of the the 7000 the watchdog is practically non existant, i run my timers at 1ms
Yeah, it behaves reasonably well if I re-fire my routine via a 1ms timer. 10ms seems good on the 7000 and 6000 both. It's this random crashing I don't like.
Quote:lg's are way more sensitive to NULL pointers and accidently using globals than other phones
Explain "accidentally using globals"? :^)
Thx. I'm beginning to think the bug no longer lies in the realm of watchdog or stack overusage rebooting, which were my first problems. (We're porting some code from non-C to C, then specifically BREW.)
Thx!
-bill!

well the compiler doesn't always pick up globals, so if you miss one a lot of phones (motorolas come to mind) seem to happily run the code, either because the memory maps different and its happily overwriting a lucky spot or unallocated spot, or that the LGS actually check for it

well the compiler doesn't always pick up globals, so if you miss one a lot of phones (motorolas come to mind) seem to happily run the code, either because the memory maps different and its happily overwriting a lucky spot or unallocated spot, or that the LGS actually check for it

charliex wrote:well the compiler doesn't always pick up globals, so if you miss one a lot of phones (motorolas come to mind) seem to happily run the code, either because the memory maps different and its happily overwriting a lucky spot or unallocated spot, or that the LGS actually check for it
Ah, got it. Yeah, I've never used globals (or tried).
I just found the problem. One of the functions I ported is recursive, and I hadn't noticed. YERRGHH!
Stack go boom. Bill crush BREW like Kompressor crush vitamins.
-bill!

charliex wrote:well the compiler doesn't always pick up globals, so if you miss one a lot of phones (motorolas come to mind) seem to happily run the code, either because the memory maps different and its happily overwriting a lucky spot or unallocated spot, or that the LGS actually check for it
Ah, got it. Yeah, I've never used globals (or tried).
I just found the problem. One of the functions I ported is recursive, and I hadn't noticed. YERRGHH!
Stack go boom. Bill crush BREW like Kompressor crush vitamins.
-bill!