Photon not running code while connecting to wifi

Firmware
1

I have a snippet that mainly runs without a wifi connection, but at a given moment it connects to wifi, publishes what needs to be published and then turns the wifi back off. The problem is it seems to be stopping the script while it establishes the internet connection, while I would love for a neopixel animation to run while that is happening. It looks like there is a sort of delay, I’m guessing for stability while connecting, somewhere in the hard code, but at the same time, the status led blinks green. otherwise the code runs smoothly, and I don’t use any hard delays myself. I looked into replicating the status led on the neopixels (ref https://github.com/spark/firmware/issues/302) but it doesn’t seem to go through. I’ll post the code here if desirable, but again, I’m fairly certain the issue is not there.

2

Have you had a look at the docs for SYSTEM_MODE() and SYSTEM_THREAD(ENABLED)?

1 Like
3

Yup! Only difference is that with SYSTEM_THREAD(ENABLED) the status led stays cyan instead of turning white on boot up. when connecting the wifi, the script is still blocked it seems. Still can’t replicate the status led either.

4

Sorry for the late response, but when I go with SYSTEM_MODE(SEMI_AUTOMATIC) and SYSTEM_THREAD(ENABLED) I don’t see any blocking during any connection atempt.
Neither does it block on connection drop or reconnect.

1 Like
5

I use SYSTEM_MODE(SEMI_AUTOMATIC) and SYSTEM_THREAD(ENABLED) also, it works great for me. I have the Photon display the SSID on my OLED display and I can see when it’s not connected (doesn’t display any SSID) and then see when it connects (displays the SSID).

1 Like
6

Hi,

I’ve noticed that for WiFi.connect() in MANUAL or SEMI_AUTOMATIC mode, with SYSTEM_THREAD(ENABLED), there is still a period of up to three seconds where the system firmware will block if the module is not able to establish a WiFi connection. Specifically, it happens during the call to wiced_interface_up(WICED_STA_INTERFACE) in wlan_connect_finalize(). Blocking for three seconds is obviously preferable to the full 20-second timeout, but it’s also a pain to have to potentially block for up to three seconds each time we attempt to connect to WiFi.

Since it’s already established that control can be returned to the user thread before the full 20s timeout period, would it also be somehow possible to reduce the duration of the three-second blocking period to accommodate more time-sensitive applications?

Thanks!

7

Okay, so apparently I missed a little something in my script, so the script was waiting for WiFi.ready(), not Particle.connected(), hence the freezing. Sorry and thank you all for the feedback, it now does everything I want it to do!

8

Could you show the code that illustrates that behaviour, since my tests don’t show any impact on the application thread as long the app code does not try to get control over a shared resource while the connection process has exclusive control.

9

Well that’s the thing I kinda missed, there was no code that ran while waiting for Particle.connected, just WiFi.ready, and since the latter takes litterally no time at all, it looked like the script froze! Now that I changed it to Particle.connected, it runs the animation (a simple led sweep) continuously until the publish is complete.

1 Like
10

@batmanish, but @dfukumori has commented about this and I tried to get some feedback of him how he’s tested, or are you working on an inter-continental joint-project together :wink:

11

Hah, well there you go! I’m on mobile, so didn’t see the ‘replied to’ thing until now. Sorry

12

Here’s a simple example that exhibits the behavior:

#include "application.h"

SYSTEM_MODE(SEMI_AUTOMATIC);
SYSTEM_THREAD(ENABLED);

void setup() {
  pinMode(D3, OUTPUT);
}

void loop() {
  digitalWriteFast(D3, !digitalRead(D3)); // Pin toggle to determine whether user code is running.
  if (!WiFi.ready() && !WiFi.connecting()) {
    WiFi.connect(); // Running with bad credentials, expecting no connection.
  } else {
    // Do something.
  }
}

I’m using a logic analyzer to monitor the output of D3. There’s a three-second delay in pin-toggling when the call to WiFi.connect() is made without good network credentials. Interestingly, this is not the case if the attempt to connect to WiFi is initiated by a call to Particle.connect() – the behavior is more similar to what would be expected from SYSTEM_THREAD(ENABLED), i.e. switching between system and user code every ~1ms for a short period of time (~10-20ms). This is also the behavior I’ve observed when the module is in listening mode with SYSTEM_THREAD(ENABLED).

13

@dfukumori, I see.

Try to rearrange your if like this and have another test.

 if (!WiFi.connecting() && !WiFi.ready())
14

@dfukumori, have you tested this? Does it change things for you?
If you care for an explanation why this makes a difference, just ask :wink: