[ESP32] + [Arduino] why do I sometimes need to reset the chip manually?

[Watth]

I have several ESP32S2 "mini" boards, and at first, every attempt required a manual reset. But out of nowhere, sometimes, the chip resets all by itself after the program is complete (I can hear the Windows chime of a USB device unplugging). Then the program runs. But for some reason I can't understand, after another programming, the same board needs a hard reset. How would you explain that to someone who is not very familiar with µControllers inner working? I use Arduino IDE 2.3.0, the board is set as ESP32S2 DEV MODULE. Here's an example:

Code: [Select]

#define PLED 15  // Sortie LED
#define PAUSE 150

void setup() {
  Serial.begin(115200);
  pinMode(PLED, OUTPUT);
  Serial.println("START!");
}

void loop() {
  digitalWrite(PLED, HIGH);
  Serial.print("It's been ");
  Serial.print(millis());
  Serial.println(" milliseconds.");
  delay(PAUSE);
  digitalWrite(PLED, LOW);
  delay(PAUSE);
}Here is the IDE's output:

Code: [Select]

Sketch uses 226194 bytes (17%) of program storage space. Maximum is 1310720 bytes.
Global variables use 14680 bytes (4%) of dynamic memory, leaving 313000 bytes for local variables. Maximum is 327680 bytes.
esptool.py v4.5.1
Serial port COM10
Connecting...
Chip is ESP32-S2FNR2 (revision v0.0)
Features: WiFi, Embedded Flash 4MB, Embedded PSRAM 2MB, ADC and temperature sensor calibration in BLK2 of efuse V2
Crystal is 40MHz
MAC: 84:fc:e6:d1:24:9c
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 921600
Changed.
Configuring flash size...
Flash will be erased from 0x00001000 to 0x00004fff...
Flash will be erased from 0x00008000 to 0x00008fff...
Flash will be erased from 0x0000e000 to 0x0000ffff...
Flash will be erased from 0x00010000 to 0x00047fff...
Compressed 14720 bytes to 10221...
Writing at 0x00001000... (20 %)
Writing at 0x00001c5a... (40 %)
Writing at 0x000027ac... (60 %)
Writing at 0x000032d6... (80 %)
Writing at 0x00003c4c... (100 %)
Wrote 14720 bytes (10221 compressed) at 0x00001000 in 0.2 seconds (effective 514.7 kbit/s)...
Hash of data verified.
Compressed 3072 bytes to 146...
Writing at 0x00008000... (100 %)
Wrote 3072 bytes (146 compressed) at 0x00008000 in 0.1 seconds (effective 331.4 kbit/s)...
Hash of data verified.
Compressed 8192 bytes to 47...
Writing at 0x0000e000... (100 %)
Wrote 8192 bytes (47 compressed) at 0x0000e000 in 0.1 seconds (effective 590.6 kbit/s)...
Hash of data verified.
Compressed 226560 bytes to 133109...
Writing at 0x00010000... (1 %)
Writing at 0x00011548... (3 %)
Writing at 0x00012a4b... (4 %)
Writing at 0x00013e8e... (6 %)
Writing at 0x000158c6... (7 %)
Writing at 0x00016f1f... (9 %)
Writing at 0x00018735... (10 %)
Writing at 0x0001a3b4... (12 %)
Writing at 0x0001cdc8... (13 %)
Writing at 0x0001e84e... (15 %)
Writing at 0x0001f3b9... (16 %)
Writing at 0x0001fc5d... (18 %)
Writing at 0x00020764... (20 %)
Writing at 0x00021388... (21 %)
Writing at 0x00021dc9... (23 %)
Writing at 0x0002280e... (24 %)
Writing at 0x000233bc... (26 %)
Writing at 0x00023f4b... (27 %)
Writing at 0x000248ed... (29 %)
Writing at 0x0002545f... (30 %)
Writing at 0x00025e66... (32 %)
Writing at 0x000267b4... (33 %)
Writing at 0x00027164... (35 %)
Writing at 0x00027be1... (36 %)
Writing at 0x0002857a... (38 %)
Writing at 0x00028f65... (40 %)
Writing at 0x0002997c... (41 %)
Writing at 0x0002a4f5... (43 %)
Writing at 0x0002b0be... (44 %)
Writing at 0x0002bae7... (46 %)
Writing at 0x0002c34b... (47 %)
Writing at 0x0002ce06... (49 %)
Writing at 0x0002d79e... (50 %)
Writing at 0x0002e33a... (52 %)
Writing at 0x0002ed48... (53 %)
Writing at 0x0002f796... (55 %)
Writing at 0x00030239... (56 %)
Writing at 0x00030db2... (58 %)
Writing at 0x00031910... (60 %)
Writing at 0x000322a9... (61 %)
Writing at 0x00032df0... (63 %)
Writing at 0x000339a2... (64 %)
Writing at 0x00034b5a... (66 %)
Writing at 0x00035a39... (67 %)
Writing at 0x0003643b... (69 %)
Writing at 0x00036e3a... (70 %)
Writing at 0x00037b3d... (72 %)
Writing at 0x00038d25... (73 %)
Writing at 0x00039cef... (75 %)
Writing at 0x0003c3e8... (76 %)
Writing at 0x0003d0b0... (78 %)
Writing at 0x0003d9f7... (80 %)
Writing at 0x0003e405... (81 %)
Writing at 0x0003ee5d... (83 %)
Writing at 0x0003fa21... (84 %)
Writing at 0x00040602... (86 %)
Writing at 0x00040ffa... (87 %)
Writing at 0x00041a51... (89 %)
Writing at 0x00042436... (90 %)
Writing at 0x00042eaa... (92 %)
Writing at 0x00043993... (93 %)
Writing at 0x000445e5... (95 %)
Writing at 0x00045471... (96 %)
Writing at 0x00045e3c... (98 %)
Writing at 0x000468b9... (100 %)
Wrote 226560 bytes (133109 compressed) at 0x00010000 in 3.0 seconds (effective 604.9 kbit/s)...
Hash of data verified.

Leaving...
WARNING: ESP32-S2FNR2 (revision v0.0) chip was placed into download mode using GPIO0.
esptool.py can not exit the download mode over USB. To run the app, reset the chip manually.
To suppress this note, set --after option to 'no_reset'.
Failed uploading: uploading error: exit status 1Note that after the reset, the LED blinks as expected, but Windows (therefore Arduino) can't find the board as a USB device (so no connection with the serial monitor).

[Lindley]

Hi,

You code loads and  runs fine on our ESP32wroom board.

It sounds more like you have some usb connection problem, either a failing USB socket either on you PC or possibly the esp board if the fault is only on that one board ?

Also are you using a USB hub, if so try plugging direct into the PC USB socket.

Some USB cables just do not work well with the micros like the Arduino, so do try a few other cables, generally the shorter the better.  eg under 1 mtr long.

[kripton2035]

those boards need a very stable power supply. try to add some filters and decoupling capacitors. 10uF and 100nF.

[tszaboo]

those boards need a very stable power supply. try to add some filters and decoupling capacitors. 10uF and 100nF.

I second that, but actually bigger capacitor. 100uF or so. ESPs need like 500mA power supply and I think they sometimes create even larger load currents.
I had similar issues with I2C sensors getting stuck, a large Elco solved the issue.

[westfw]

One Possible reason:

The Arduino boards with "native USB" use a hack to reset the board for uploading new firmware.  They set the baudrate of the USB/CDC channel to 1200bps.  The Arduino USB Core software detects this can causes a reset (and then runs the bootloader.)

Any bug in your "sketch" that interferes with proper USB/CDC operation will prevent this from working, and force you to do a manual reset.