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

wifi: no connectivity as STA and softAP #4

Closed
yshestakov opened this issue Aug 10, 2021 · 39 comments
Closed

wifi: no connectivity as STA and softAP #4

yshestakov opened this issue Aug 10, 2021 · 39 comments

Comments

@yshestakov
Copy link

Hi,

I'm trying to compile and run examples/wifi/getting_started/ code having CONFIG_ESP32_PHY_MAX_WIFI_TX_POWER=14.
It seems the module is not able to connect to wifi nor become visible as softAP.
Tested on v4.4-dev branch and current "master" (83956ebbae5b3)

@gigamegawatts
Copy link

I have the same problem.

I tested with ESP-IDF v4.3 (Jun 15 release), and with Arduino. I've set the Tx power to 12 and disabled brownout to prevent the "reset glitch" problem.

There aren't any runtime errors, but the "station" example fails to connect to the SSID (I've tried 3 different routers), and the "softAP" example's access point isn't visible.

The "scan" example works, so the WiFi hardware is functioning.

I've tested with 2 different T-OI-Plus modules, both silicon revision 3.

Is everybody having problems with these 2 examples? If anyone has got them to work, or has been able to connect to an access point using a different approach, I'd appreciate if you could reply and say so. If you have any suggestions on code changes, that would be very helpful.

Thanks,

Dan.

@mgsb
Copy link

mgsb commented Aug 16, 2021

I am seeing the same issue. I also tried latest espressif Arduino support (2.0.rc1) and the client example fails to connect as well. scan works for me, too.

@gigamegawatts
Copy link

I was able to get the "station" and "softAP" ESP-IDF examples to work by using the "LilyGo-T-OI-plus_2021-7-17.bin" firmware in this GitHub.

I assume that this replacement bootloader makes some tweaks to the WiFi behaviour. Unfortunately, without the source code it's impossible to know for sure.

I haven't done anything ambitious yet with the WiFi code, or retested with Arduino, so I don't know how much is fixed by the replacement bootloader. It's a step in the right direction, at least.

Note that you have to be careful not to overwrite the bootloader when you flash your code. I run esptool.py from the command line without the "0x0 build\bootloader\bootloader.bin" part.

@yshestakov
Copy link
Author

The LilyGo-T-OI-plus_2021-7-17.bin file has been built using ESP-IDF version v4.4-dev-960-gcf457d412:

Author: Angus Gratton <angus@espressif.com>
Date:   Fri Apr 23 10:15:50 2021 +1000

    esp32c3 espefuse: Fix efuse programming timing on ESP32-C3 ECO3

    Without this timing change, efuse programming occasionally appears to fail
    (although the efuse is programmed correctly).

I tried to check out gcf457d412 tag, have rebuilt "examples/wifi/stations". There is no issue with TX_POWER / TX_WIFI_POWER (set to 20 in sdkconfig). However, the station doesn't work: not able to connect to my AP.

Well, the "scan" example works fine in the "master" branch as well.
By the way, I saw the "station" connected to my AP once, then it rebooted immediately and failed to connected after reboot.
I can't reproduce it again. Probably, it was the case when "scan" was replaced by "station" application, it worked for a moment and stopped to work after that.
So, there is something wrong with wifi authentication or wifi connectivity settings.

p.s. the latest one (master branch) I tested has v4.4-dev-2594-ga20df tag assigned.

@gigamegawatts
Copy link

@yshestakov I get a different result from you: AP connect works (and has been stable so far) with TX_POWER set to 12. If I change the TX_POWER to 20, it can no longer connect to the AP -- it doesn't reset or hang, it just gives the usual "connect to the AP fail" error message. I'm using the ESP-IDF v4.3 release, not 4.4-dev.

I'm quite sure that the fix in my case was in that LilyGo-T-OI-plus_2021-7-17.bin bootloader. I tried going back to the default bootloader from my ESP-IDF build, and I can no longer connect to the AP.

However, that new bootloader doesn't fix everything. I tried connecting to an eero router, and that failed. In fact, the eero AP doesn't even show up in the scan results. So, it works with one AP (an old Wavlink), but not with another.

@yshestakov
Copy link
Author

@gigamegawatts thank you for the information regarding v4.3 release you're using.
In fact, I have 4 boards bought (2 with battery holder and 2 w/o it)
One of boards is not visible in the "softAP" application (myssid). However, the second one is visible in the "Wifi Analyzer" (Android app).
So that I have unpacked 3rd board, flashed "station" app and got it connected to the myssid just of a couple of seconds:

I (623) wifi station: wifi_init_sta finished.
I (623) wifi:new:<1,1>, old:<1,0>, ap:<255,255>, sta:<1,1>, prof:1
I (633) wifi:state: init -> auth (b0)
I (643) wifi:state: auth -> assoc (0)
I (663) wifi:state: assoc -> run (10)
I (10663) wifi:state: �ESP-ROM:esp32c3-api1-20210207
Build:Feb  7 2021
rst:0x13 (GLITCH_RTC_RST),boot:0xd (SPI_FAST_FLASH_BOOT)
SPIWP:0xee
mode:DIO, clock div:2

WIFI_TX_POWER is set to 12 in all cases.
ESP-IDF: v4.4-dev-2594-ga20df743f1-dirty

@yshestakov
Copy link
Author

Having added call to esp_wifi_set_country() with MANUAL policy and max_power=12, I'm able to see a successful Wifi connection established by the station. But it lasts only for a couple seconds again:

I (493) phy_init: phy_version 500,985899c,Apr 19 2021,16:05:08
I (613) wifi:set rx active PTI: 0, rx ack PTI: 0, and default PTI: 0
I (613) wifi:mode : sta (7c:df:a1:b6:58:9c)
I (613) wifi:enable tsf
I (623) wifi:new:<1,1>, old:<1,0>, ap:<255,255>, sta:<1,1>, prof:1
I (623) wifi:state: init -> auth (b0)
I (623) wifi:state: auth -> assoc (0)
I (1633) wifi:state: assoc -> init (400)
I (1633) wifi:new:<1,0>, old:<1,1>, ap:<255,255>, sta:<1,1>, prof:1
I (3323) wifi:new:<1,1>, old:<1,0>, ap:<255,255>, sta:<1,1>, prof:1
I (3323) wifi:state: init -> auth (b0)
I (3333) wifi:state: auth -> assoc (0)
I (3333) wifi:state: assoc -> run (10)
I (13333) wifi:state: run -> init (cc00)
I (13333) wifi:new:<1,0>, old:<1,1>, ap:<255,255>, sta:<1,1>, prof:1
I (15033) wifi:new:<1,1>, old:<1,0>, ap:<255,255>, sta:<1,1>, prof:1
I (15033) wifi:state: init -> auth (b0)
I (15033) wifi:state: auth -> assoc (0)
ESP-ROM:esp32c3-api1-20210207
Build:Feb  7 2021
rst:0x13 (GLITCH_RTC_RST),boot:0xd (SPI_FAST_FLASH_BOOT)

@yshestakov
Copy link
Author

Update.
I have checked out esp-idf and its submodules including components/esp_wifi/lib to the commit dated on April 7:

Author: Zhang Jun Hao <zhangjunhao@espressif.com>
Date:   Wed Apr 7 15:04:51 2021 +0800

    esp_wifi: move unused wifi log to noload section to save binary size

As a result, I got wifi station app connected to my AP (partially): I didn't get IP address assigned.

I (489) phy_init: phy_version 500,985899c,Apr 19 2021,16:05:08
I (609) wifi:set rx active PTI: 0, rx ack PTI: 0, and default PTI: 0
I (609) wifi:mode : sta (7c:df:a1:b6:58:9c)
I (609) wifi:enable tsf
I (619) wifi station: wifi_init_sta finished.
I (619) wifi:new:<7,2>, old:<1,0>, ap:<255,255>, sta:<7,2>, prof:1
I (629) wifi:state: init -> auth (b0)
I (629) wifi:state: auth -> assoc (0)
I (639) wifi:state: assoc -> run (10)
I (649) wifi:connected with XXXXX, aid = 2, channel 7, 40D, bssid = 48:8f:5a:ff:ff:ff
I (649) wifi:security: WPA2-PSK, phy: bgn, rssi: -67
I (649) wifi:pm start, type: 1

I (659) wifi:set rx beacon pti, rx_bcn_pti: 0, bcn_timeout: 0, mt_pti: 25000, mt_time: 10000
I (679) wifi:BcnInt:102400, DTIM:1
W (1299) wifi:<ba-add>idx:0 (ifx:0, 48:8f:5a:ff:ff:ff), tid:0, ssn:3, winSize:64
ESP-ROM:esp32c3-api1-20210207
Build:Feb  7 2021
rst:0x13 (GLITCH_RTC_RST),boot:0xd (SPI_FAST_FLASH_BOOT)

@yshestakov
Copy link
Author

Good news: I made the fix for esp32-c3 revision 3:
espressif/esp-idf#7441

@gigamegawatts
Copy link

That's great!

Are you able to get a stable connection to your AP with that change to the bootloader?

@mgsb
Copy link

mgsb commented Aug 18, 2021

Thanks for the patch. This fixed the reset problem for me with the TX power issue. Leaving the power at 20, I still cannot connect to either of 2 different APs.

@gigamegawatts
Copy link

@mgsb It's very fussy about which type of AP it will connect to. Of the 3 I've tried (an Amazon eero, a Wavlink N300, and an Asus RT_N56U), mine can only connect to the Wavlink. It won't even connect to a 2nd OI-Plus running the softAP sample.

I don't know enough about WiFi to see what's special about the Wavlink. It's running the OEM firmware, and uses WPA2, same as the others. It works with the "station" example in ESP-IDF v4.3 -- I didn't have to make any changes to the code.

@yshestakov
Copy link
Author

@gigamegawatts Well, at TX_POWER <= 16 the board establishes a connection to the Mikrotik AP in a couple of seconds (5 to 15 depending on tx_power value).
On another hand, I'm observing 5-15-40% of packet loss on ICMP pings with default 64 bytes packet size. So, the link by itself is not reliable for TCP connection IMO.

@gigamegawatts
Copy link

I discovered another router that my OI-PLUS can reliably connect to, and you probably all own one.

I took an ESP32 (not C3, the original one) and installed this router software on it: https://github.com/martin-ger/esp32_nat_router. I just used the prebuilt .bin files from that repository.

After configuring things, my OI-PLUS connects to it and can access both my local network and the Internet. I'm only using MQTT, so the speed is good. It probably helps that the 2 boards are sitting inches apart on my desk.

I'm still using the latest release of ESP-IDF 4.3. I added @yshestakov's patch, and have kept the Tx power at 12 (maybe not required anymore, but 12 works).

So, the OI-PLUS's WiFi isn't completely broken, just very fussy about the router. I don't know WiFi stuff well enough to figure out what code changes would allow to work with other routers.

@yshestakov
Copy link
Author

@gigamegawatts you may try to set wifi_country_t configuration after esp_wifi_init(&cfg) call.
By default it uses China settings.

    wifi_country_t wifi_country = {
        .cc = "US",
        .schan = 1,
        .nchan = 14,
        .max_tx_power = 14,
        .policy = WIFI_COUNTRY_POLICY_MANUAL,
    };
    ESP_ERROR_CHECK(esp_wifi_set_country(&wifi_country));

@gigamegawatts
Copy link

@yshestakov Yes, I did try using esp_wifi_set_country. The only effect I noticed was that it changes which channels are scanned (as expected). It still doesn't connect to my eero and Asus routers, but connects to the Wavlink and ESP32 routers.

Unfortunately, the eero and Asus routers don't have a log for troubleshooting this problem. I think the routers are rejecting the connection for some reason, but I don't have any way of finding out why.

On the ESP32-C3's side, the error message is "auth timeout". Based on Google results, this doesn't mean anything specific -- the root cause is unknown. I actually can't find the ESP-IDF code that logs this error, or the code that sets the timeout to 1 second. I don't know if increasing the timeout would do anything.

Here's the relevant part of the ESP32-C3's debug output:

D (2388) wifi:auth mode is not none
D (2388) wifi:connect_bss: auth=1, reconnect=0
I (2398) wifi:state: init -> auth (b0)
D (2398) wifi:start 1s AUTH timer
D (2398) wifi:clear scan ap list
D (3398) wifi:auth timeout
I (3398) wifi:state: auth -> init (200)
D (3398) wifi:connect status 1 -> 4
D (3398) wifi:stop beacon/connect timer
D (3398) wifi:reason: auth expire(2)

@tomash
Copy link

tomash commented Aug 24, 2021

Facing the same issue here, Arduino 1.8.15, esp boards updated to 2.0.0-rc2. Wifi-scan example works but can't connect to any router, tried three different ones (2x Asus RT series and phone hotspot). REG_SET_FIELD(RTC_CNTL_FIB_SEL_REG, RTC_CNTL_FIB_SEL, RTC_CNTL_FIB_SUPER_WDT_RST | RTC_CNTL_FIB_BOR_RST); added to prevent random resets. WiFi.setTxPower() doesn't help even if I got as low as 2 dBm.

Waiting for my regular esp32-c3 dev boards to see if the problem happens there as well or is it unique to this Lilygo board (which would be comforting that it might be something with bootloader or maybe a faulty line of chips).

@gigamegawatts
Copy link

@tomash I was wondering too if other C3 boards like Espressif's DevKit have WiFi problems. I haven't read about any.

The DevKits use shielded modules, and apparently don't use external flash (there are variants of the ESP-C3 that have on-chip flash). I wonder if one of those differences causes the WiFi problems. Just a wild guess, but maybe the external flash causes some critical code to run too slowly, resulting in a connection timeout?

The fact that LilyGo has stopped selling the IO-PLUS makes me suspect it is a problem specific to the board.

Let us know how it goes with the other board.

@tomash
Copy link

tomash commented Aug 25, 2021

@gigamegawatts after I test with devkits, I'll sacrifice one of my Lilygo boards and desolder the flash chip to see if it helps. It's the BergMicro 25Q32 near the grove connector and 3V3 pin, right?

@gigamegawatts
Copy link

@tomash Yes, the 25Q32 chip is the flash (it's a WinBond chip on my board), but I don't think the LilyGo board will be usable without it. As far as I can tell, the ESP32C3 chip it uses doesn't have the 4M of on-chip flash.

@tomash
Copy link

tomash commented Aug 27, 2021

@gigamegawatts all right, got my devkits, one with ESP32-C3-12F and the second with ESP32-C3-13 (both seem to have 4MB flash in-module), time to test.

@tomash
Copy link

tomash commented Aug 27, 2021

Yep, the DevKits connect to Wifi without any issues within two seconds, even the 2MB-flash ESP32-C3-13. So the IO-PLUS is borked.

(Also the DevKits apparently stop executing on opening Arduino Serial Monitor, it might be related to DTR, so I switched to blinking onboard LED at different intervals to show the state).

Other than external flash, could there be other causes, like bad antenna connection on the IO-PLUS? I can try resoldering the 0R resistor to connect with uFL socket instead of this weird white antenna, if that makes sense?

@gigamegawatts
Copy link

@tomash Thanks for letting us know. That's good news, at least for Espressif. It means that the problem isn't with the C3 or the Espressif WiFi stack.

Do your DevKits have the "revision 3" C3? (The GetChipID Arduino sketch displays the revision.) Apparently this revision has some differences that affect WiFi. I wondered if people aren't having WiFi problems with the Espressif DevKits because they use an earlier revision.

Do you mind saying where you bought your boards from? I'd like to have a reliable board to test with.

As for the antenna on the IO-PLUS, that's worth a try, since I don't have a better idea. Although the ceramic antenna works with one of my routers, I might try changing it myself out of curiosity.

@gigamegawatts
Copy link

@tomash I just tried changing to a uFL antenna (and moved the R0 resistor over to its connection pad). For me, it made no difference - same AP connection results. RSSI was actually a little worse with this antenna, but it's a cheapo model that cost a couple of dollars on Aliexpress.

If you have a better antenna and your signal strength is poor with the ceramic antenna, it might be worth trying anyway. At least, I can confirm that the uFL antenna works.

@Jason2866
Copy link

Jason2866 commented Sep 11, 2021

The question, is the board just bad designed, or is the esp32-c3 revision 3 wifi part bad at all?

I have no issues with C3 modules AI-Thinker ESP-C3-01M and other modules from AI-Thinker nor the orig. DevKit from Espressif. The do not need the glitch fix at all.

My Arduino ESP32 framework with the glitch fix https://github.com/Jason2866/esp32-arduino-lib-builder/releases/download/427/framework-arduinoespressif32-master-583026f04.tar.gz
Can be used directly with Platformio

Edit: It is not the chip revision. Just checked the AI-Thinker ESP-C3-01M is revision 3 too.
Screenshot_20210911-205200

@wibbler
Copy link

wibbler commented Sep 12, 2021

I don't know if this is relevant, but I'm climbing up the wall trying to get BLE working on these boards, I have two 20120716 boards, both act the same , advertising now and again, scanning never. I'm using esp-idf-4.3.1. I've tried all sorts of things, I really am beginning to believe the RF side of these boards are borked. I'll try 4.4 and master or whatever, but lost two days trying to get esp-idf example code working (as well as my own known good code), very disappointed with lilygo

@gigamegawatts
Copy link

@wibbler I hadn't tried BLE before today, but I have problems too with my 20210716 board.

I only tried GATT server examples: advertising works, but I can't connect. No connect or disconnect event is raised by the ESP-IDF code. It would seem that whatever's going wrong is happening in hardware, since I don't see any related BLE issues in the ESP-IDF Github.

I tried the Nimble, BlueDroid (both ESP-IDF 4.3) and even the Arduino BLE stacks, and get the same result in each case.

So, yeah, assuming that there aren't some other users happily using Wi-Fi and BLE with the OI PLUS, something's borked on the RF side. LilyGo stopped selling this board a while ago, and that might be the closest thing we get to a confirmation from them.

I notice that LilyGo has recently started selling their own C3 module (i.e. just the SOC without a board). There's not much info on their site, but the obvious differences from the OI PLUS are a PCB antenna and a metal shielding enclosure. Imma pass on that one.

@Jason2866
Copy link

Jason2866 commented Sep 13, 2021

The board is borked. Every other C3 boards do work, including BLE.
LilyGo will do nothing. There will be silence on this topic (see this issue and #10). If the react the would have to tell the sold crap or find a solution (there is none for bad HF design). The only way would to replace the boards with good ones. This the will try to avoid. My decision is made. Never again anything from them.

@LilyGO
Copy link
Contributor

LilyGO commented Sep 29, 2021

Sorry for the inconvenience, the new version has been updated to fix it.

@krystiansliwa
Copy link

@LilyGO New version of board?

@LilyGO
Copy link
Contributor

LilyGO commented Sep 29, 2021

New version

@krystiansliwa
Copy link

Do you plan to replace broken ones?

@LilyGO
Copy link
Contributor

LilyGO commented Sep 29, 2021

Yes, you can contact the customer for replacement

@TMillesich
Copy link

Lilygo customer support replies with: "Hello, could you send us a screenshot of the serial printing about the error?"

I'm a bit out of ideas what exactly they want.

@gigamegawatts
Copy link

I received the exact same reply. I don't know what it means either.

I also wonder what they've changed in the new version of the board. The antenna is obviously different, but they've also reoriented the chip and surrounding components. The notice on this Github says "The new version has fixed the glitch that caused crystal burrs to start wifi and ble reset", which doesn't mean much to me.

@LilyGO
Copy link
Contributor

LilyGO commented Oct 6, 2021

Customer service needs you to provide a screenshot of the reset serial port after wifi is turned on

@yshestakov
Copy link
Author

@LilyGO Already provided the moment of reset on wifi connection attempt:
Screenshot 2021-10-10 at 21 03 08

@mgsb
Copy link

mgsb commented Oct 10, 2021

I got my replacements this week and WiFi is working now. I have not tried BLE, yet. I am using IDF 4.3.1 with MicroPython 1.17.

@LilyGO
Copy link
Contributor

LilyGO commented Oct 13, 2021

For older versions, the following changes need to be made. Starting wifi will not restart.But the wifi antenna is not very good, the signal is still poor.
1

The latest version has fixed these problems with the previous version.

@LilyGO LilyGO closed this as completed Oct 13, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants