esp32 Wifi no longer connects after version espruino_2v00.42 #1571
Comments
So it is the change to SDK 3.1. I tried a complete board erase and reflashing the new firmware. Same problem - wifi does not connect. Workround:
Flash with new version |
|
Did you try a fresh connect with v3.1 - it looks like we have an issue and might have to revert back to version 3.0 |
|
Hey, I'm not really involved in this, just just wanted to say thanks @mkralla11 for putting the time in to track this down to the actual commit - it makes everyone's lives a million times easier. |
|
@gfwilliams absolutely no worries. I love using the espruino runtime and creating IoT products! You and all of the engineers who have created espruino have my respect. @wilberforce I didn't get a chance to try your work-around but thank you for providing it! Disappointingly, I don't think it would scale well while building my current library, as I frequently erase all storage from my devices. So having to:
...wouldn't end up working for my use-case (correct me if I'm wrong, I'm assuming that I'd run into the same error after erasing Storage). Regardless, thank you again @wilberforce for helping provide a potential work-around! |
|
There are always problems with new versions, its a ..... To your question, only benefit I see for V3.1 is support of PSRAM Tested with actual version V3.1.1. |
|
Found the bug in ESPV3.1.1, its simply taking wrong name. From my point of view, V3.1 and following are not reliable. |
|
What do you mean by wrong name? So you think we should go back to version 3.0.x of the sdk then? |
|
Definition of a function in .h and .c is different. No idea, how this could make it through testing at Espressif If we go back to V3.0, thats the first step for us, to be decoupled from future versions. How could we add PSRAM support ? I could send sources with changes to you ? |
|
@wilberforce |
|
Tried to take it back to v3.0.3 - got it to compile then link errors. Grrr. So currently trying a new fresh build based on 3.0.6. Got a .bin - next step is to flash it and test. Going to bed now - will test tomorrow. |
|
Always same with these guys, new version means new trouble. |
|
Are you able to try this? https://www.espruino.com/binaries/travis/cfebac7a04de43e26f2919b69eb0d8186fc1884f/espruino_esp32.bin @jumjum123 I added that code a few more things 0- looking at the esp-idf example file - and set up the connect the same way - and it trys to re-connect 5 times. nvr-ram is also reset like the example if the version has changed. |
|
@wilberforce, wow |
|
I will try this build today @wilberforce. |
|
It was this fix that mentioned the memset issue: |
|
@wilberforce |
|
It was in my notifications for github - I watch for changes on Espruino so I know what is getting changed. You should be able to just click on the name to link to their github account. |
|
Still not working. I compiled the ESP-idf with verbose level debugging on - still no connection when you start from a blank flash. No messages output after a an attempted wifi connection. Interesting enough a wifi scan does work, so the radio is working. Next report could be to try the wifi example and see if anything appears on output with verbose mode. Then check that the code in espruino follows the same event order as the wifi demo. |
|
The esp-idf wifi example works and gets an IP. For reference - here is the output: |
|
With some hard coding to my AP I have a connection working. Next step is to remove the debug and get this working. Looking at the prior code - it's a wonder it worked before! |
|
@wilberforce
|
|
I think the order of the calls might be important. I have set up the event switch function to be like the sample and have added debug output so I can see when they are called. It seems the main event handler did not handle the connect like the sample - that's what I was referring too. I hope to get it a bit more stable and then post my findings. I can publish what I have now if you want to see the work in progress? This all needs to work from the newly flashed case, and also a wifi.save. |
|
The wifi config and memcpy would have come from the esp8266 code. I'm not sure that it is too helpful! |
|
In my check of order I could'nt find big differences, compared to simplewifi example. |
Yes. That is where I have it now. It also handles the reconnects 5 times which some people have been doing in JavaScript. I will try more to today and post my changes to the 3.1 branch so you can see. |
|
It seems that the connect event does not get emitted - even though it is connecting. |
|
Wow nice find! That’s really weird.
…Sent from my iPhone
On Dec 7, 2018, at 7:47 PM, wilberforce ***@***.***> wrote:
#1582
It seems that the connect event does not get emitted - even though it is connecting.
var wifi = require("Wifi");
wifi.connect("espruino", {password:"espruino"}, function(err,stuff){
// never fires
console.log("connected? err=", err, "info=", wifi.getIP());
console.log(stuff);
});
// yet this show we ARE connected!
setTimeout( function() { console.log(wifi.getStatus()) }, 1000 );
>var wifi = require("Wifi");
=function () { [native code] }
WARNING: jswrap_wifi_connect: entry
WARNING: jswrap_wifi_connect: esp_wifi_start
=undefined
=undefined
>setTimeout( function() { console.log(wifi.getStatus()) }, 1000 );
=1
{
"station": "connected",
"ssid": "espruino",
"bssid": "18:f3:45:62:2e:91",
"channel": 1, "rssi": -34,
"htMode": "HT20",
"authMode": "wpa2",
"mode": "STA",
"powersave": "modem"
}
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
In my testing, its even more weird And startet some testing The error in ESP_WIFI_CONNECT is 0x300A which is WIFI_REASON_DISASSOC_PWRCAP_BAD So without calling connect again, status is connected (?) May be, we have to rethink the idea of reconnecting (?) |
|
The logic for the reconnect has been sorted out - it will no longer reconnect after an actual reconnection. If the release flag is off the wifi events and entry points are shown on output. The main thing discovered is the way the auto connect flag in the esp-idf works - it needs to be on to get a connection. The latest pull request should sort the issues. |
|
Hmmm, becomes more curious. |
I had that - I needed to build for RELEASE=1 to avoid the ASSERT. @gfwilliams This assert is failing: |
|
@gfwilliams just found it. |
|
Are you sure about this? C should have added a terminating This was an issue because I'd got the size of the array wrong, but it was fixed with commit 013cb1b a bit over a month ago. |
|
Hmm, need to check status of ESP32-V3.1 |
I have updated the ESP32-V3.1 to be up to date with master. |
|
Tested with new ESP-V3.1 and still have problems. I get an SSID is invalid before setting config and before starting connection. |
|
It's possible you have invalid nvs data. Use esptool and blank out 0x9000 for 0x3000 bytes and try that or erase the flash. I've not seen that message. Perhaps the auto connect call should be the last in the sequence before the start call? |
|
I always erase before loading new binary. My hardware is a Fritzbox 7490. I've a problem with setting autoconnect to true. |
|
Yes. It auto connects using the last used ssid/pass. We need to track the wifi.save state. If it is off at start up - then it needs to be turn off again after the connection is established with a wifi.connect. If it's is on with a wifi.save - it needs to be left on. |
|
Hmm, would it be possible to read ssid and password from nvs ? Anyway, I uploaded my source and added some more changes:
|
|
Wow - that's great. I checked the neopixel code and that works great! The task stuff to prevent interrupts - I should update the onewire code to to use the same. The issue we have with the wifi connect comes down to this:
As the last settings are auto managed - it remembers the last connection and on restart auto connects. We Could work around this - however perhaps the best way forward is to use the code @MaBecker developed for the ESP8266 that stores the wifi config in the |
|
I've added the first part of this that saves the wifi config as per the esp8266 in Storage in the .wificfg file. Next step is do the restore from flash part |
|
wifi config now restored from Storage: If there are no previous stored settings - the default ESPxxx access point is started as before. |
|
Many changes - I've added a pull request - see the details here! |
|
Now the hostname setting is done - need to make part of save and restore |
|
Hey @wilberforce good poin. Will add this for ESP8266 too. |
|
@MaBecker I think the esp8266 build already does this. I did notice there is return statement at the start of one of the functions - startMdns from memory |
|
Seem to have an issue connecting to a a netgear router: WARNING: esp32_wifi_init complete WARNING: jswrap_wifi_restore |
|
Thanks for working on this @wilberforce and @jumjum123! Any recent updates? Let me know if you need someone to test a new build on the esp32. Thanks again! |
|
Hi - have you tried a recent travis build? I have not made any changes recently. The only thing I can think of is try the latest version of 3.1.x esp-idf. |
|
Thanks @wilberforce, it looks like wifi is working on the latest build (espruino_2v01.13_esp32). What is weird is that the connect callback is sometimes not called. So when I run: Sometimes the callback is called, and sometimes it's not, using the same SSID and password. Is this a known issue or is there a more consistent way of connection notification, like the 'connect' event? |
|
Are you using If you are - then the connect call back is not called. If you do a wifi.save('clear')' and connect at start up then You can check to see if you have an IP address, and if it is 0.0.0.0 do a connect as a work-around |
|
Also see |
|
Travis build: https://www.espruino.com/binaries/travis/269311e22910b7b4026e50245805162f4afab20b/espruino_esp32.bin Not sure why the version adds |
I wanted to be as proactive as possible on this - so after upgrading to the most recent version of
espruino_2v00.90 and noticing that Wifi can no longer connect, I began testing every single released version of espruino for esp32 between the version that I was previously on with working wifi - espruino_2v00.34 - through espruino_2v00.90, performing a manual binary search on the inclusive version list, testing the Wifi module until I found the last version that had a working implementation of Wifi.
The Wifi module stopped connecting and began throwing a weird error between the versions below:
Working Wifi:
version: espruino_2v00.42
hash: 1a1fd36
link: http://www.espruino.com/binaries/travis/1a1fd36b740547ece5dda46220c9489bdbd17ff0/
Broken Wifi (no longer connects):
version: espruino_2v00.59
hash: 1df0220
link: http://www.espruino.com/binaries/travis/1df02202a10d974fcb37428f3e40891c6a654dfa/
Wifi Test image of espruino_2v00.42 working correctly (last working version):
Wifi Test image of espruino_2v00.59 failure:
The text was updated successfully, but these errors were encountered: