ESP8266 Developer Zone

Re: Better understanding of the system_soft_wdt_feed function

2017-02-28T19:51:28+08:00

thanks

Statistics: Posted by chaturvedi98765 — Tue Feb 28, 2017 7:51 pm

Re: Better understanding of the system_soft_wdt_feed function

2015-09-05T23:40:58+08:00

No you can't do that. You cannot busy wait or block or whatever. You MUST use the connect callback and in the meantime return control to the SDK code. There is no, as far as I know, no function comparable to yield() that returns to the same point in your code.

Statistics: Posted by eriksl — Sat Sep 05, 2015 11:40 pm

Re: Better understanding of the system_soft_wdt_feed function

2015-09-05T23:36:24+08:00

@dkinzer,
I'm following your logic on the notion that the system_soft_wdt_feed() function will simply cause the WDT not to fire because it has been fed.... and I am most assuredly not saying you are wrong ... however, if that is its only function ... why would one not use the pair system_soft_wdt_stop() before a time consuming area and system_soft_wdt_restart() afterwards? If all one wants to do is preempt a timer from firing, those later two would seem to be right. I can't help but "feel" that there is more to system_soft_wdt_feed() than just reset a timer and let it start ticking again.

Neil

Statistics: Posted by kolban — Sat Sep 05, 2015 11:36 pm

Re: Better understanding of the system_soft_wdt_feed function

2015-09-05T23:31:31+08:00

My thinking is that I could "logically" implement a blocking "connect" call by calling the espconn_connect() (asynchronous) and then busy waiting for a flag to be sent that would be set by the callback we registered when the espconn_connect() was called. The callback is invoked when the connection happens. Now, I fully realize that if I just do a simple busy wait ... it will fail because I have to return control BACK to the ESP8266 in order for it to process the WiFi and TCP/IP stack. It was my hope that the system_soft_wdt_feed() was a "call into" mechanism back into the ESP8266 to allow it to do all of its house keeping and then when it hit a place where it had performed a house keeping cycle, control would be returned BACK to where the system_soft_wdt_feed() was originally invoked.

The team that has built the Arduino libraries for the ESP8266 have solved the problem. They wrote some routines in assembler that provide a "yield()" call. When invoked, control is "yielded" back to the ESP8266 which is the "equivalent" of a return to ESP8266 and then when the housekeeping is done, control comes back to the yield() code with the stack/context preserved. The Arduino team did this as far back as SDK 1.1 which pre-dates the system_soft_wdt_feed() which first appeared in SDK 1.3. I was wondering if THIS function is a formal mechanism for the Arduino team's "yield" like routines.

Statistics: Posted by kolban — Sat Sep 05, 2015 11:31 pm

Re: Better understanding of the system_soft_wdt_feed function

2015-09-05T22:58:19+08:00

Kolban, I don't think you're going to get this working, without a lot of work. Apparently it's designed on standaard unix sockets semantics (socket(), connect(), listen(), accept(), close()) which are all "blocking" by design. You will never get that working on esp8266 and that's not due to the watchdog.

Statistics: Posted by eriksl — Sat Sep 05, 2015 10:58 pm

Re: Better understanding of the system_soft_wdt_feed function

2015-09-05T22:44:56+08:00

kolban wrote:
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.

Statistics: Posted by dkinzer — Sat Sep 05, 2015 10:44 pm

Re: Better understanding of the system_soft_wdt_feed function

2015-09-05T22:25:11+08:00

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.

Statistics: Posted by kolban — Sat Sep 05, 2015 10:25 pm

Re: Better understanding of the system_soft_wdt_feed function

2015-09-05T15:11:35+08:00

kolban wrote:
Code:
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!

Statistics: Posted by eriksl — Sat Sep 05, 2015 3:11 pm

Re: Better understanding of the system_soft_wdt_feed function

2015-09-05T12:09:30+08:00

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

Code:

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

Statistics: Posted by kolban — Sat Sep 05, 2015 12:09 pm

Re: Better understanding of the system_soft_wdt_feed function

2015-09-05T02:26:21+08:00

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.

Statistics: Posted by eriksl — Sat Sep 05, 2015 2:26 am

Re: Better understanding of the system_soft_wdt_feed function

2015-09-04T02:43:09+08:00

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.

Statistics: Posted by dkinzer — Fri Sep 04, 2015 2:43 am

Re: Better understanding of the system_soft_wdt_feed function

2015-09-04T06:59:58+08:00

kolban wrote:
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:

40219a20:   000600
40219a23:   800460
...
40219a78:   fe8dc0
40219a7b:   3f
...
40219a7c :
40219a7c:   ffff51          l32r   a5, 40219a78 
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

Statistics: Posted by dkinzer — Thu Sep 03, 2015 11:18 pm

Re: Better understanding of the system_soft_wdt_feed function

2015-09-03T19:56:00+08:00

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

Statistics: Posted by kolban — Thu Sep 03, 2015 7:56 pm

Re: Better understanding of the system_soft_wdt_feed function

2015-09-03T14:07:48+08:00

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.

Statistics: Posted by dkinzer — Thu Sep 03, 2015 2:07 pm

Better understanding of the system_soft_wdt_feed function

2015-09-03T10:48:34+08:00

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

Statistics: Posted by kolban — Thu Sep 03, 2015 10:48 am