ESP32 restarts when trying to connect with WiFiClient .

[bartdereu]

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.

[TD-er]

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]

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]

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

[bartdereu]

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]

Please provide a minimal example sketch to reproduce the issue

[TD-er]

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]

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]

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]

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]

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]

@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]

@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]

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

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

[kapyaar]

@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]

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

[kapyaar]

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

[TD-er]

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);

[kapyaar]

Tried it (on 3.1.3), same result.

[TD-er]

OK, just so I understand it correctly...
You see a completely unrelated pin act on starting the Wire interface?

Could it be that the other (unrelated) pin was maybe assigned to be one of the I2C pins and thus got reset when you start Wire.begin ?

So what if you set the Wire pins immediately in setup() and then set the other GPIO pin?
Then if you start Wire.begin(), it should not change the unrelated pin, right?

Your example does seem to be using GPIO-0 as 'the other unrelated' pin.
So if this hypothesis is correct, then it might be some unfortunate init of the 'current' pins for I2C to 0 instead of -1.

[kapyaar]

Interesting. As you suggested, I called setPinModes() after Wire.begin, and that seems to make it work!! Pressing the button gives 0, and release gives 1.

[TD-er]

OK, so we need to dive into the I2C interface code to see if the default assigned pins might be set to 0 instead of -1 and thus might be reset by periman when you assign "new" pins.

[TD-er]

@kapyaar
Can you check in your setup what values are set for SDA and SCL?
In caps.

So can you print those values in the setup() to serial?

[kapyaar]

Serial.print("SDA: ");Serial.println(SDA);
Serial.print("SCL: ");Serial.println(SCL);

Shows

SDA: 21
SCL: 22

[kapyaar]

@TD-er Just wanted to check if this discussion has been further looked into :)