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

ESP32 restarts when trying to connect with WiFiClient . #10974

Open
1 task done
bartdereu opened this issue Feb 15, 2025 · 17 comments
Open
1 task done

ESP32 restarts when trying to connect with WiFiClient . #10974

bartdereu opened this issue Feb 15, 2025 · 17 comments
Labels
Status: Awaiting triage Issue is waiting for triage

Comments

@bartdereu
Copy link

Board

Arduino Nano ESP32

Device Description

I have the problem even with the bare board not connected to anything.

Hardware Configuration

nothing

Version

v3.1.2

IDE Name

Arduino IDE

Operating System

Windows 10

Flash frequency

default

PSRAM enabled

no

Upload speed

default

Description

As soon as i try to connect , the board reboots.

Sketch

if (WiFiClient.connect(Host,Port) == false) //Attempt connection
{
     /// i don't even get here, the board has already restarted/
}

Debug Message

no error, or debug message. The compiling goes error free, so does the uploading.

Other Steps to Reproduce

I got it fixed by downgrading to version 3.0.2

I have checked existing issues, online documentation and the Troubleshooting Guide

  • I confirm I have checked existing issues, online documentation and Troubleshooting guide.
@bartdereu bartdereu added the Status: Awaiting triage Issue is waiting for triage label Feb 15, 2025
@TD-er
Copy link
Contributor

TD-er commented Feb 15, 2025

Is the board already connected to a WiFi access point when you try to connect?
And what is the surrounding code?
WiFiClient is also the name of a class.
So I assume you have created an object called WiFiClient and not try to invoke the connect function of that class without constructing an object first?

@NinoBenci
Copy link

I have experienced the same issue when I update from version 3.0.7 to 3.1.2. My current versions of libraries are;

Used: C:\Users\...\esp32\hardware\esp32\3.0.7\libraries\ESPmDNS
Used: C:\Users\...\hardware\esp32\3.0.7\libraries\WiFi
Using library webthing-arduino at version 0.12.0
Using library ESPAsyncWebServer at version 3.1.0
Using library FS at version 3.0.7
Using library WiFi at version 3.0.7
Using library Networking at version 3.0.7
Using library AsyncTCP at version 1.1.4
Using library ArduinoJson at version 7.3.0
Using library ESPmDNS at version 3.0.7
Using library ElegantOTA at version 3.1.6
Using library Update at version 3.0.7
Using library BlockNot at version 2.3.0

With version 3.0.7 the basic code compiles with no issues and runs. Updating esp32 to version 3.1.2, the code falls over at;

server.begin();

server initialisation is as follows.;

// setup the ElegantOTA HTTP server
// Using Port 81 as port 80 is used by WebThings
//
AsyncWebServer server(81);

// Setup ElegantOTA Server
//
server.on("/", HTTP_GET, [](AsyncWebServerRequest *request) {
    request->send(200, "text/plain", "UPSV11");
});

server.begin();

At the moment version 3.0.7 works as expected.

@me-no-dev
Copy link
Member

@NinoBenci this is a different issue. Please use the latest Async libs versions from https://github.com/ESP32Async

@bartdereu
Copy link
Author

Is the board already connected to a WiFi access point when you try to connect? And what is the surrounding code? WiFiClient is also the name of a class. So I assume you have created an object called WiFiClient and not try to invoke the connect function of that class without constructing an object first?

The board is indeed connected to a WiFi acces point. And no, i did not mix up the class name.

@me-no-dev
Copy link
Member

Please provide a minimal example sketch to reproduce the issue

@TD-er
Copy link
Contributor

TD-er commented Feb 17, 2025

OK, so your code looks like this?

WiFiClient WiFiClient;
if (WiFiClient.connect(Host,Port) == false) //Attempt connection
{
     /// i don't even get here, the board has already restarted/
}

Maybe better to rename your object to make sure there is no confusion.

WiFiClient client;
if (client.connect(Host,Port) == false) //Attempt connection
{
     /// i don't even get here, the board has already restarted/
}

Oh and there is a new Arduino 3.1.3 release, can you also try that one, just to be sure the crash isn't caused by some String handling which was the reason for the new release this quickly after the 3.1.2 release.

@bartdereu
Copy link
Author

bartdereu commented Feb 17, 2025

The code is as follow :

WiFiClient ntripClient;

if (ntripClient.connect(casterHost, casterPort) == false) //Attempt connection
{
      Serial.println(F("Connection to caster failed"));
      setColor("red");
      delay(1000);
      return;
}
else
{
      Serial.print(F("Connected to "));
      Serial.print(casterHost);
      Serial.print(F(": "));
      Serial.println(casterPort);
 }

The ESP32 restarted as soon as i tried to connect, so i never saw the message 'Connection to caster failed' in
the serial monitor

@TD-er
Copy link
Contributor

TD-er commented Feb 17, 2025

And how is casterHost defined?
Is it possible this is a nullpointer?

If so, please try to update to the latest Arduino release code, which was released today.

@bartdereu
Copy link
Author

bartdereu commented Feb 17, 2025

No casterHost and casterPort are both present and correct. The exact same code works flawless on 3.0.2 , haven't really tried a higher version than that.

I'll have a demo of my product tomorrow , so i'll go on testing after that. Don't want to mess up things
at this stage ;-)

@kapyaar
Copy link

kapyaar commented Feb 17, 2025

I wanted to share my experience with 3.1.2. I am also seeing some really weird behaviours, including the board restarting, because GPIO0 (which is pulled to 3.3 via 10k, and connected to nothing else other than a push switch for manual restart) is getting pulled low. That too, not all the way to 0, but ~0.3V. The issue is repeatable, and I cannot figure out why. A basic switch input goes into an ADC talking on I2C. After boot, by default, switch is open. I can keep reading the adc. If I close the switch, with the next ADC read, GPIO0 is getting pulled low. Everything works no issues with 3.0.7, and 3.1.1. Spent 2 days trying to narrow it down, and I still cannot put a finger on what the real issue is. I think it has something to do with I2C. I know I am not adding any details, as I need some time to get a min code. I am just putting it out here, to see if anyone else is having similar issues, or if it is just me so I could put more time chasing something on my end.

@me-no-dev
Copy link
Member

@kapyaar there is not much different between 3.1.1 and 3.1.2/3.1.3 and certainly nothing in the gpio or i2c drivers. It's rather unexpected to see any negative effects

@kapyaar
Copy link

kapyaar commented Feb 18, 2025

@me-no-dev I would think so too, went through all change logs, and could not find anything that I could relate to in this context.
Anyways, I went back to an ESP32 Dev Board, got GPIO0 pulled up, with a push button, and started narrowing down the code. Eventually, I got to this code.

#include <Arduino.h>
#include <Wire.h>
const uint8_t dataPin = 32;
const uint8_t clockPin = 23;

void setPinModes() {
  pinMode(0, INPUT);  //Reset pin pulled to 3.3V, with a Normally open push button to gnd.
}
void setup() {
  Serial.begin(115200);
  while (!Serial) {
    delay(100);
  }
  setPinModes();
  //Wire.begin(dataPin, clockPin);
}

void loop() {
  Serial.print(digitalRead(0));
  delay(500);
}

With 3.1.1, works just fine. But with 3.1.2 and 3.1.3, if I enable the Wire.begin(...) line, GPIO0 goes to ~0.4V. And Serial gives a 0 value.
Makes no sense. And not to make a fool of myself, I tested it back and forth a lot, and same results.

@TD-er
Copy link
Contributor

TD-er commented Feb 18, 2025

And what if you set the pins first and then call begin()?

  Wire.setPins(dataPin, clockPin);
  Wire.begin();

@kapyaar
Copy link

kapyaar commented Feb 18, 2025

@TD-er Same result. I tested it again to be sure, on both 3.1.1 (works fine) and 3.1.3 (GPIO0 goes to 0.4V). What you suggested is how I have in my original codebase, before slimming it down to what I posted above.

@TD-er
Copy link
Contributor

TD-er commented Feb 18, 2025

I got the suggestion from this thread: #10114 (comment)

@kapyaar
Copy link

kapyaar commented Feb 18, 2025

Got it. It makes sense if only I2C was at play. Can't make sense of a totally unrelated GPIO changing state.

@TD-er
Copy link
Contributor

TD-er commented Feb 18, 2025

Can you try calling this:

gpio_reset_pin(GPIO_NUM_32);
gpio_reset_pin(GPIO_NUM_23);

and then configuring the Wire interface?

Or simpler:

gpio_reset_pin((gpio_num_t)dataPin); // Force-release pins
gpio_reset_pin((gpio_num_t)clockPin);

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Awaiting triage Issue is waiting for triage
Projects
None yet
Development

No branches or pull requests

5 participants