Android hotspot requires restarting for ESP32 to reconnect or fails: auth -> init (200) [solved:update to latest master]

[Ritesh]

Code: Select all

jcsba@LENOVO-720S MINGW32 ~/esp/esp-idf
$ git log
commit ebdcbe8c60a3b5a228d9e80335d869cc01c527ab (HEAD -> master, origin/master, origin/HEAD)
Merge: 6c49f1924 299e4ca71
Author: Jiang Jiang Jian <jack@espressif.com>
Date:   Fri Mar 1 10:03:03 2019 +0800

    Merge branch 'doc/crc_apis_usage' into 'master'

    Add CRC APIs usage

    See merge request idf/esp-idf!4351

Hi,

I have checked into ESP32 IDF 4.0 master development branch and checked with one mobile hot-spot after restarting ESP32 into STA mode.

So, Still, I am facing STA Disconnection event till 10 to 20 seconds then it is going to connect after that much duration.

Please find below logs for reference purpose

rst:0x1 (POWERON_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:6540
load:0x40078000,len:11308
ho 0 tail 12 room 4
load:0x40080400,len:6700
entry 0x40080764
I (30) boot: ESP-IDF v4.0-dev-402-ga20d02b 2nd stage bootloader
I (30) boot: compile time 17:09:18
I (30) boot: Enabling RNG early entropy source...
I (36) boot: SPI Speed : 40MHz
I (40) boot: SPI Mode : DIO
I (44) boot: SPI Flash Size : 4MB
I (48) boot: Partition Table:
I (52) boot: ## Label Usage Type ST Offset Length
I (59) boot: 0 nvs WiFi data 01 02 00009000 00006000
I (66) boot: 1 phy_init RF data 01 01 0000f000 00001000
I (74) boot: 2 factory factory app 00 00 00010000 00100000
I (81) boot: End of partition table
I (86) esp_image: segment 0: paddr=0x00010020 vaddr=0x3f400020 size=0x18884 (100484) map
I (130) esp_image: segment 1: paddr=0x000288ac vaddr=0x3ffb0000 size=0x03040 ( 12352) load
I (135) esp_image: segment 2: paddr=0x0002b8f4 vaddr=0x40080000 size=0x00400 ( 1024) load
I (137) esp_image: segment 3: paddr=0x0002bcfc vaddr=0x40080400 size=0x04314 ( 17172) load
I (152) esp_image: segment 4: paddr=0x00030018 vaddr=0x400d0018 size=0x6766c (423532) map
I (302) esp_image: segment 5: paddr=0x0009768c vaddr=0x40084714 size=0x0b588 ( 46472) load
I (331) boot: Loaded app from partition at offset 0x10000
I (332) boot: Disabling RNG early entropy source...
I (332) cpu_start: Pro cpu up.
I (336) cpu_start: Application information:
I (340) cpu_start: Project name: wifi_station
I (346) cpu_start: App version: v4.0-dev-402-ga20d02b-dirty
I (353) cpu_start: Compile time: Apr 20 2019 17:18:18
I (359) cpu_start: ELF file SHA256: 60cd5bdb5ee1867c...
I (365) cpu_start: ESP-IDF: v4.0-dev-402-ga20d02b-dirty
I (371) cpu_start: Starting app cpu, entry point is 0x40081058
I (0) cpu_start: App cpu up.
I (382) heap_init: Initializing. RAM available for dynamic allocation:
I (389) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM
I (395) heap_init: At 3FFB8EC0 len 00027140 (156 KiB): DRAM
I (401) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM
I (407) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (414) heap_init: At 4008FC9C len 00010364 (64 KiB): IRAM
I (420) cpu_start: Pro cpu start user code
I (102) cpu_start: Starting scheduler on PRO CPU.
I (0) cpu_start: Starting scheduler on APP CPU.
I (153) wifi station: ESP_WIFI_MODE_STA
I (173) wifi: wifi driver task: 3ffc08d0, prio:23, stack:3584, core=0
I (173) wifi: wifi firmware version: 7240fb7
I (173) wifi: config NVS flash: enabled
I (173) wifi: config nano formating: disabled
I (173) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE
I (183) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE
I (223) wifi: Init dynamic tx buffer num: 32
I (223) wifi: Init data frame dynamic rx buffer num: 32
I (223) wifi: Init management frame dynamic rx buffer num: 32
I (223) wifi: Init management short buffer num: 32
I (233) wifi: Init static rx buffer size: 1600
I (233) wifi: Init static rx buffer num: 10
I (233) wifi: Init dynamic rx buffer num: 32
I (333) phy: phy_version: 4100, 2a5dd04, Jan 23 2019, 21:00:07, 0, 0
I (343) wifi: mode : sta (24:0a:c4:1d:52:d0)
I (343) wifi station: wifi_init_sta finished.
I (343) wifi station: connect to ap SSID:Redmi password:rice123456
I (463) wifi: new:<6,0>, old:<1,0>, ap:<255,255>, sta:<6,0>, prof:1
I (463) wifi: state: init -> auth (b0)
I (473) wifi: state: auth -> init (1c0)
I (473) wifi: new:<6,0>, old:<6,0>, ap:<255,255>, sta:<6,0>, prof:1
I (473) wifi station: retry to connect to the AP after 10 seconds....
I (10483) wifi station: connect to the AP fail
I (12533) wifi station: retry to connect to the AP after 10 seconds....
I (22533) wifi station: connect to the AP fail
I (22653) wifi: new:<6,0>, old:<6,0>, ap:<255,255>, sta:<6,0>, prof:1
I (22653) wifi: state: init -> auth (b0)
I (22653) wifi: state: auth -> assoc (0)
I (22663) wifi: state: assoc -> run (10)
I (22693) wifi: connected with Redmi, channel 6, bssid = 72:bb:e9:96:49:c7
I (22703) wifi: pm start, type: 1

I (23663) tcpip_adapter: sta ip: 192.168.43.211, mask: 255.255.255.0, gw: 192.168.43.1
I (23663) wifi station: got ip:192.168.43.211

So, is this expected behavior or still there is an issue like it should be connected into first attempt?

Please verify from your end and let me know if need any more details for same.

[Ritesh]

ESP32 SDK Team,

Let me know if you need any more details regarding test-cases done from my end.

We need quick resolution for same or let me know if still known issue for that with that behavior.

[jcsbanks]

I am not using 4.0, but 3.3 intending to adopt the release version.

[Ritesh]

I am not using 4.0, but 3.3 intending to adopt the release version.

So, I am just facing issue like initially it is taking time like 20 to 30 seconds to reconnect Hot-Spot after board restart. I have also checked into mobile in which connected device entry is removed quickly after restarting board but still it is taking time to connect with that.

So, Did you face this type of issue while using 3.3 IDF which I have mentioned into logs as well?

[jcsbanks]

I am on commit c76f00373fa695c017cd0c8cd0f6d622c7dffd5f (HEAD -> release/v3.3, origin/release/v3.3) and it is working with Android 9. I do not know if the reason it is not for you is due to a particular Android device/firmware or ESP-IDF.

[Ritesh]

I am on commit c76f00373fa695c017cd0c8cd0f6d622c7dffd5f (HEAD -> release/v3.3, origin/release/v3.3) and it is working with Android 9. I do not know if the reason it is not for you is due to a particular Android device/firmware or ESP-IDF.

As I have cloned master branch then it should be fixed into that branch as you are using 3.3 stabke branch. So, You are going to doubt on Android device which I am using in my case to test it. I have check into one of our router in which not able to reproduce.

So, How can I judge like what to do in case of Hot-Spot of mobile as it is going to connect with multiple retries which are also not fixed?

Though it is going to connect after that many retries but how to take decision for that?

Let me know if you have any suggestiins for that otherwise ESP32 SDK developers might help into this case.

[jcsbanks]

I also need to test this more in light of your findings. I did try a hotspot from an Android 7.1 watch and it could not connect, but I need to grab the failure reason.

I have no answers though.

[Ritesh]

I also need to test this more in light of your findings. I did try a hotspot from an Android 7.1 watch and it could not connect, but I need to grab the failure reason.

I have no answers though.

Ok. Thanks for understanding it.

Take your time and test it from your end. Once you test from your end then please provide me updates for same.

Meanwhile, ESP32 Developers might also test same at their end to verify it.

[Ritesh]

Code: Select all

jcsba@LENOVO-720S MINGW32 ~/esp/esp-idf
$ git log
commit ebdcbe8c60a3b5a228d9e80335d869cc01c527ab (HEAD -> master, origin/master, origin/HEAD)
Merge: 6c49f1924 299e4ca71
Author: Jiang Jiang Jian <jack@espressif.com>
Date:   Fri Mar 1 10:03:03 2019 +0800

    Merge branch 'doc/crc_apis_usage' into 'master'

    Add CRC APIs usage

    See merge request idf/esp-idf!4351

Hi,

Is it possible to get exact commit in which STA Reconnect Issue has been fixed? So that we will take that patch and will try to apply on 2.1 Stable IDF which we are right now using form our development purpose.

Because, We have already developed one product with that ESP32 IDF 2.1 Stable IDF and it is difficult to upgrade ESP32 IDF 3.3 or latest IDF.

Please let me know exact commit ID and dependency of that patch if I will use it into ESP32 IDF 2.1 Stable Release.

[jcsbanks]

I don't know, I only reported a commit in which it did and did not work. My understanding is that the fixes are in a closed source binary blob but I do not know its location or portability between esp-idf versions.