Strange problem with SDK v1.1

[Harold L.]

I've upgraded to SDK v1.1 from v0.9.4, and met WIFI problem.

If I flash the *new bin* file to a *fresh board*(which means the SPI Flash contains all 0xff ....), it'll failed to connect to the AP!

I've sure the following things:
1. 8266 can receive. If I set a wrong SSID, it'll say STATION_NO_AP_FOUND instead of 'STATION_CONNECT_FAIL'
2. the WIFI Tx signal from 8266 may very weak, if a put the board near the AP, my AP has log like this:
daemon.info hostapd: wlan0: STA 18:fe:34:9d:80:97 IEEE 802.11: authenticated
daemon.notice hostapd: wlan0: STA 18:fe:34:9d:80:97 IEEE 802.11: did not acknowledge authentication response

but if the distance is not that close, like 5m, AP would have no such log.

3. If I flash the old bin(build from SDK 0.9.4) first, it'll connect to AP stably at any distance. Now we'll not call it as a *fresh board* since the old bin has been flashed, now I flash the *new bin* to it, WIFI connection is OK!!!

4. The most strange things come: If I erase the *entire* flash though SPIEraseChip() then flash the *new bin*, it'll become a *fresh board* and failed to connect again!


2015-6-3:
After more tests, I found the 3 and 4 was a side-effect of my logic. The problem is more accurately described as follow: with the new SDK, if my code consumes some time before the WIFI connection was established, (e.g.start a timer running at 1HZ in the user_init, block for 100ms in each timer_cb), you may not connect to any AP with SDK 1.1

The same behavior is OK with the old SDK, and we really need to do things before WIFI connection was established!

2015-6-10:
Please see my posts below.


I hope you can offer some help.
Thanks!

[Harold L.]

BTW, I've tried the following mode:
1. STEP2 with 0
2. boot 1.2 + STEP2 with 1 and STEP5 with 3 or 5
3. boot 1.4 + STEP2 with 1 and STEP5 with 3 or 5

all behave the same.

[ESP_Faye]

Hi，

Could you provide your test code to us to duplicate this problem ?

Here is a demo code of ESP8266 station connecting router http://bbs.espressif.com/viewtopic.php?f=21&t=228
Please have a try and notice that "stationConf.bssid_set = 0; " has to be set.

Thanks for your interest in ESP8266 !

[MacDog]

I've got the same problem and it does not seem to care much about the signal strength. Being close to an AP helps a little, but not much.
I've tried two different AP and they both exhibit the same behavior.
It seems to me that there is a timeout in ESP being to short. This results in ESP trying a reconnect instead of waiting for the AP and acknowledge.

[ESP_Faye]

Hi，

Could you provide your test code and the information about your router to us to duplicate this problem ?

Thanks for your interest in ESP8266 !

[Harold L.]

It was really not easy to reproduce the phenomenon in a simple ".c" file

But I found something more intresting: the 0x1fe000 region (RF parameters) matters a lot!

"ssid_bad.bin" is the dump of 0x1fe000 from a board that can not connects to AP, and "ssid_good.bin" dumps from a board that connects fine.

ssid.gif (138.78 KiB) Viewed 7372 times

something there were different, but was set by the same c code.

I've no idea why the same c code configs WIFI SSID & PASSWD can write different RF parameters to 0x1fe000.

P.S. After I flashing the ssid_good.bin to the board which can not connect to AP, it becomes OK!

[MacDog]

I've been testing some more and found the problem seems to be related to the signal strength after all. When using an AP with a good signal, the ESP-12 works every time. The problem with a weak signal might be related to the signal level out of the ESP-12. What's strange is that when it finally connects, it stays connected and keeps the connection up
I found the ESP-12E to be a lot better than the ESP-12. When using the ESP-12E it connects to the AP that the ESP-12 fails on.
I'm converting to using ESP-12E

[Harold L.]

It was the output when the problem happens (using SDK 1.1.2)

connecting...
mode : sta(18:fe:34:9d:80:96)
add if0
f 0, .....scandone
.reconnect
f 0, ....scandone
.reconnect
f -240, ....scandone
.reconnect
f 0, ....scandone
.reconnect
f -240, ....scandone
.reconnect
f 0, ....scandone
.reconnect
f -240, ....scandone
.reconnect
f 0, ....scandone

[iothing]

Hey there I have exactly the same problem also with SDK 1.1.2 (all patches) and it only appears on some of my esp-01 boards:

First I use esptool to write_flash 0x00000 blank512k.bin
This sets all bits in the flash to ones

C code section:

Code: Select all

wifi_station_disconnect();
wifi_set_phy_mode(2); //11g Mode
wifi_set_opmode(1); //STA mode       
char ssid[32] = "lambda";
char password[64] = "1234567890";
struct station_config stationConf;
stationConf.bssid_set = 0;
os_memcpy(&stationConf.ssid, ssid, 32);
os_memcpy(&stationConf.password, password, 64);
wifi_station_set_config(&stationConf);
wifi_station_connect();
wifi_station_dhcpc_start();


Uart log:

Code: Select all

   291> mode : sta(18:fe:34:a6:55:5a)
   295> add if0
   296> f 0, scandone
  3413> reconnect
  3413> f 0, scandone
  6528> reconnect
  6529> f -240, scandone
  9645> reconnect
  9645> f 0, scandone
 12761> reconnect
 12762> f -240, scandone
 15878> reconnect
 15878> f 0, scandone
 18994> reconnect
 18994> f -240, scandone
 22111> reconnect
 22111> f 0, scandone
 25227> reconnect
 25227> f -240, scandone
 28343> reconnect
 28343> f 0, scandone
 31459> reconnect
 31459> f -240, scandone
 34576> reconnect
 34576> f 0, scandone
 37692> reconnect
 37692> f -240, scandone
 40809> reconnect
 40809> f 0, scandone
 43925> reconnect
 43925> f -240, scandone
 47041> reconnect


The same problem happens if I set the esp8266 to be in AP mode, no client can connect. If I place the client (smarphone literally on top of the esp8266 antenna it can sometimes connect.

Once the connection succeeds I can increase the distance by 20 meters and still the connection is stable. So maybe it really has to do with the initial TX PWR settings stored in flash?!

[blubb]

Even with SDK 1.2.0 I have a similar problem, but only in 11N mode! In 11G mode, everything is ok.

In 11N mode I get this scandone/reconnect loop and as reason for the disconnect "auth_leave" is reported.

My router is a "TP-Link TL-WR1043ND" with DD-WRT firmware.