Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

esp32 Wifi no longer connects after version espruino_2v00.42 #1571

Closed
mkralla11 opened this issue Nov 17, 2018 · 55 comments

Comments

Projects
None yet
5 participants
@mkralla11
Copy link

commented Nov 17, 2018

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_working

Wifi Test image of espruino_2v00.59 failure:

wifi_fail

@wilberforce

This comment has been minimized.

Copy link
Member

commented Nov 17, 2018

2v00.42 (c) 2018 G.Williams
WARNING: setsockopt(SO_REUSPORT) failed
>
Connected to port COM3
>ESP32.getState();
={
  sdkVersion: "v3.0.3",
  freeHeap: 39680, BLE: true, Wifi: true, minHeap: 35340 }
> 

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 V.20.42
  • connect to the network
  • wifi.save()
  • flash with latest version
  • wifi reconnects on power up
>var ssid="espruino";
="espruino"
="espruino"
=function () { [native code] }
=undefined
null
Connected to access point,  {
  "ip": "192.168.15.25",
  "netmask": "255.255.255.0",
  "gw": "192.168.15.1",
  "mac": "24:0a:c4:00:2f:90"
 }
>wifi.save();
=undefined
>ESP32.getState()
={
  sdkVersion: "v3.0.3",
  freeHeap: 34668, BLE: true, Wifi: true, minHeap: 32676 }
> 

Flash with new version


E (295) spiram: SPI RAM enabled but initialization failed. Bailing out.
E (469) phy_init: store_cal_data_to_nvs_handle: store calibration data failed(0x1105)
E (725) phy_init: store_cal_data_to_nvs_handle: store calibration data failed(0x1105)

>require("Wifi").getIP();
={
  ip: "192.168.15.25",
  netmask: "255.255.255.0",
  gw: "192.168.15.1",
  mac: "24:0a:c4:00:2f:90"
 }
>ESP32.getState();
={
  sdkVersion: "v3.1",
  freeHeap: 40008, BLE: true, Wifi: true, minHeap: 28584 }
> 

@wilberforce wilberforce added the ESP32 label Nov 19, 2018

@wilberforce

This comment has been minimized.

Copy link
Member

commented Nov 19, 2018

@jumjum123

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

@gfwilliams

This comment has been minimized.

Copy link
Member

commented Nov 19, 2018

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.

@mkralla11

This comment has been minimized.

Copy link
Author

commented Nov 19, 2018

@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:

  • down grade firmware
  • reconnect / store wifi credentials
  • upgrade to latest firmware

...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!

@jumjum123

This comment has been minimized.

Copy link
Contributor

commented Nov 20, 2018

There are always problems with new versions, its a .....
Checked a simple connect to my wifi and failed in 9 of 10 times.
But I never got the errormessage shown above. I did not even get a callback
Added some printf to figure out the problem and see an event to disconnect STA, which should not happen.
Next checked examples/wifi/simple_wifi and that works fine.
Spent some hours to find differences, no success

To your question, only benefit I see for V3.1 is support of PSRAM
Its a simple task to add this to V3.0, minor changes in 2 sources. May be we can do that.

Tested with actual version V3.1.1.
But already first step, compiling a template, failed because of conflicting types
To repeat from the beginning, there are always problems with new versions, its a ....

@jumjum123

This comment has been minimized.

Copy link
Contributor

commented Nov 20, 2018

Found the bug in ESPV3.1.1, its simply taking wrong name.
Compiled and now I get the same error:
E (19858) phy_init: store_cal_data_to_nvs_handle: store calibration data failed(0x1105)
BTW, now size of binary is 1318KB

From my point of view, V3.1 and following are not reliable.

@wilberforce

This comment has been minimized.

Copy link
Member

commented Nov 20, 2018

What do you mean by wrong name?

So you think we should go back to version 3.0.x of the sdk then?

@jumjum123

This comment has been minimized.

Copy link
Contributor

commented Nov 20, 2018

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.
Therefore I would not like to do so.
But right now its looking like being best solution.

How could we add PSRAM support ? I could send sources with changes to you ?

@jumjum123

This comment has been minimized.

Copy link
Contributor

commented Nov 21, 2018

@wilberforce
will you take the part going back to V3.0 ?
Once this is done, I would like to provide some changes for neopixel, LED boards and last not least PSRAM support

@wilberforce

This comment has been minimized.

Copy link
Member

commented Nov 21, 2018

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.

@jumjum123

This comment has been minimized.

Copy link
Contributor

commented Nov 21, 2018

Always same with these guys, new version means new trouble.
Have a good night

@wilberforce

This comment has been minimized.

Copy link
Member

commented Dec 3, 2018

@mkralla11

Are you able to try this?

https://www.espruino.com/binaries/travis/cfebac7a04de43e26f2919b69eb0d8186fc1884f/espruino_esp32.bin

@jumjum123
I can't find where but someone (github/forum?) mentioned memset-ing the struct to Zero first.

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.

#1579

@jumjum123

This comment has been minimized.

Copy link
Contributor

commented Dec 3, 2018

@wilberforce, wow
thanks to your changes, I better understand results of my trial and error sessions ;-)
Looks like memset is the big point.
And another thing I just found: The memcpy call does not copy the null terminator
In our case this means, setting \0 to terminate password and ssid in buffer ist not copied to structure by memcpy

@mkralla11

This comment has been minimized.

Copy link
Author

commented Dec 3, 2018

I will try this build today @wilberforce.

@wilberforce

This comment has been minimized.

Copy link
Member

commented Dec 4, 2018

It was this fix that mentioned the memset issue:

861ee50

@jumjum123

This comment has been minimized.

Copy link
Contributor

commented Dec 4, 2018

@wilberforce
wow, how did you find that. Even with the id, it took me some time to find Maker Asia

@wilberforce

This comment has been minimized.

Copy link
Member

commented Dec 4, 2018

@jumjum123

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.

@wilberforce

This comment has been minimized.

Copy link
Member

commented Dec 6, 2018

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.

https://github.com/espressif/esp-idf/blob/master/examples/wifi/getting_started/station/main/station_example_main.c

@wilberforce

This comment has been minimized.

Copy link
Member

commented Dec 6, 2018

The esp-idf wifi example works and gets an IP. For reference - here is the output:

ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
ets Jun  8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:5832
load:0x40078000,len:9020
load:0x40080000,len:6064
entry 0x40080330
I (29) boot: ESP-IDF v3.1 2nd stage bootloader
I (29) boot: compile time 09:32:53
I (29) boot: Enabling RNG early entropy source...
I (34) boot: SPI Speed      : 40MHz
I (38) boot: SPI Mode       : DIO
I (42) boot: SPI Flash Size : 4MB
I (46) boot: Partition Table:
I (49) boot: ## Label            Usage          Type ST Offset   Length
I (57) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (64) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (72) boot:  2 factory          factory app      00 00 00010000 00100000
I (79) boot: End of partition table
I (83) esp_image: segment 0: paddr=0x00010020 vaddr=0x3f400020 size=0x127bc ( 75708) map
I (119) esp_image: segment 1: paddr=0x000227e4 vaddr=0x3ffb0000 size=0x03560 ( 13664) load
I (124) esp_image: segment 2: paddr=0x00025d4c vaddr=0x3ffb3560 size=0x00000 (     0) load
I (125) esp_image: segment 3: paddr=0x00025d54 vaddr=0x40080000 size=0x00400 (  1024) load
I (135) esp_image: segment 4: paddr=0x0002615c vaddr=0x40080400 size=0x09eb4 ( 40628) load
I (160) esp_image: segment 5: paddr=0x00030018 vaddr=0x400d0018 size=0x61fe8 (401384) map
I (301) esp_image: segment 6: paddr=0x00092008 vaddr=0x4008a2b4 size=0x05fc8 ( 24520) load
I (311) esp_image: segment 7: paddr=0x00097fd8 vaddr=0x400c0000 size=0x00000 (     0) load
I (312) esp_image: segment 8: paddr=0x00097fe0 vaddr=0x50000000 size=0x00000 (     0) load
I (329) boot: Loaded app from partition at offset 0x10000
I (329) boot: Disabling RNG early entropy source...
I (331) cpu_start: Pro cpu up.
I (334) cpu_start: Starting app cpu, entry point is 0x40080fc0
I (0) cpu_start: App cpu up.
I (345) heap_init: Initializing. RAM available for dynamic allocation:
I (351) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM
I (358) heap_init: At 3FFB95E0 len 00026A20 (154 KiB): DRAM
I (364) heap_init: At 3FFE0440 len 00003BC0 (14 KiB): D/IRAM
I (370) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (377) heap_init: At 4009027C len 0000FD84 (63 KiB): IRAM
I (383) cpu_start: Pro cpu start user code
I (65) cpu_start: Starting scheduler on PRO CPU.
I (0) cpu_start: Starting scheduler on APP CPU.
I (109) simple wifi: ESP_WIFI_MODE_STA
I (109) wifi: wifi driver task: 3ffc0ea8, prio:23, stack:3584, core=0
I (109) wifi: wifi firmware version: 54ef8ed
I (109) wifi: config NVS flash: enabled
I (119) wifi: config nano formating: disabled
I (119) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE
I (129) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE
I (149) wifi: Init dynamic tx buffer num: 32
I (149) wifi: Init data frame dynamic rx buffer num: 32
I (149) wifi: Init management frame dynamic rx buffer num: 32
I (159) wifi: Init static rx buffer size: 1600
I (159) wifi: Init static rx buffer num: 10
I (169) wifi: Init dynamic rx buffer num: 32
I (239) phy: phy_version: 3960, 5211945, Jul 18 2018, 10:40:07, 0, 0
I (239) wifi: mode : sta (24:0a:c4:00:2f:90)
I (249) simple wifi: wifi_init_sta finished.
I (249) simple wifi: connect to ap SSID:espruino password:espruino
I (369) wifi: n:1 0, o:1 0, ap:255 255, sta:1 0, prof:1
I (1349) wifi: state: init -> auth (b0)
I (1349) wifi: state: auth -> assoc (0)
I (1359) wifi: state: assoc -> run (10)
I (1389) wifi: connected with espruino, channel 1
I (1389) wifi: pm start, type: 1

I (2109) event: sta ip: 192.168.15.25, mask: 255.255.255.0, gw: 192.168.15.1
I (2109) simple wifi: got ip:192.168.15.25
@wilberforce

This comment has been minimized.

Copy link
Member

commented Dec 7, 2018

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!

@jumjum123

This comment has been minimized.

Copy link
Contributor

commented Dec 7, 2018

@wilberforce
WiFi sources have never been my area. Anyway, right now I'm testing and checking and ....
To it's a wonder, it worked before, could you please give some more info ?
Let me give actual status of my testing etc. Hopefully my collection of trial and error is not too confusing ;-)

  • changed ssid and password by directly writing them to wifi_config_t staConfig instead of using char arrays and memcpy. I've no idea, why we had this additional step
  • skipped back to writing phy data to nvs, additional phy-partition from former testing removed. This was done to get rid of "no space in nvs partition", but I don't get it anymore.
  • checked example simplewifi and it works
  • similar to your test, hardcoding of ssid and password worked with Espruino
  • couldn't get noisy version(log on deep level) running, size of binary was too big
  • added logging events, found nothing helpful
  • moved definition of sta_config out of function. May be, pointer its used somewhere inside a lib (?)
  • testing with versions: travis / V3.1 / V3.1.1, Only V3.1 returns a callback. Have no idea where difference between travis and V3.1 is in source or configuration. Size of my V3.1 is 1306, and travis is 1288.
@wilberforce

This comment has been minimized.

Copy link
Member

commented Dec 7, 2018

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.

@wilberforce

This comment has been minimized.

Copy link
Member

commented Dec 7, 2018

The wifi config and memcpy would have come from the esp8266 code. I'm not sure that it is too helpful!

@jumjum123

This comment has been minimized.

Copy link
Contributor

commented Dec 7, 2018

In my check of order I could'nt find big differences, compared to simplewifi example.
Big change is waiting for start event before calling esp_wifi_connect. During my test, this did not change anything.
BTW, you moved esp_wifi_connect to wifi_get_event. Shouldn't it be in event_handler ?
Yes I would absolutely like to follow your changes. It is always helpful, to see others thoughts

@wilberforce

This comment has been minimized.

Copy link
Member

commented Dec 7, 2018

BTW, you moved esp_wifi_connect to wifi_get_event. Shouldn't it be in event_handler ?

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.

@wilberforce

This comment has been minimized.

Copy link
Member

commented Dec 8, 2018

#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"
 }

@mkralla11

This comment has been minimized.

Copy link
Author

commented Dec 8, 2018

@jumjum123

This comment has been minimized.

Copy link
Contributor

commented Dec 8, 2018

In my testing, its even more weird
Downloaded latest commit from branch ESP-V3.1 and compiled
After erase flash, download binary and reset uploaded this small piece

var ssid = "JUMWare";var password = "xxxxxxxxxxxxxxxxxx";
var wifi = require("Wifi");
function connect(){
  wifi.connect(ssid, {password: password}, function(ap) {
    console.log("connected:", ap); 
  });
}

And startet some testing

>wifi.getStatus()
WARNING: wifiReasonToString: Unknown reasonL 0
={
  station: "Unknown reason",
  mode: "AP",
  powersave: "modem"
 }
>connect()
WARNING: jswrap_wifi_connect: entry
WARNING: Wifi: event_handler -> SYSTEM_EVENT_STA_START
ERROR: Wifi: event_handler STA_START: esp_wifi_connect: 12298
WARNING: jswrap_wifi_connect: esp_wifi_start
=undefined
>wifi.getStatus()
WARNING: wifiReasonToString: Unknown reasonL 0
={
  station: "Unknown reason",
  mode: "APSTA",
  powersave: "modem"
 }
>connect()
WARNING: jswrap_wifi_connect: entry
WARNING: jswrap_wifi_connect: esp_wifi_start
=undefined
>wifi.getStatus()
WARNING: wifiReasonToString: Unknown reasonL 0
={
  station: "Unknown reason",
  mode: "APSTA",
  powersave: "modem"
 }

The error in ESP_WIFI_CONNECT is 0x300A which is WIFI_REASON_DISASSOC_PWRCAP_BAD
No idea what that means.
Next I hard reset the board and uploaded same source again and see:

wifi.getStatus()
={
  station: "connected",
  ssid: "JUMWare",
  bssid: "34:81:c4:c0:d6:21",
  channel: 6, rssi: -33,
  htMode: "HT40+",
  authMode: "wpa2",
  mode: "APSTA",
  powersave: "modem"
 }

So without calling connect again, status is connected (?)
Then tried to disconnect and got this

>wifi.disconnect()
ERROR: retry to connect to the AP
E (663123) event: post event to user fail!
=undefined
WARNING: Wifi: event_handler -> SYSTEM_EVENT_STA_GOT_IP
>wifi.getStatus()
={
  station: "connected",
  ssid: "JUMWare",
  bssid: "34:81:c4:c0:d6:21",
  channel: 6, rssi: -30,
  htMode: "HT40+",
  authMode: "wpa2",
  mode: "APSTA",
  powersave: "modem"
 }

May be, we have to rethink the idea of reconnecting (?)

@wilberforce

This comment has been minimized.

Copy link
Member

commented Dec 10, 2018

@jumjum123

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.

@wilberforce

This comment has been minimized.

Copy link
Member

commented Dec 10, 2018

@jumjum123

This comment has been minimized.

Copy link
Contributor

commented Dec 10, 2018

Hmmm, becomes more curious.
I removed release and now reset() runs into an assert in jsflash.c
Will do some more testing later today.
All was done with latest sources from ESP-V3.1 branch

@wilberforce

This comment has been minimized.

Copy link
Member

commented Dec 10, 2018

I removed release and now reset() runs into an assert in jsflash.c

I had that - I needed to build for RELEASE=1 to avoid the ASSERT.

@gfwilliams This assert is failing:
https://github.com/espruino/Espruino/blob/master/src/jsflash.c#L56

JsfFileName jsfNameFromString(const char *name) {
  assert(strlen(name)<=8);
@jumjum123

This comment has been minimized.

Copy link
Contributor

commented Dec 10, 2018

@gfwilliams just found it.
There is a problem in jsfLoadBootCodeFromFlash (jsflash.c). terminating \0 is missing.
My quick fix was to change definition of filename to
char filename[7] = ".bootX\0";

@gfwilliams

This comment has been minimized.

Copy link
Member

commented Dec 11, 2018

Are you sure about this? C should have added a terminating 0 automatically, since it's a C string - https://stackoverflow.com/questions/47288881/are-c-constant-character-strings-always-null-terminated

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.

@jumjum123

This comment has been minimized.

Copy link
Contributor

commented Dec 11, 2018

Hmm, need to check status of ESP32-V3.1
Looks like we have to merge master, ....

@wilberforce

This comment has been minimized.

Copy link
Member

commented Dec 11, 2018

Looks like we have to merge master, ....

I have updated the ESP32-V3.1 to be up to date with master.

@jumjum123

This comment has been minimized.

Copy link
Contributor

commented Dec 12, 2018

Tested with new ESP-V3.1 and still have problems.
To make testing/debugging easy, I've added some function to translate events and errors to string.
Next added some more jsDebugs to recognize sequence.
No other changes, nothing to change sequence or logic.
Just pushed these changes to ESP32-V3.1 branch.
Result of a simple connect is this:

connect()
WARNING: jswrap_wifi_connect: entry
WARNING: jswrap_wifi_connect: SSID, password, Callback done
WARNING: Wifi: Event(2):SYSTEM_EVENT_STA_START
ERROR: Wifi: event_handler STA_START: esp_wifi_connect: 12298(SSID is invalid)
WARNING: jswrap_wifi_connect: esi_wifi_set_mode done
WARNING: jswrap_wifi_connect: esp_wifi_set_autoconnect done
WARNING: jswrap_wifi_connect: esp_wifi_set_config done
WARNING: jswrap_wifi_connect: esp_wifi_start JUMWare
=undefined

I get an SSID is invalid before setting config and before starting connection.
For me looks like esp_wifi_set_mode causes SYSTEM_EVENT_STA_START event
Could it be a problem, that we started ESP32 in AP mode during startup ?

@wilberforce

This comment has been minimized.

Copy link
Member

commented Dec 12, 2018

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?

@jumjum123

This comment has been minimized.

Copy link
Contributor

commented Dec 12, 2018

I always erase before loading new binary. My hardware is a Fritzbox 7490.
BTW, talking about hardware, I still have my good old ZX80. It remains lying for the grinning heirs ;-)
Lets go back
Just tested with an additional esp_wifi_connect() at the end of jswrap_wifi_connect and now I get this
Looks like success, even in my testing

connect()
WARNING: jswrap_wifi_connect: entry
WARNING: jswrap_wifi_connect: SSID, password, Callback done
WARNING: Wifi: Event(2):SYSTEM_EVENT_STA_START
ERROR: Wifi: event_handler STA_START: esp_wifi_connect: 12298(SSID is invalid)
WARNING: jswrap_wifi_connect: esi_wifi_set_mode done
WARNING: jswrap_wifi_connect: esp_wifi_set_autoconnect done
WARNING: jswrap_wifi_connect: esp_wifi_set_config done
WARNING: jswrap_wifi_connect: esp_wifi_start JUMWare
=undefined
WARNING: Wifi: Event(4):SYSTEM_EVENT_STA_CONNECTED
WARNING: wifiGetEvent: Got event: 4
WARNING: Wifi: Event(7):SYSTEM_EVENT_STA_GOT_IP
WARNING: sendWifiCompletionCB
WARNING: Wifi: About to emit connect!
WARNING: wifiGetEvent: Got event: 7
connected: null

I've a problem with setting autoconnect to true.
After a hard reset I get this, its connecting automatically. There is nothing saved, so ESP-IDF is doing it by itself

WARNING: esp32_wifi_init complete
WARNING: jswrap_wifi_restore: Starting Wifi
WARNING: Wifi: not auto starting!
WARNING: Wifi: Event(2):SYSTEM_EVENT_STA_START
WARNING: Wifi: Event(13):SYSTEM_EVENT_AP_START
WARNING: sendWifiCompletionCB
WARNING: jswrap_esp32_wifi_soft_init()
WARNING: jswrap_esp32_wifi_soft_init()
 ____                 _
|  __|___ ___ ___ _ _|_|___ ___
|  __|_ -| . |  _| | | |   | . |
|____|___|  _|_| |___|_|_|_|___|
         |_| espruino.com
 2v00.120 (c) 2018 G.Williams
Espruino is Open Source. Our work is supported
only by sales of official boards and donations:
http://espruino.com/Donate
WARNING: Wifi: Event(4):SYSTEM_EVENT_STA_CONNECTED
WARNING: wifiGetEvent: Got event: 4
WARNING: Wifi: Event(7):SYSTEM_EVENT_STA_GOT_IP
WARNING: sendWifiCompletionCB
WARNING: Wifi: About to emit connect!
WARNING: wifiGetEvent: Got event: 7
@wilberforce

This comment has been minimized.

Copy link
Member

commented Dec 12, 2018

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.

@jumjum123

This comment has been minimized.

Copy link
Contributor

commented Dec 12, 2018

Hmm, would it be possible to read ssid and password from nvs ?

Anyway, I uploaded my source and added some more changes:

  • get NEOPIXEL running again
  • make shiftout command more robust, switched taskhandling off. Based on this (and mainly by changes from @gfwilliams ) we now have a stable driver for LED matrix 32x64 for ESP32. Some more information will follow next days in Espruino Forum
@wilberforce

This comment has been minimized.

Copy link
Member

commented Dec 13, 2018

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.
Potentially we could have wifi and ble on core 0 and espruino running on core 1 - so that this stuff does not impact? Another day.

The issue we have with the wifi connect comes down to this:

ESP_ERROR_CHECK(esp_wifi_set_storage(WIFI_STORAGE_FLASH)); in void esp32_wifi_init() {

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 Storage module in a special wifi area.

@wilberforce

This comment has been minimized.

Copy link
Member

commented Dec 14, 2018

I've added the first part of this that saves the wifi config as per the esp8266 in Storage in the .wificfg file.

84266ab

>w=require("Wifi");
=function () { [native code] }
>w.save();
WARNING: Wifi.save
WARNING: Wifi.save: write completed
=undefined
>s=require("Storage");
=function () { [native code] }
>s.list();
=[
  ".bootcde",
  ".wificfg"
 ]
>s.re
read                readArrayBuffer
readJSON            replaceWith
removeAllListeners  removeListener
>s.rea
read                readArrayBuffer
readJSON
>s.readJSON('.wificfg');
={
  ssid: "espruino",
  password: "espruino",
  mode: 3, sleepType: 1,
  ssidAP: "ESP_002F91",
  passwordAP: "",
  authmodeAP: 0, hiddenAP: 0, channelAP: 1 }
>w.save('clear');
WARNING: Wifi.save
WARNING: Wifi.save(clear)
=undefined
>s.list();
=[
  ".bootcde"
 ]

Next step is do the restore from flash part

@wilberforce

This comment has been minimized.

Copy link
Member

commented Dec 14, 2018

@jumjum123

wifi config now restored from Storage:

9b3cca7

If there are no previous stored settings - the default ESPxxx access point is started as before.

@wilberforce

This comment has been minimized.

Copy link
Member

commented Dec 16, 2018

@jumjum123

Many changes - I've added a pull request - see the details here!

#1585

@wilberforce

This comment has been minimized.

Copy link
Member

commented Dec 17, 2018

Now the hostname setting is done - need to make part of save and restore

84266ab#diff-c734390fce4f734cb78505c41867aec3R1282

@MaBecker

This comment has been minimized.

Copy link
Contributor

commented Dec 17, 2018

Hey @wilberforce good poin. Will add this for ESP8266 too.

@wilberforce

This comment has been minimized.

Copy link
Member

commented Dec 18, 2018

@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

@wilberforce

This comment has been minimized.

Copy link
Member

commented Dec 28, 2018

Seem to have an issue connecting to a a netgear router:

WARNING: esp32_wifi_init complete
WARNING: jswrap_esp32_wifi_soft_init()
WARNING: jswrap_wifi_connect: entry
WARNING: jswrap_wifi_connect: SSID, password, Callback done
WARNING: jswrap_wifi_connect: esi_wifi_set_mode done
WARNING: jswrap_wifi_connect: esp_wifi_set_autoconnect done
WARNING: jswrap_wifi_connect: esp_wifi_set_config done
WARNING: jswrap_wifi_connect: esp_wifi_start espruino
WARNING: Wifi: Event(2):SYSTEM_EVENT_STA_START
WARNING: Wifi: Event(13):SYSTEM_EVENT_AP_START
WARNING: sendWifiCompletionCB
{ "poll_ms": 120000 }
WARNING: jswrap_esp32_wifi_soft_init()

WARNING: jswrap_wifi_restore
WARNING: WARNING: Wifi: Event(14):SYSTEM_EVENT_AP_STOP
WARNING: Wifi: event_handler -> NOT HANDLED EVENT: 14
jswrap_wifi_restore: AP=ESWARNING: Wifi: Event(13):SYSTEM_EVENT_AP_START
WARNING: sendWifiCompletionCB
P_002F91
WARNING: Wifi.restore: STA=NETGEAR88
WARNING: Wifi.restore: hostname=espressif
WARNING: Wifi:startMDNS - espressif
WARNING: Wifi: Event(5):SYSTEM_EVENT_STA_DISCONNECTED
WARNING: retry to AP connect
E (3736) event: post event to user fail!
WARNING: Wifi: Event(5):SYSTEM_EVENT_STA_DISCONNECTED
WARNING: retry to AP connect
E (6578) event: post event to user fail!
WARNING: Wifi: Event(5):SYSTEM_EVENT_STA_DISCONNECTED
WARNING: retry to AP connect
E (9420) event: post event to user fail!
WARNING: Wifi: Event(5):SYSTEM_EVENT_STA_DISCONNECTED
WARNING: retry to AP connect
E (12261) event: post event to user fail!
WARNING: Wifi: Event(5):SYSTEM_EVENT_STA_DISCONNECTED
WARNING: wifiGetEvent: Got event: 5

@mkralla11

This comment has been minimized.

Copy link
Author

commented Jan 28, 2019

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!

@wilberforce

This comment has been minimized.

Copy link
Member

commented Jan 28, 2019

@mkralla11

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.

@mkralla11

This comment has been minimized.

Copy link
Author

commented Jan 28, 2019

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:

setTimeout(()=>{
  require('Wifi').connect('Name', {password: 'password'}, function(e){
    console.log('connected?', e);
  });
}, 4000);

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?

@wilberforce

This comment has been minimized.

Copy link
Member

commented Jan 28, 2019

@mkralla11

Are you using wifi.save().

If you are - then the connect call back is not called. If you do a wifi.save('clear')' and connect at start up then connect should be called.

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

@wilberforce

This comment has been minimized.

Copy link
Member

commented Jan 29, 2019

Also see

#1599 (comment)

@wilberforce

This comment has been minimized.

Copy link
Member

commented Feb 3, 2019

@mkralla11

e4e0e33

Travis build:

https://www.espruino.com/binaries/travis/269311e22910b7b4026e50245805162f4afab20b/espruino_esp32.bin

>ESP32.getState();
={
  sdkVersion: "v3.1.2-dirty",
  freeHeap: 26896, BLE: true, Wifi: true, minHeap: 21700 }
>

Not sure why the version adds _dirty - possbile as I used the zip version of the idf

@wilberforce wilberforce closed this Feb 3, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.