ESP32-CAM in boot loop (flash read err, 1000)

[rtek1000]

Board

ESP32-CAM Ai-Thinker

Device Description

ESP32-CAM with camera attached and SD card inserted

Hardware Configuration

ESP32-CAM with camera attached and SD card inserted

Version

v1.0.6

IDE Name

Arduino IDE 1.8.19

Operating System

Xubuntu 20.04

Flash frequency

80MHz

PSRAM enabled

yes

Upload speed

115200

Description

ESP32-CAM in boot loop

Sketch

Anyone

Debug Message

rst:0x10 (RTCWDT_RTC_RESET),boot:0xb (HSPI_FLASH_BOOT)
flash read err, 1000
ets_main.c 371 
ets Jun  8 2016 00:22:57

Other Steps to Reproduce

Inserting the SD card causes the problem

Note: I didn't see the Troubleshooting Guide, it would be nice to have a link to that along with the warning when opening the issue.

But on the Internet I didn't find anything directly related to ESP32-CAM either.

Since this board model already has an SD card socket, it would be interesting to have a way to allow firmware uploads to be carried out even with the presence of the SD card. Otherwise, I have to remove the SD card and then upload the firmware via the serial port.

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

• I confirm I have checked existing issues, online documentation and Troubleshooting guide.

[TheVisionariesInk]

Been having fun with the same issue. From what I have read you need to add a pull-up resistor to pin 2 after flashing.
I am having issues with the Arduino ESP board & SD Cards in PSI mode in version 2.0.2. works under 2.0.0 slowly or 1.0.6 quite well. You do need to set HSPI as per:
SPIClass spi = SPIClass(HSPI);
spi.begin(14 , 2 , 15 , 13 );// spi.begin(SCK,MISO,MOSI,CS);
if (!SD.begin(13,spi,40000000)) Serial.println("Card Mount Failed"); // SD.begin defaults to 4MHz, not 40Mhz as listed in some locations.

I have also seen a few reference to people adding a resistor after flashing, some adding a transistor to control power.
Otherwise the SD card can interferes with the flashing process.

You could try OTA, but I think it will suffer the same issue.

[lbernstone]

https://github.com/espressif/esp-idf/tree/master/examples/storage/sd_card/sdmmc#note-about-gpio12-esp32-only

[TheVisionariesInk]

Arduino version 1.0.6 library works correctly
Arduino version 2.0.0 library works but is slow
Arduino version 2.0.2 library fails badly as we know

#6081
leads to
#6103

From those I compared the 1.0.6, 2.0.0, 2.0.2 versions of the sd_diskio.cpp, and benchmarked the performance.

From 2.0.0->2.0.2 function “ff_sd_status” has the following added (near line 610)
if(sdCommand(pdrv, SEND_STATUS, 0, NULL) == 0xFF)
{
log_e("Check status failed");
return STA_NOINIT;
}

#6103 recommends removing these lines.
By commenting the lines out, it works, but I still can only read and write at 2.0.0 speeds, but still fails sometimes

From 1.0.6->2.0.0 function “sdSelectCard” had the following lines added (near line 120)

•   digitalWrite(card->ssPin, HIGH);
  

•  return false;
  

6103 recommends removing these lines, but I suggest that keeping the “return false;” it will give an error when it fails, and thus the ability to retry.

With both these sets of lines disabled, I can read and write correctly.
SPI access to the SD is about 10% of write and about 20% of read speed of 1bit SD mode.
If I override the SD speed to 40Mhz instead of the 4Mhz it defaults to, that jumps to 22% & 60% respectively.

spi.begin(14 , 2 , 15 , 13 );// spi.begin(SCK,MISO,MOSI,CS);
if (!SD.begin(13,spi,40000000)) Serial.println("Card Mount Failed");

[me-no-dev]

@P-R-O-C-H-Y PTAL on the speed issues

[P-R-O-C-H-Y]

Hi @TheVisionariesInk
About the SD card speeds. In upcoming 2.0.3 version the SD card will be fixed (already in master #6103 ) and there is PR #6456 (not merged yet) that improves read speeds a lot when reading bigger chunks of data. For what I tested, the write speed doesn't differ too much from 1.0.6 version. For 1 MB data (512 byte chunks write) the time it took was +50~100 ms.

Table of testing the read speeds.

chunk in bytes / 1 MB data read time	master branch	with PR #6456
64 bytes	1502 ms	1502 ms
128 bytes	1422 ms	1354 ms
256 bytes	1382 ms	1118 ms
512 bytes	1366 ms	934 ms
1024 bytes	1351 ms	805 ms
2048 bytes	1347 ms	705 ms
4096 bytes	1345 ms	649 ms
8192 bytes	1345 ms	621 ms

[TheVisionariesInk]

I have updated the source and tested.
I confirm the speed is good now.
Nice work.

Thank you for your efforts

[P-R-O-C-H-Y]

Thank you and thanks for testing that @TheVisionariesInk !
Is there still some issue or it can be closed? I think you still have the problem where you need to remove the sd from slot to be able to upload firmware right?

[s-hadinger]

@P-R-O-C-H-Y Sorry I'm cross-posting here, but #6456 is breaking reads when mixing small and large chunks.

The code is in Berry but the mapping is striaghtforward.

Scenario 1:

• open file
• read 128 bytes
• read 128 bytes
• close

f=open("robotocondensed_latin1.tapp")
s1=f.readbytes(128)
s2=f.readbytes(128)
f.close()
print(s1)
print(s2)

# bytes('504B03040A0000000000B8B8755431C19D1968000000680000000B001C006175...')
# bytes('6C6174696E312873697A6529600A0A696D706F727420726F626F746F636F6E64...')
# CORRECT

Scenario 2:

• open file
• read 128 bytes
• read 256 bytes
• close

f=open("robotocondensed_latin1.tapp")
s1=f.readbytes(128)
s2=f.readbytes(256)
f.close()
print(size(s1))
print(s1)
print(s2)

# bytes('504B03040A0000000000B8B8755431C19D1968000000680000000B001C006175...')
# bytes('1300207C9004822410900F1004C170003804E626822258748689F0180000200C...')
# SECOND IS INCORRECT

In scenario 2, the read is above 128 ans the result is wrong. The result looks like garbage - not content from the file, and it often crashes right after as a hint of memory corruption.

I have some questions:

• __fpending(_f); is normally for the output buffer, not the input buffer. Am I missing something?
• lseek(fileno(_f),(-128+bytesinbuf),SEEK_CUR); why is the file seeked 128 bytes ahead of bytesinbuf? Are we even sure that bytesinbuf is always greater than 128? If not the substraction is invalid and yields to an overflow.

[P-R-O-C-H-Y]

@s-hadinger Hi, its OK :)
But Jason from Tasmota opened discussion about that -> #6507.
So if you can post the sketch and your tests there I will appreciate that.
Its better to be all in 1 place. You can just "copy/paste" your comment from here ;)

I can answer all your questions there. So more people can see that.

Thank you for understanding!

[P-R-O-C-H-Y]

@rtek1000 Does your issue still persist? Or we can close this one :)

[TheVisionariesInk]

Issue appears to be resolved. thank you