Not saving wifi credentials

[bbkiwi]

Hi @con-f-use and @cnlohr

I've been trying the basic example made by make project (Im in dev) with make clean erase initdefault burn burnweb the ESP8266 (nodemcu v1) comes up with an AP and in the gui I connect to my home wifi no problem. However when I reset it usually tries to connect to the AP again and I have to use the gui again. If examine top of flash 0x3FE000 with echo -ne "fr4186112\t128" | netcat -u -w 1 192.168.1.3 7878 | hexdump -C I find that the wifi credentials are not there. Occasionally it does restart at home station and I find my credentials are there and after each restart it goes to the station.

In commonservices.c I see your comment wifi_station_set_config(&stationConf); //I don't know why, doing this twice seems to make it store more reliably. Is this a manifestation of the unreliability?

I thought I had a way to get around the issue by having my wifi off when I tried to switch to my home station. It kept trying and failing, then I turned the wifi on and it seemed to connect and remember. However even with this it fails often.

Is there any testing I can do for you? Cheers, Bill

[king2]

Yes, to its old value, not to hardcoded value.

[con-f-use]

Did the fix for issue #61 in 96418251a do anything for this?

[king2]

No. I have created my own fix and made a pull request for previous problem (#61). It had created #62. Sorry :(

I made changed for this issue and uploaded them to github (https://github.com/king2/esp82xx), but i do not know how to make separate pull request for my second commit. Maybe my previous pull request has to be accepted to allow me to post next, I do not know..

[king2]

Pull request made for dev branch for both cases.

[con-f-use]

Thank you. I merged the dev one and closed the other. The changes will be merged from dev to master once everything is verified and been so for a while.

Just for reference #63 should fix this issue as of commit adb21e5.

[bbkiwi]

@cnlohr @con-f-use @king2 May have closed a bit too soon.

1. Why is FindMPFS(); needed at all, as the mpfs address is given as PAGE_OFFSET in user.cfg Also if a chip (not erased) that previously had mpfs at high memory has the mpfs put in low memory, FindMPFS will give the wrong address. I still don't understand why flashchip->chip_size must be set to 16M say if the larger flash was only 8M say?

2. maybe this is another issue.

I want to use esp82xx in colorchord/embedded8266 and the current commit cannot be used as it is too big. These fixes need be applied at earlier commits (113e is used by cc now.)

However now that I have been testing with the current commits, the esp8266 seems to be in a state that earlier commits no longer work :-(

I have run using the latest commits on dev now, via make clean erase initdefault burn burnweb and all good.

I then git checkout 113e and try again. (3 attempts: just with make clean burn burnweb, but also erasing first and also erasing first and esptool.py write_flash 0x3FC000 esp_init_data_default.bin taken from sdk/bin i.e. esp_iot_sdk_v1.5.2/bin). In all cases it sets up AP, but can't connect to 192.168.4.1 via web. Back door works ok. )

cc using esp82xx (113e) and I can't get charles master for it to work anymore at all. Keeps rebooting.

How can I get the esp8266 back in a state to use the earlier commits of esp82xx that use sdk 1.5.2 to work.

[cnlohr]

I was about to write a post disagreeing with you on FindMPFS() but I guess it really is no longer needed. I did need it back in the day where the two systems were decoupled. I.e. the code /couldn't/ know what sector it would be in. This is no longer the case. Because the configuration value /is/ known compile-time. PR it! (And don't forget to PR the sector change)

Re: the rest of your problem...

(1) New esp82xx [does or does not] work with sdk 1.5.2? (2) Your board crashes interminably after installing a newer esp82xx on it? (3) Does anyone know if 0x3D0000 is a special location? It's where CC stores its settings.

[bbkiwi]

Hi @cnlohr and team,

Will do more testing later today. (1) Haven't tried new esp82xx with sdk 1.5.2 yet but tried old esp82xx (113e which cc uses and 0946 which used to work with cc) with 1.5.2 and neither works anymore - cant connect to 192.168.4.1 via web, can connect via backdoor, sometime get reset loop with message 'don't use rtc mem' Also the current cc no longer works properly with similar behavior. (2) NO newer works fine after I use make erase initdefault (3) Don't know.

Somehow once the new esp82xx has been used on the board, I can't get it back in a state where the older versions work anymore.

[con-f-use]

Erm, are you saying the historic commit, that remains unchanged doesn't work with the historic SDK that also remains unchanged? That would be very interesting. If only I had time...

[king2]

@bbkiwi,

1. how much flash do you have in your test board?
2. where is your mpfs located?
3. how big both segments of your firmware and where they are located in flash? Can you show output of make burnweb and make flash?

[bbkiwi]

@con-f-use You have understood me correctly. That is exactly what is happening. It may be interesting but I find it extremely frustrating :-o I am retired and have plenty of time but huge gaps in my knowledge. I'm happy to help with this, but may need a bit of direction as how to proceed.

@king2 I have two nodemcu v1.0 boards which have 4Mbyte flash. I have tested putting mpfs both high and low. I've attached details of my tests which show sizes and locations. I'm only using one of them because the second has a working version of cc and is installed in my banjo. I don't want to screw it up until after some upcoming performances.

SUMMARY: esp82xx/dev with included toolchain - ALL GOOD esp82xx/dev using sdk 1.5.2 - ALL GOOD - @cnlohr asked me to try this. After this test, I was somewhat optimistic that my mods to cc would work with esp82xx/dev and sdk 1.5.2. But NO :-( colorchord/embedded8266 master using sdk 1.5.2 tests all fail

• with mpfs at 0x10000 FAIL
• with mpfs at 0x100000 FAIL
• with flashchip->chip-size lines commented out in commonservices.c and mpfs.c (bug was present then)
• my fork/dev with same esp82xx (113)

The failures are similar in each case. Makes AP, but web gui will not connect or is very flaky (1Hz and dissconnects). Can switch to staion via backdoor, but get into funny rebooting loop. - with various output about rooms etc (which I don't understand) and including message don't use rtc mem data (I've looked up rtc memory and it persists upon resets, so maybe the new esp82xx has changed something there ????)

test esp82xx.txt test cc.txt

[king2]

@bbkiwi, sorry, my english knowledge not so good to understand exactly what is going on from this message. Can you find me on skype (oleg_king2), so I can to ask more questions and try to make some tests and try to resolve this problem?

I see that size of menuinterface.js mismatch, are you using newer version from esp82xx?

[bbkiwi]

Hi Oleg,

Thanks that would help. I'm in NZ. I found you on skype and NZ is 9 hours ahead of you. What time suits you? I will look for you now, but if we don't connect, usually up to 10pm here, but not for the next few days

I was mistaken about my test for esp82xx/dev using sdk 1.5.2 . Some funny behavior if I scan for wifi it forces a reboot (but not a looping reboots).

[king2]

Just got -dev, saved it to esp82xx dir of my firmware (ws2812 based, but works with ws2801 too) and tested it on 4M chip (ESP-02 with 25Q32 chip resoldered) - everything work ok, wifi credentials was stored to flash, MPFS and firmware upgrade over the air works as expected.

@bbkiwi , sorry, I was able to connect to you too late today. A accepted auth, feel free to send me a message any time, and we will try to debug your app via skype/shared screen (but sorry in advance for my poor english!). I live in crazy world, so my worktime is crazy also, I can work at night and sleep at day, or inside out, from day to day :)

[bbkiwi]

A big thank you to Oleg for spending many hours today on skype with me trying to track down the bug. At one point by making various changes in colorchord/embedd8266 code we succeeded in getting it to fit using sdk2.0.0 but still buggy. Probably works ok as AP, but difficulty is when (attempt) to connect to station. With the same code and using sdk1.5.2 it started to work fine - we flashed and got a cc working with both wifi and AP. BUT then we gradually rolled back the stages till it broke. BUT then going back to the changes that seem to fix it, it was still broken &*$%.

I have pushed these experiments to https://github.com/bbkiwi/colorchord/commits/bugfind Oleg has kindly offered to look a bit more when he get the time.

[cnlohr]

So, I regret I didn't tell you guys earlier, I've been banging away at ColorChord. I fixed a ton of stuff in the new SDK! I can't find a place where it's still busted. It also seems to work a lot better than it used to, now. I didn't expect you'd be working on an independent tree :(

https://github.com/cnlohr/colorchord/commit/454ca08025123322560e48dd2554185d0c42e0f5

There were a number of changes I had to make to free up more IRAM, but with all the changes enabled, it seems to fit on the new SDK no problem.

[cnlohr]

@bbkiwi It also looks like you've got some good changes in there, too. Though I think your sar changes are ill-fated.

You may want to try merging with what I have and see how it goes.

The biggest crashing bug I found was that when the ESP does some specific stage of connecting, it freezes the processor. If the high performance ADC is enabled then, things totally train-wreck. My solution was to not enable the ADC until after a connection is successful.

[bbkiwi]

This version used to work and still does on the one chip in my banjo. But can't get it to work on my other chip. https://github.com/bbkiwi/colorchord/tree/dev/embedded8266

@cnlohr Will look at your new stuff (but not today).

For your info :-) https://youtu.be/-Rruu9rfudg

[bbkiwi]

Oleg was puzzled about sar. Very little doc available. You might look at my dev branch where I introduced some new parameters to cc for other effects. Maybe there is room for them now.

[cnlohr]

ooohhh nooooo :-p I totally re-did the way the parameters work. By putting them in a struct rather than letting them noodle around everywhere I saved about 100 bytes of IRAM!

[cnlohr]

P.S. To everyone: Let's see if Discord makes sense for this. https://discord.gg/ZnU9r

[cnlohr]

Moving discussion over here: https://github.com/cnlohr/colorchord/issues/44

Can we now declare this closed?

Maybe we should push dev to master?

[bbkiwi]

Not sure what Discord is, but I click and it says invalid invite (not available in NZ?)

RE closing. esp2xx/dev seems to be good now using sdk 2.0.0 and if cc can or will be able to soon use it, probably ok to close issue and push to master.

Big festival of lights here in Lyttelton, NZ tomorrow. Debut of cc banjo!

[con-f-use]

Regarding invalid invite, probably @cnlohr didn't set the "link to never expire".

[cnlohr]

herp derp https://discord.gg/W5J2aZD

[cnlohr]

@bbkiwi YOU BETTER GET VIDEO AND GET A BANJO TO HACKADAY! There's only two banjo stories on hackaday with banjos. https://hackaday.com/tag/banjo/

[king2]

@cnlohr, I can add only one thing: we have added some debugging code that executed after reboot and allows to know where it was crashed. SDK when crashing writes info about crash into RTC mem (that's because we are getting such messages about don't use rtc mem!)

We have checked 3 times, every time crash was associated with executing read_sar_dout function, with reason 'invalid command', and possible cause as 'invalid binaries' or 'wild pointers'.

[cnlohr]

@king2 see my comment in https://github.com/cnlohr/colorchord/issues/44