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

Developer

Forums

Forums:

Is there any guy in this world who know exactly how BREW Watchdog works and can share this information with me?
I guess a lot of developers experience unexpected crashes (power cycles) of their app, but you can never say for sure if this was a watchdog.
What I want to know is a "deep inside" of a watchdog. How exactly does it monitors? What exactly is the algorythm it uses to start and end its timing?

Why exactly am I having the following problem: My application processes key events with speed 1 key per 500ms. It's a very busy and serious application, it makes a lot of computations. And I reasobly believe that 500ms is a very good time. But if I press the key with 250ms delay (I can do this with my finger) - I get a watchdog triggering in 1 minute. Why is that?!?!?! I return control to BREW once 500ms!!! Isn't this enought? But it seemes like those keys are in some queue and watchdog will not be "petted" until the entire queue is depleted.
So, in theory, I'm able to crash ANY application if I press keys faster than it processes it. You say you have a good application that is stable? Try to run Grinder with 1ms delay...

BTW, I use LG VX4400 for those tests...

On most devices running an RTOS(phones), a watchdog is used to check the health of a thread or a process.
If a BREW application takes up too much of the CPU and does not yield so that another task on the phone can be executed, the phone will be reset.
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(around 100 msec) . This again might trigger the watchdog timer. The timer should be after (and not before) a particular block of processing is done as shown above.
also donot use tighter loops like for loops...

On most devices running an RTOS(phones), a watchdog is used to check the health of a thread or a process.
If a BREW application takes up too much of the CPU and does not yield so that another task on the phone can be executed, the phone will be reset.
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(around 100 msec) . This again might trigger the watchdog timer. The timer should be after (and not before) a particular block of processing is done as shown above.
also donot use tighter loops like for loops...

"I return control to BREW once 500ms!!! Isn't this enought? "
No, its not. At least in my experience. 500ms is a long time.
If the watchdog causes a reboot on a test enabled phone, I always see "dog.c" before the phone recycles.

"I return control to BREW once 500ms!!! Isn't this enought? "
No, its not. At least in my experience. 500ms is a long time.
If the watchdog causes a reboot on a test enabled phone, I always see "dog.c" before the phone recycles.

skumar_rao, You missing the point. I never use tight loop in application. The longest event handling takes 500ms, which definitely does not exceed the watchdog timer.
But my point is that you can implement super-high-speed event processing that will return in 5 ms and Grinder still will be able to crash the phone if it will be set to make 2ms pause between events.
And, I saw the information you posted in some article on the net. It does not describe the way watchdog REALLY works.

skumar_rao, You missing the point. I never use tight loop in application. The longest event handling takes 500ms, which definitely does not exceed the watchdog timer.
But my point is that you can implement super-high-speed event processing that will return in 5 ms and Grinder still will be able to crash the phone if it will be set to make 2ms pause between events.
And, I saw the information you posted in some article on the net. It does not describe the way watchdog REALLY works.

jmiller2, I agree with you, it's not enought "from experience".
But NSTL test cases say that application should respond in 2 SECONDS.
Thanks for the hint, I'll try to use logger (I guess you mean this by saying that you see "dog.c").

jmiller2, I agree with you, it's not enought "from experience".
But NSTL test cases say that application should respond in 2 SECONDS.
Thanks for the hint, I'll try to use logger (I guess you mean this by saying that you see "dog.c").

http://www.embedded.com/2000/0011/0011feat4.htm
http://www.embedded.com/story/OEG20010920S0064
http://www.embedded.com/97/feat29704.htm
Choosing the timeout interval
"....If you do not fully understand the timing characteristics of your program, you might pick a timeout interval that is too short. This could lead to occasional resets of the system, which may be difficult to diagnose. The inputs to the system, and the frequency of interrupts, can affect the length of a single loop. "

http://www.embedded.com/2000/0011/0011feat4.htm
http://www.embedded.com/story/OEG20010920S0064
http://www.embedded.com/97/feat29704.htm
Choosing the timeout interval
"....If you do not fully understand the timing characteristics of your program, you might pick a timeout interval that is too short. This could lead to occasional resets of the system, which may be difficult to diagnose. The inputs to the system, and the frequency of interrupts, can affect the length of a single loop. "

Hello Dude's,
Ive got an applications where u find lots of objects been moving,and the timer im using is 100ms.This app is loaded on the phone LG-VX6000.I started the app,kept the app without sending any events to it.
Its remained in the same flow for more than 5 minutes,does it mean that ive crossed the problem of Watchdog timer,(or) is this not the way to check it.
Do post.

Hello Dude's,
Ive got an applications where u find lots of objects been moving,and the timer im using is 100ms.This app is loaded on the phone LG-VX6000.I started the app,kept the app without sending any events to it.
Its remained in the same flow for more than 5 minutes,does it mean that ive crossed the problem of Watchdog timer,(or) is this not the way to check it.
Do post.

Hello Rajs1,
as the VX6000's watchdog is set to 60sec. so if yor application donot return the control to OS. the watchdog will bit and the phone will reset...
in ur case if ur running a application 5min. continously without returning control to the OS it will reset...after 60sec...

Hello Rajs1,
as the VX6000's watchdog is set to 60sec. so if yor application donot return the control to OS. the watchdog will bit and the phone will reset...
in ur case if ur running a application 5min. continously without returning control to the OS it will reset...after 60sec...

i have also gone through same problem... there is only one way to overcome this watchdog... and that is pass controll to system periodically.... you can have a timer in your app. (set it to say 59 sec) and when it reaches set value suspend app and return to system for say 5ms.... and then resume app.... by this way app can run for longer duration.... also if possible divide your application in time slots...say 300ms and after each chunk of processing return to system....
this is the only way to run app. longer...
sdg

i have also gone through same problem... there is only one way to overcome this watchdog... and that is pass controll to system periodically.... you can have a timer in your app. (set it to say 59 sec) and when it reaches set value suspend app and return to system for say 5ms.... and then resume app.... by this way app can run for longer duration.... also if possible divide your application in time slots...say 300ms and after each chunk of processing return to system....
this is the only way to run app. longer...
sdg

Hello,
Even if the timer is kept as 6oms,i dont find any negative impact on the phone.
Raj

Hello,
Even if the timer is kept as 6oms,i dont find any negative impact on the phone.
Raj