ESP-32 Cam on a restart loop

[InsertPotatoHere]

#2763 # Hardware:
Board: ESP32-Cam AI Thinker Module
Core Installation version: 1.8.9
IDE name: Arduino IDE
Flash Frequency: 80Mhz
PSRAM enabled: Yes
Upload Speed: 921600
Computer OS: Windows 10

Description:

Trying to upload code onto a ESP-32 Cam, and it uploads fine either as a Wrover board or a AI Thinker ESP-32 CAM. However, the serial output is in a constant loop of restarting. Weirdly enough, it only happens to certain esp32 modules that I received recently, while my original module works completely fine. I've also tried clearing the flash memory on the chips that aren't working, but the problem still persists. Tried my other YP-05 programmer and the same results still appear. The module is running on 5v USB port on my monitor, and my USB tester is not showing any power consumption, so brownouts is not likely an issue here. I also tested the continuity of the reset switch, and it works fine. I might suspect this is a manufacturer defect, as all three modules I had ordered from them suffers from the issue I am detailing (but still had good reviews), while the one that works was one I ordered a while back. Strangely enough, the code uploads on these boards without needing to press the reset switch on the bottom, so I'm guessing there could be a possible short on the switch

Using esptool.py flash_id, the one that doesnt works returns:

Detecting chip type... ESP32
Chip is ESP32D0WDQ6 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
Manufacturer: ef
Device: 4016
Detected flash size: 4MB

While the module that does work returns:

Detecting chip type... ESP32
Chip is ESP32D0WDQ6 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
Manufacturer: 68
Device: 4016
Detected flash size: 4MB

Sketch:

void setup(){
    Serial.begin(115200);
    Serial.println("Test"); //Doesnt print
}
void loop(){ }

Debug Messages:

Enable Verbose and Debug, no additional information was given in the serial monitor

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0018,len:4
load:0x3fff001c,len:1100
load:0x40078000,len:9232
load:0x40080400,len:6400
entry 0x400806a8
ets Jun  8 2016 00:22:57

rst:0x3 (SW_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0018,len:4
load:0x3fff001c,len:1100
load:0x40078000,len:9232
load:0x40080400,len:6400
entry 0x400806a8
ets Jun  8 2016 00:22:57
...... 
(The SW_RESET entry keeps repeating about every 100ms +- 2 ms)

[benv666]

Got exactly the same here on a brand new ESP32Cam while tinkering with the TenDollarWebcam project:

rst:0x3 (SW_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:1100
load:0x40078000,len:9232
load:0x40080400,len:6412
entry 0x400806a8
ets Jun  8 2016 00:22:57

rst:0x3 (SW_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:1100
load:0x40078000,len:9232
load:0x40080400,len:6412
entry 0x400806a8

(etc)

Seems to be triggered by the wireless though, since before I hacked out the AutoWifi/Smartconfig stuff it would wait there for SmartConfig. (could not get that to work on my phone, so I hacked it out in favor of a 'normal' WiFi.begin(); call, after which this started to occur)

[InsertPotatoHere]

Any solutions you came across? Mine is just anything that is uploaded, even a blank script comes across this issues and I'm not entirely sure if its a software or hardware problem. Clearing the flash seems to not do anything, but I'm not sure if its because of the FTDI adaptor I have or if the product itself is faulty. The reason I'm leaning against a hardware problem is because on closer inspection, all SMD components seem fine and all three came faulty, which would rarely happen if they did any QA testing

[lbernstone]

Reboots during WiFi initialization are typically power issues. Powering through the USB is very often inadequate to provide the peak power needed to fire up the radios. Different manufacturers use different components, especially the power regulators, which may not get enough current from a computer USB port.
Continual reboots with an empty sketch are more likely connection/flash issues. Set the board type to 'esp32 dev module'. Set all the options to the lowest level (DIO/40MHz flash/No PSRAM/115200 baud) and try to upload again.

[InsertPotatoHere]

Thanks, just setting the flash to 40MHz worked for me. . Do you know any way I can replace the power regulators if possible?

[lbernstone]

https://www.youtube.com/results?search_query=desoldering+components+from+pcb
I doubt it is worth the effort trying to match the components for a $10 item. Don't buy from that vendor again...

[kbickham]

Same issue here, I'm driving from a 3amp ldo linear regulator.

rst:0x3 (SW_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0018,len:4
load:0x3fff001c,len:1100
load:0x40078000,len:9232
load:0x40080400,len:6400
entry 0x400806a8

[AmeyaVS]

Hello @kbickham ,

You can try and change the flash frequency to 80 MHz also(instead of 40MHz as suggested by @lbernstone ) and see if it works for you.
Even I was having similar issue regarding boot loop between two of my esp32cam boards.

Here are the outputs of esptool.py flash_id for two of the esp32cam boards I have:

• Board with reboot issues:

  esptool.py v2.6
  Found 1 serial ports
  Serial port COM4
  Connecting........_____....._____....._____....._____..
  Detecting chip type... ESP32
  Chip is ESP32D0WDQ5 (revision 1)
  Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme
  None
  MAC: 
  Uploading stub...
  Running stub...
  Stub running...
  Manufacturer: 1c
  Device: 3016
  Detected flash size: 4MB
  Hard resetting via RTS pin..
  

• Board without reboot issues:

  esptool.py v2.6
  Found 1 serial ports
  Serial port COM4
  Connecting....
  Detecting chip type... ESP32
  Chip is ESP32D0WDQ6 (revision 1)
  Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme
  None
  MAC: 
  Uploading stub...
  Running stub...
  Stub running...
  Manufacturer: 20
  Device: 4016
  Detected flash size: 4MB
  Hard resetting via RTS pin...
  

I tried measuring the power difference between the two boards during power-up and I could not notice any differences.

When I changed the build configuration to 80 Mhz, and uploaded the generated binary for the board with reboot issues now functions flawlessly.

Hope it helps.

[sarath341]

Reboots during WiFi initialization are typically power issues. Powering through the USB is very often inadequate to provide the peak power needed to fire up the radios. Different manufacturers use different components, especially the power regulators, which may not get enough current from a computer USB port.
Continual reboots with an empty sketch are more likely connection/flash issues. Set the board type to 'esp32 dev module'. Set all the options to the lowest level (DIO/40MHz flash/No PSRAM/115200 baud) and try to upload again.

This works perfect with ESPRESSIF ESP32CAM. Most probably power issues.

[sadachiro]

I bought 4 esp32cam. one came with this loop defect. I installed the 3 in the store aisles, but 2 boards came to burn for a peak of energy burned the source, then the 3.3V regulator (esp32cam) shorted at 2 passing the peak of energy, shorted the CI Esp32 and burned the 2 cameras. Testing the boards I found that the memories were OK, so I decided to change the memory of the board with the loop defect. And OK the board is back up and running, already programmed with the configuration of the other board. Then I re-uploaded the program and OK. I discovered that the defect is in the CI 25Q32 J 1932 AS01173, under the metal shield. The 3 boards have this CI from different manufacturers (the ones that were good were XTX and BoyaMicro). I hope it helps. I lost a few hours on this problem and now I can say that it is a hardware problem.