-->
Page 1 of 1

Watchdog / Timer issues

PostPosted: Tue Jul 07, 2015 12:19 pm
by DinsFire64
Hey guys,

I'm writing software to control a series of RGB LEDs that includes cool features such as fading, pulsing, changing colors, etc all based off of a JSON string sent via UDP.

Anyway the whole project has gone smoothly up until I started to update the SDK versions. Ar first I couldn't pulse/change the color of the LEDs too quickly since the old PWM code in 0.9.4 took too long to run pwm_start(), so I started to update. The new PWM code is a lot of efficient, and allows me to fade much quicker.

The only problem is that with the new SDK I am running into two different issues. Either my timers fail to go off after a certian period of time, or the watchdog kills the system.

If I disable the watchdog using system_soft_wdt_stop() or ets_wdt_disable(), then the system will stop receiving packets. It no longer responds to any packets or commands after an extended length of time.

If I keep the watchdog enabled by feeding it and running system_soft_wdt_stop() and system_soft_wdt_restart() on long sections of code, the system stops my timers from going off after a certain period of time. On wits end, I have one timer going off every three seconds, feeding the dog and printing a statement. After 105 seconds the timer stopped going off and I noticed after a while this appeared on the UART:

Code: Select allwhy 102400 1 123855715 972612494
rm 0
pm close 7 0 0/968881879
reconnect
f 0, Current wifi state 1

scandone
add 0
aid 1
pm open phy_2,type:2 0 0
cnt


Then my device restarted my code, but it wasn't a wdt_reset. Any idea?

If I feed the device properly, sometimes the device will stop scheduling my timers. For example, at one point I was printing a string right before the disarm, arm, etc for a timer. I would see the device print that line and the code for the timer would never run. It would force a restart.

So my main question is three fold, how can I convince the ESP8266 to stay alive with the espconn listening with the watchdog restarting every time I stop running code? Or how can i have my timers go off with the watchdog disabled? Or how can I keep the watchdog happy with how I have this code setup?

Or rather can I find example code that keeps the wdt timer happy? I don't quite understand how I am supposed to lay out my code so that the system doesn't think my code is stuck. I can run someone through the layout of my code, but I feel that I've made this post long enough.

Appreciate the insight guys. This embedded system is the most fun I've had in a while.

Re: Watchdog / Timer issues

PostPosted: Thu Jul 16, 2015 9:11 am
by eriksl
I think you're trying too much code (too long...) in the main thread, so a.o. the watchdog can't be fed in time. Make it a custom to never do lengthy stuff when called from timers or callbacks. From interrupts even less, only a few lines of code. All callbacks (including interrupt callbacks) should post a background task and that task should do the real work. Also not too long, be sure to yield to system if it takes to long and request to be called again to finish the job.

Keep in mind the "sdk"-system (including wlan, ip and watchdog) needs to be called frequently to work, if you keep running your own code, that can't happen. There is no preemptive multitasking.

This is very basis of every operating-system-less embedded system.

Re: Watchdog / Timer issues

PostPosted: Thu Jul 16, 2015 9:12 am
by eriksl
BTW Espressif already mention this fact in their documents.