[WIP] Add delay in softAPConfig() after call to enableAP() to assure AP startup works

[devyte]

On latest git today.
I have been intermittently encountering an issue where the AP won't start given certain unknown conditions. In particular, I have a WiFi control sequence where the logic is controlled by configuration parameters. In my case, the sequence is being called from a callback that executes in the SYS context (callback of an Async object).
If the AP is to be enabled, such as when switching from STA to AP mode, then the very first call in that sequence is WiFi.softAPConfig():

  if(!WiFi.softAPConfig(blah))
    Serial.println("softAPConfig failed");
  else
    Serial.println("softAPConfig succeeded");

And that fails.

When the failure happens, it's repeatable. Then, I will change some unrelated code and rebuild, and the problem may go away, or continue to be present and still consistent. This leads me to believe it is some race condition.

Debugging (DebugLevel WiFi) the calls inside softAPConfig() shows logs that indicate that the call to enableAP() at the very start of the method succeeds, but then all subsequent SDK API calls fail. On a whim, I moved my control sequence code to the CONT context by wrapping it in a lambda and scheduling it. This continued to show the failure. Then, I added a delay(10) right after the call to enableAP(), as shown in this PR, and suddenly the issue disappeared and can't be reproduced.

My suspicion is that the mode switch at low level (in the SDK or in hardware) isn't synchronous. Either there is a hw sequence that should be waited upon, or there is a sequence of SDK tasks that get queued that need to be executed for the sequence to complete.

This PR is meant for discussion. Off the top of my head:

• I am not sure about this solution. Adding a delay() disallows calling these functions from the SYS context (can't delay there => crash) as is possible now, e.g.: from a Ticker callback.
• This works, but the delay value picked is just a guess. Of note, yield() doesn't work.
• I'm not sure this is the best place to put the delay(). The enableAP() method is in reality a thin wrapper around mode(). I think the race condition is really in there, so maybe adding a delay() or busy loop waiting for a condition at the end of the mode() method would be better.
• Can anyone come up with an idea better than delay()?

Notes:
-a delayMicroseconds() could check for a hw sequence. If it works, it's a hw sequence. If not, it's likely a sequence of tasks that were queued.
-If a mode switch is a sequence of tasks, other wifi things could be as well. I'm thinking of the case where the status() doesn't always reflect reality.

[Jeroen88]

@devyte I encountered the same problem yesterday and solved it by waiting for WiFi.softAPConfig(blah) to return 'true'. Not elegant, but better than just a delay, because my solution continues as soon as possible.

[devyte]

How? please post a code snippet.

[Jeroen88]

I have no access to my code now, but something like:

while(!WiFi.softAPConfig(blah)) delay(10);

I considered adding a timeout, just to be sure, but did not yet, because softAPConfig changes to 'true' fast enough.

[TD-er]

Well the description of the post is at least very recognizable to me.

I would think the most elegant way would be to react to events just like when you connect to WiFi.