Better understanding of the system_soft_wdt_feed function

[kolban]

In SDK 1.3, there was a new API added called "system_soft_wdt_feed". Unfortunately, there isn't much else to go on. The docs simply say "feed software watchdog". I am hoping that this is a function that can be called within user code to give control back to the ESP8266 to do what it "periodically needs to do" so that I can stay within use code control ... for example, if I want to block for a long time, then I can block for 10 milliseconds, call the system_soft_wdt_feed() function and then go back to blocking again for another 10 milliseconds and repeat as needed. However ... I simply don't know if that is the intent or desire of this function. I am hoping that someone in the support department at Espressif can post more details of this interesting function.

Neil

[dkinzer]

My perception is that calling system_soft_wdt_feed() simply resets the software watchdog so that it doesn't fire. If you want to yield back to the system so that it can process WiFi, etc. take a look at the file cont.S in the ESP8266-Arduino code base. I've incorporated something similar in the code base that I'm working on and it works great to yield back to the system and have control returned to the yield point later.

[kolban]

Howdy Don,
Are you suggesting that calling the "system_soft_wdt_feed" merely says to the watchdog "I know you are there ... don't worry ... I'll get back to you eventually ...." ... effectively subverting the purpose of the watchdog completely? I would hope that the "system_soft_wdt_feed()" is actually an SDK implementation of "yield()" that returns control to the SDK ... lets the SDK take care of ALL its housekeeping and then returns control back to where the "system_soft_wdt_feed()" was called.

Before bed last night, I wrote a test to see if this would work. I created a 30 second loop which would otherwise case a hard timer based reset and in that 30 second loop, every 10msecs called "system_soft_wdt_feed()". My experiment seemed to show NO timer based exception. However ... I haven't completed all my tests yet ... so the jury is still out.

Neil

[dkinzer]

Are you suggesting that calling the "system_soft_wdt_feed" merely says to the watchdog "I know you are there ... don't worry ... I'll get back to you eventually ...."

Yes, I am. In just about the same way that poking a hardware watchdog does nothing more than reset its timer.

I added system_soft_wdt_feed() to a test app and timed how long it took to execute. The result is 14 RTC TImer2 ticks (each tick being 200nS). That's not long enough to do much.

Then I took a look at the actual code. system_soft_wdt_feed() maps to pp_soft_wdt_feed() and the code for it is shown below. As you can see, it doesn't do much. It does store zero at address 3ffe8dc0 - probably the soft watchdog counter.

Code: Select all

40219a20:   000600
40219a23:   800460
...
40219a78:   fe8dc0
40219a7b:   3f
...
40219a7c <pp_soft_wdt_feed>:
40219a7c:   ffff51          l32r   a5, 40219a78 <pp_soft_wdt_init+0x20>
40219a7f:   040c            movi.n   a4, 0
40219a81:   004542          s8i   a4, a5, 0
40219a84:   73a022          movi   a2, 115
40219a87:   ffe631          l32r   a3, 40219a20
40219a8a:   0020c0          memw
40219a8d:   c56322          s32i   a2, a3, 0x314
40219a90:   f00d            ret.n


[dkinzer]

On further study, I realized that the code at 40219a84 through 40219a8d (in my earlier post) stores the value 0x73 (115) to address 0x60000914 (i.e 0x60000600 + 0x314). In other places I've seen that referred to as resetting the watchdog timer and used, for example, immediately prior to performing Flash erase, Flash write, etc.

[eriksl]

I you need to reset watchdogs (either hardware or software) you're doing something seriously wrong. If you take care that the SDK-code gets called frequently (because you yield execution, just return), WLAN will work correctly and the watchdog will not timeout.

[kolban]

I issued an espconn_connect() call which should form a TCP connection. Immediately afterwards, I execute a loop as follows

Code: Select all

while(connected == false) {
   system_soft_wdt_feed();
}


I also registered an espconn_regist_connetcb() which, when called, sets the global variable "connected" to true. My thinking is that I would have achieved a logical "blocking" connect() call. Unfortunately, after the espconn_connect(), we enter the while loop but never exit as the connected callback doesn't appear to be invoked.

I had really hoped that calling system_soft_wdt_feed() would have given control back to the ESP controller to do its work and then return control to me after having processed what ever needed to be processed (such as TCP connections).

If all system_soft_wdt_feed() does is caused the watch dog timer not to fire ... I don't get its purpose. Why would we want to do that?

Neil

[eriksl]

Code: Select all

while(connected == false) {
   system_soft_wdt_feed();
}


This is the wrong approach. Don't mess with the watchdog.

At startup the user_init function is called. There do the necessary configuration that needs to be done there (actually very little, I don't know from the top of my head, probably none in your case). Also there register a callback for a init done callback and return.

In the "init done" callback setup your tcp listener, register a callback for incoming connections. Return.

In the "incoming connection" callback setup "data received" and "data sent" callbacks. Return.

Handle data via the two above callbacks. If at any point you need to do something lengthy (loops...), post a background task.

In the background task do "work" for a small amount of time (no endless loops!!!), if there is any work left, just post the background task again. Return.

It's all just like TCP on Windows, no blocking available nor allowed, everything is handled with callbacks.

The watchdog is not your enemy that you need to keep happy! If you do it right, you won't notice the watchdog!

[kolban]

Howdy,
Thanks for the information. Unfortunately, I am porting an application that runs on ARM and other embedded devices to the ESP8266. That application is almost 100% device independent but provides "plugins" or implement device specific areas. One of those is networking at the TCP level. The application expects me to implement a series of C language functions whose signature and contract is architected.

Among these are:

connect(IPAddr, port)

which, when called, is supposed to form a TCP connection to the target IPAddr and port and ... importantly, not return until either done or failed. Because IMMEDIATELY after returning from connect, there is a second contracted call which is:

send(data, length)

Which is meant to send data over the previous connection. It too is not meant to return until the data has been transmitted or has failed.

However, in the ESP8266 story, I figured I would implement "connect" with a call to espconn_connect(). However, that is an asynchronous call which does not block but instead later invokes a callback to describe the outcome of the connect. And here is where I get into trouble. Ideally I would like to the application's "connect()" call to block while I await the espconn_connect outcome. Since I can't block, I figured I would busy wait ... and ... while waiting ... somehow give the ESP8266 all the CPU time it needed by called system_soft_wdt_feed() ... because I "guessed" that the purpose of this was to feed kernel to let it do its stuff to handle WiFi and TCP.

In this story.... I have zero control over the application being ported ... in this story ... I need to "map" from the application "thinking" that it is making synchronous calls to the ESP8266 needing to make asynch calls.

[dkinzer]

If all system_soft_wdt_feed() does is caused the watch dog timer not to fire ... I don't get its purpose.l

It should only be used for a few unusual situations. One that I mentioned is erasing/writing Flash. Since both of these operations require a significant amount of time and you can't know how near the software WDT is to expiring you call system_soft_wdt_feed() just before you initiate those operations.