esp32c3: Connection fail loop #43655
Comments
mbolivar-nordic
added
priority: low
|
@bgreggsmith, the log output in ESP32C3 kind of tells that the input password is wrong. It is trying to connect to the SSID but gets disconnected due to wrong password. Have you run |
|
@sylvioalves I did run west update. Here's what I dont understand; the identical code and credentials when compiled for esp32 (as opposed to esp32c3) and flashed to an esp32 (as opposed to an esp32c3) connects just fine. |
|
I'm experiencing exactly the same issue with ESP32-C3 and I double-checked that my password and SSID are set correctly. As also mentioned in Discord, the |
|
@bgreggsmith @martinjaeger I can't reproduce in here at all. Anyway, I'll try with other boards to evaluate it properly. |
|
@sylvioalves Took delivery of a new batch of boards today (These are ESP32-C3-WROOM-02, the old boards I was testing on were ESP-C3-32S) and these now work fine with the original binary. Thanks for your time on this, but I think we can mark this as solved. |
|
@bgreggsmith no, it's not solved for me. I will double-check with a different board as well. |
|
I have tried this out with multiple boards now. The issue is very strange. I've got two different ESP32-C3-DevKitM-1 boards. On one board it works fine, on the other one it fails with above disconnect loop, even after multiple resets, flash erase cycles, etc. Both boards may be from different batches because I bought one from ebay just after it was released and the other one later from Digikey/Mouser. The working one is the XXH4 variant, the other the XXN4 variant, everything else including the ROM and 2nd stage bootloader is exactly the same: Annoyingly, I've developed some custom boards (XXN4 module variant) which all fail to connect to the access point. They do work perfectly fine and immediately connect with most recent ESP-IDF (git describe: v5.0-dev-2137-g2f9d47c708) and Any ideas? Could the temperature rating (N4 vs H4) be relevant? @bgreggsmith could you please check which temperature variant your failing board has? It's written at the very bottom of the sheet metal shield. |
|
@martinjaeger This just got interesting enough for me to open the work laptop on a weekend. I thought it was just me and that I had a bunch of bad boards. I'm working on large(r) networks so I have about 20 of these things and I flashed the first 9 boards with the same firmware on Friday. 6 work fine, 3 are unable to connect to anything. Re-flashing them doesn't help, so I was under the impression I had 3 DOA boards or a very weird bug in my test firmware. Temperatures are just normal bench conditions (about 20C?). Guess I'm not sending off some emails to RMA or tearing apart my work just yet. It did seem weird that espressif would have ~30% failure rate of boards. |
|
@bgreggsmith That's interesting, thanks for investigating. Were all of your boards exactly the same hardware and from the same production run (ordered at the same time)? With temperature variant I meant the type of the ESP32-C3 module. They are available for 105°C (H4) and 85°C (N4) operating temperature, see below picture: |
|
@martinjaeger So I have 3 sets of boards, one normal ESP32 with a ESP-WROOM-32 module of unknown origin (it's been in the lab a while from someone elses' order). This one works perfectly. Then I have a pair of boards with the ESP-C3-32S module which has FCC ID 2ATPO-ESP-C3-X and no other markings both of which are affected by this connection bug. These have an Ai logo on them and not much else besides the CMIIT ID and FCC ID. The board the module is on is a "NodeMCU-Series". Being from amazon, it wouldn't surprise me theres some weirdness I'm in the dark about. Finally I have a batch of 16 boards which have the ESP32-C3-WROOM-02 module on them. These are the only ones with that XXN4 marking. All these boards were bought recently off mouser as a single order. Of these I've unboxed 9 and 6 of them work perfectly, 3 are affected by this bug. These are the boards I really care about since I need 12 working ones and getting them out of the US into Germany has been a multi-month ordeal because apparently shipping a trace antenna to Germany is a threat to US national security so fixing this will be faster than getting more. |
|
I was able to reproduce the issue as well. I'll check this. |
|
@sylvioalves do you possibly have any update on this already? I'd be willing to support with narrowing down the issue, but as I'm not too familiar with the exact way how |
|
To seconds this, I don't have much experience messing with the insides of zephyr but in the next week or two this might be a blocker for me so I might also have to dig into whats going wrong, so a pointer on where to start for this issue might be helpful. |
|
@martinjaeger I have started working on this a few days ago, but no success yet. Will ping you once fixed. |
Excellent, thanks a lot @sylvioalves! |
|
@sylvioalves Hi, |
|
@omikronlambda sadly not, its been a blocker for me for a while now, so I'm probably going to have to spend more hours than I'd like figuring out where to even start since I've not had any hints either :( |
|
@omikronlambda I could not figure that out yet. I have been updating hal layer to bring the latest modifications and check if it solves it. |
Is that HAL update already available upstream or did you only test it locally? I would be interested in testing as well, but don't know how to update the HAL manually. |
|
I test HAL updates periodcally ('west update' with zephyr's 'revision: main', then 'west espressif update'), but still no way. |
|
@sylvioalves I have a network of ESP32C3s which I thought were known good on the bench. I'd be happy to help test anything you think might help since I am seeing increasingly erratic behaviour of known good boards as the number of nodes increases. |
|
Just check updates. Still the same :( |
|
I've replicated the issue on an I'm going to poke around a little bit and see if I can identify any differences. |
|
I have a bunch of |
|
@sylvioalves do you have any estimation when the Espressif team will have time to have a closer look into this or upgrade to next version HAL? This bug makes the ESP32-C3 pretty much unusable for Zephyr, as WiFi is one of the key features why one would choose this MCU. |
|
Hi, I managed to get this fixed, will submit the PR soon. |
|
That's really good news, thanks @sylvioalves! |
|
@sylvioalves Thanks! Waiting to see how to fix it so I can finally use my dev-kit. 😄 |
|
Hi I have a similare issue with ESP32C3 WROOM 02 H4 / N4. I find no information about this issue. can someone explain me the origin of what you find ? I thanks you in advance Spilz |
Describe the bug
The sample code for connecting to wifi (samples/boards/esp32/wifi_station), works fine on esp32 but does not work on esp32c3. Instead of connecting, a disconnect loop is obtained.
This is on a generic esp32c3 development board. Zephyr version 3.0.99.
This happens on a WPA1, WPA2, and Open access point. Building the same code for esp32 and running on a normal esp32 yields perfectly normal behaviour.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Board connects to access point and get a DHCP address.
Impact
Unable to connect to wifi on esp32c3.
Logs and console output
Console output (the loop) on ESP32C3:
Same code, ESP32 output:
Environment (please complete the following information):
The text was updated successfully, but these errors were encountered: