Boot Inestability

[luismalddonado]

Hardware

ESP32

Firmware version

2.4.0

Application version

2.4.0

What happened? What did you expect to happen?

When booting the ESP32 device "sometimes" it does not respond:

1. Web interface does not fully load (however it loads partially but is not operable)
2. When pinging the device:
   C:\Users\luism>ping -t 192.168.3.25
   Pinging 192.168.3.25 with 32 bytes of data:
   Request timed out.
   Request timed out.
   Request timed out.
   Reply from 192.168.3.25: bytes=32 time=12ms TTL=255
   Request timed out.
   Request timed out.
   Reply from 192.168.3.25: bytes=32 time=194ms TTL=255
   Request timed out.
   Request timed out.
   Reply from 192.168.3.25: bytes=32 time=1233ms TTL=255
   Reply from 192.168.3.25: bytes=32 time=3ms TTL=255
   Request timed out.
   Request timed out.
   Reply from 192.168.3.25: bytes=32 time=1282ms TTL=255
   Reply from 192.168.3.25: bytes=32 time=2ms TTL=255
   Request timed out.
   Request timed out.
   Reply from 192.168.3.25: bytes=32 time=1053ms TTL=255
   Reply from 192.168.3.25: bytes=32 time=7ms TTL=255
   Reply from 192.168.3.25: bytes=32 time=25ms TTL=255
   Reply from 192.168.3.25: bytes=32 time=4ms TTL=255
   Reply from 192.168.3.25: bytes=32 time=3ms TTL=255
   Reply from 192.168.3.25: bytes=32 time=2ms TTL=255
   Reply from 192.168.3.25: bytes=32 time=3ms TTL=255
   Reply from 192.168.3.25: bytes=32 time=2ms TTL=255
   Reply from 192.168.3.25: bytes=32 time=2ms TTL=255
   Reply from 192.168.3.25: bytes=32 time=3ms TTL=255
   Reply from 192.168.3.25: bytes=32 time=3ms TTL=255
   Reply from 192.168.3.25: bytes=32 time=2ms TTL=255 <<--Try to access web interface
   Request timed out.
   Request timed out.

NOTES:
1) Unfortunatly when trying to debug, connecting to a USB Drive in a PC it always works well
2) If I start the ESP32 with the CC1101 Transceiver disconnected (3v3 pin unplugged) and after start I connect it, it works well after disabling/enabling Radio in the Web Interface
3) I have a ASUS Mesh wifi (AIMesh). As you can see in the logs my SSID it listed twice with 2 different MAC addresses. I just left the last digits of the MAC address visible

I use a brand new Micro-USB cable and a brand new 2.4 A USB charger.

How to reproduce it (step by step)

1. Reboot the device
2. Connected to the Web interface

Logs

Logs when working well (connected to a PC):
Startup/Boot....
Mounting File System...
File system mounted successfully
Chip Model ESP32-
Preference IP Free Entries: 477
SECURITY   Type:0 Username:[] Password:[] Pin:[] Permissions:0
Connection Type: 1
NTP Settings 
pool.ntp.org TZ:CEST-1CET,M3.2.0/2:00:00,M11.1.0/2:00:00
WIFI Settings
 SSID: [DOMOTICACASA] PassPhrase: [xxxxxxxxxxxxxxxx]
Launching web server...
Creating Web MicroServices...
WiFi Mode: 0
Scanned 12 Networks...
*0: DOMOTICACASA (-40dBm) CH:2 MAC:xx:xx:xx:01:D7:40
 1: DIRECT-1C-HP -CASA (-41dBm) CH:2 MAC:xxxxxxxxxxxxxx
*2: DOMOTICACASA (-49dBm) CH:2 MAC:xx:xx:xx:70:BD:A1
 3: MIWIFI_dQsx (-69dBm) CH:7 MAC:xxxxxxxxxxxxxx
 4: MOVISTAR_EACD (-76dBm) CH:11 MAC:xxxxxxxxxxxxxx
************  I removed other networks from the list ************
Socket Server Started...
Max Heap: 110580
Free Heap: 183780
Min Heap: 181536
Connecting to AP
Set hostname to:toldos
**
Successfully Connected to WiFi!!!!192.168.3.25 (-40dbm)
MDNS Responder Started: serverId=E99A28
Max Heap: 110580
Free Heap: 176224
Min Heap: 173916
App Version:2.4.0
shades.cfg exists so we are using that
Reading header at 0
version:22 len:76 roomSize:29 roomRecs:1 shadeSize:276 shadeRecs:3 groupSize:194 groupRecs: 0 pos:76
Applying radio settings Setting Data Pins RX:12 TX:13
Setting SPI Pins SCK:18 MISO:19 MOSI:23 CSN:5
Radio Pins Configured!
Successfully set up the radio
Enabled receive on Pin #12 Timing: 1
Initializing RX Queue
Socket [0] Connected from 192.168.3.16 url: /
Socket [1] Connected from 192.168.3.10 url: /
Max Heap: 110580
Free Heap: 166788
Min Heap: 152436
Setting Transceiver Json
Serialize Radio JSON SCK:18 MISO:19 MOSI:23 CSN:5 RX:12 TX:13
Successfully connected MQTT client client-0000289ae9d82240
MQTT Subscribed to:shades/+/target/set
MQTT Subscribed to:shades/+/tiltTarget/set
MQTT Subscribed to:shades/+/direction/set
MQTT Subscribed to:shades/+/mypos/set
MQTT Subscribed to:shades/+/myTiltPos/set
MQTT Subscribed to:shades/+/sunFlag/set
MQTT Subscribed to:shades/+/sunny/set
MQTT Subscribed to:shades/+/windy/set
MQTT Subscribed to:shades/+/position/set
MQTT Subscribed to:shades/+/tiltPosition/set
MQTT Subscribed to:groups/+/direction/set
MQTT Subscribed to:groups/+/sunFlag/set
MQTT Subscribed to:groups/+/sunny/set
MQTT Subscribed to:groups/+/windy/set
Timing Net: 709ms
Client 1 leaving room 0
Sending Shade Command
Received:{"shadeId":2,"command":"down"}

[luismalddonado]

Just as additional INFO I have tested with ESPSomfy-RTS v1.7.2 and I was not able to reproduce this problem.

[rstrouse]

The ESP32 libraries were bumped to 2.0.14 between those versions. I also use AIMesh and do not see the issue on any of 10 devices but I will take a look at what is different in those versions.

[luismalddonado]

The ESP32 libraries were bumped to 2.0.14 between those versions. I also use AIMesh and do not see the issue on any of 10 devices but I will take a look at what is different in those versions.

Thanks. Looking forward to test new versions when available. Again thanks for this amazing project.

[rstrouse]

I would be suspect of that power supply. In some cases the power supply cannot keep up with the spikes that are created when the WiFi radio on the ESP32 is engaged. This causes the ESP32 to panic reset because of a voltage drop on the EN pin. Which looks a lot like the ping pattern above. There were lots of changes to the core ESP32 libraries for the IDF which is why 1.7.2 which is based on v2.0.10 of the ESP32 core works in your testing.

There are lots of posts on many forums about adding a capacitor to the EN pin to smooth this out but there is another thing that I have run into with another user who had weird labeling on their board. If you have a board like this do not use the GPIO11 pin as a ground. It may work but it will be unreliable.

https://forum.arduino.cc/t/weird-gnd-in-esp32-gnd-or-gpio-11/958140

[luismalddonado]

Yes I am using GPIO11 as ground for the antenna . I will leave my producction environment untouched with v1.7.2 (stable for the last 3 days). I ordered a new CC1101. Once it arrives I will do furthers tests.

[rstrouse]

Yes I am using GPIO11 as ground for the antenna .

That while electrically can be used for a ground it should not be used. That pin is connected to SPI and could be browning out when the radio is initialized. You should use an actual ground pin.

[rstrouse]

@luismalddonado did you get your issues sorted? From what I have read, that labeling of GPIO11 as GND is a screen printing error. While when pulled low it does provide a path to ground but it also cannot handle load.

[luismalddonado]

I just got today a second antena, tested with it without using GPIO11 fro GND and it works. It would be great to change the "Suggested Pins" section for "ESP-WROOM-32/ESP32S Models" indicating this and the close this issue.

Thanks for the support