esp_camera_init() causes Core 0 Panic (StoreProhibited)

[Cpt-Squirrell]

I have been attempting to use esp32-camera on an ESP32 M5STACK TimerCam chip for a while now but when it reaches the esp_camera_init(&camera_config) init function it fails and panics. I have tried to alter SPIRAM and Camera settings in menuconfig but alas' nothing worked.

Related code:

void initialise_local()
{
    ESP_LOGI(LOG_TAG, "Initialising NVS.");
    check_esp_status_inl(nvs_flash_init());

    ESP_LOGI(LOG_TAG, "Initialising WiFi.");
    wifi_init_config_t wifi_config = WIFI_INIT_CONFIG_DEFAULT();
    check_esp_status_inl(esp_wifi_init(&wifi_config));
    check_esp_status_inl(esp_wifi_set_mode(WIFI_MODE_STA));
    check_esp_status_inl(esp_wifi_start());

    ESP_LOGI(LOG_TAG, "Initialising camera.");
    const static camera_config_t camera_config = {
    
        .pin_pwdn  = CAM_PIN_PWDN,
        .pin_reset = CAM_PIN_RESET,
        .pin_xclk = CAM_PIN_XCLK,
        .pin_sscb_sda = CAM_PIN_SIOD,
        .pin_sscb_scl = CAM_PIN_SIOC,

        .pin_d7 = CAM_PIN_D7,
        .pin_d6 = CAM_PIN_D6,
        .pin_d5 = CAM_PIN_D5,
        .pin_d4 = CAM_PIN_D4,
        .pin_d3 = CAM_PIN_D3,
        .pin_d2 = CAM_PIN_D2,
        .pin_d1 = CAM_PIN_D1,
        .pin_d0 = CAM_PIN_D0,
        .pin_vsync = CAM_PIN_VSYNC,
        .pin_href = CAM_PIN_HREF,
        .pin_pclk = CAM_PIN_PCLK,

        .xclk_freq_hz = 20000000, //EXPERIMENTAL: Set to 16MHz on ESP32-S2 or ESP32-S3 to enable EDMA mode
        .ledc_timer = LEDC_TIMER_0,
        .ledc_channel = LEDC_CHANNEL_0,

        .pixel_format = PIXFORMAT_JPEG, //YUV422,GRAYSCALE,RGB565,JPEG
        .frame_size = FRAMESIZE_96X96, //QQVGA-QXGA Do not use sizes above QVGA when not JPEG

        .jpeg_quality = 63, //0-63 lower number means higher quality
        .fb_count = 1, //if more than one, i2s runs in continuous mode. Use only with JPEG
        .grab_mode = CAMERA_GRAB_WHEN_EMPTY //CAMERA_GRAB_LATEST. Sets when buffers should be filled
    };
    check_esp_status_inl(esp_camera_init(&camera_config));
}

Output log:

I (1837) SYSTEM: Initialising camera.
I (1837) gpio: GPIO[22]| InputEn: 1| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:2 
I (1847) cam_hal: cam init ok
I (1847) sccb: pin_sda 25 pin_scl 23
I (1847) gpio: GPIO[15]| InputEn: 0| OutputEn: 1| OpenDrain: 0| Pullup: 0| Pulldown: 0| Intr:0 
I (1887) camera: Detected camera at address=0x3c
I (1887) camera: Detected OV3660 camera
I (1887) camera: Camera PID=0x3660 VER=0x00 MIDL=0x00 MIDH=0x00
Guru Meditation Error: Core  0 panic'ed (StoreProhibited). Exception was unhandled.

Core  0 register dump:
PC      : 0x40091378  PS      : 0x00060833  A0      : 0x800938f9  A1      : 0x3ffb9fa0  
A2      : 0xff1d0000  A3      : 0xb33fffff  A4      : 0x0000abab  A5      : 0x00060823  
A6      : 0x00060820  A7      : 0x0000cdcd  A8      : 0x0000cdcd  A9      : 0xffffffff  
A10     : 0x00060823  A11     : 0x00000000  A12     : 0x3ffb4cbc  A13     : 0x00060623  
A14     : 0xbf9d0000  A15     : 0x003fffff  SAR     : 0x00000000  EXCCAUSE: 0x0000001d  
EXCVADDR: 0xff1d0000  LBEG    : 0x00000000  LEND    : 0x00000000  LCOUNT  : 0x00000000  

Backtrace:0x40091375:0x3ffb9fa00x400938f6:0x3ffb9fe0 0x40083c6d:0x3ffba000 0x40083c95:0x3ffba020 0x40083d55:0x3ffba040 0x400834bd:0x3ffba090 0x401265df:0x3ffba0b0 0x4012ece7:0x3ffba0d0 0x4012c21d:0x3ffba0f0 0x400e3836:0x3ffba110 0x400e3881:0x3ffba140 0x40091209:0x3ffba160 
ELF file SHA256: 4dd38a2ccde5c1ab
CPU halted.

It's worth noting that EXCVADDR is always 0xff1d0000.

The camera configurations are as follows:

# Camera configuration
CONFIG_OV7670_SUPPORT=n
CONFIG_OV7725_SUPPORT=n
CONFIG_NT99141_SUPPORT=n
CONFIG_OV2640_SUPPORT=n
CONFIG_OV3660_SUPPORT=y
CONFIG_OV5640_SUPPORT=n
CONFIG_GC2145_SUPPORT=n
CONFIG_GC032A_SUPPORT=n
CONFIG_GC0308_SUPPORT=n
CONFIG_BF3005_SUPPORT=n
CONFIG_BF20A6_SUPPORT=n
# CONFIG_SC101IOT_SUPPORT is not set
CONFIG_SC030IOT_SUPPORT=y
# CONFIG_SC031GS_SUPPORT is not set
CONFIG_SCCB_HARDWARE_I2C_PORT0=y
# CONFIG_SCCB_HARDWARE_I2C_PORT1 is not set
CONFIG_SCCB_CLK_FREQ=100000
CONFIG_GC_SENSOR_WINDOWING_MODE=y
# CONFIG_GC_SENSOR_SUBSAMPLE_MODE is not set
CONFIG_CAMERA_TASK_STACK_SIZE=1024
# CONFIG_CAMERA_CORE0 is not set
# CONFIG_CAMERA_CORE1 is not set
CONFIG_CAMERA_NO_AFFINITY=y
CONFIG_CAMERA_DMA_BUFFER_SIZE_MAX=16364
# end of Camera configuration

[WangYuxin-esp]

It is recommended that you use the example here for testing. If you still report the same error, please let me know.

[Cpt-Squirrell]

I did not know about esp_iot_solution. I downloaded and installed it per instructions. Its basic camera example works without a problem (though it took ages for me to sort out how the hell includes are done. Did not realise that esp_iot_solution had its own esp32-camera). What I do not understand is why it works but mine fails with a panic. I've cross-referenced the source files and I don't see any difference suggesting it would fail. Is my file structure or CMakeLists.txt f'd up? esp-idf has a very confusing file structure to me, though that's probably owed to CMake's inner workings of which I am not comfortable with still.

My project's CMakeLists.txt:

# CMakeLists in this exact order for cmake to work correctly
cmake_minimum_required(VERSION 3.5)

include($ENV{IDF_PATH}/tools/cmake/project.cmake)
include($ENV{IOT_SOLUTION_PATH}/component.cmake)

project(project_name)

My rough file structure looks as following:

├── esp-idf/
│   ├── esp-idf-v4.3.4/
│   └── esp-iot-solution-v4.3.4/
└── projects
    └── project-root
        ├── build/
        ├── components/
        │   └── esp32-camera/
        ├── main/
        │   ├── CMakeLists.txt
        │   └── main.c
        ├── CMakeLists.txt
        └── .vscode

I've exported IOT_SOLUTION_PATH correctly.
esp-idf-v4.3.4, esp-iot-solution-v4.3.4, and esp32-camera are fresh clones of respective repositories.
My original post's source code is still in use.

Am I doing anything wrong according to this?

[WangYuxin-esp]

The example in esp_iot_solution uses the code of esp32-camera. Therefore, this may not be an error caused by the esp32-camera itself. In addition, there is no problem with the current compilation, so it does not appear to be a Cmake error.
The normal log is as follows:

I (325) camera: Detected OV2640 camera
I (325) camera: Camera PID=0x26 VER=0x42 MIDL=0x7f MIDH=0xa2
I (504) s2 ll_cam: node_size: 3840, nodes_per_line: 1, lines_per_node: 6
I (504) s2 ll_cam: dma_half_buffer_min:  3840, dma_half_buffer: 15360, lines_per_half_buffer: 24, dma_buffer_size: 30720
I (512) cam_hal: buffer_size: 30720, half_buffer_size: 15360, node_buffer_size: 3840, node_cnt: 8, total_cnt: 10
I (522) cam_hal: Allocating 153600 Byte frame buffer in PSRAM
I (529) cam_hal: Allocating 153600 Byte frame buffer in PSRAM
I (535) cam_hal: cam config ok
I (539) ov2640: Set PLL: clk_2x: 1, clk_div: 3, pclk_auto: 1, pclk_div: 8
I (714) example:take_picture: Taking picture...

Therefore, please check whether the options in the sdkconfig in your project are the same as this in the example. You can copy this file to your project, re execute the idf.py set-targetcommand, and then compile it.
For some useful links, please refer to:
https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/build-system.html
https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/fatal-errors.html#loadprohibited-storeprohibited

[Cpt-Squirrell]

Many configs were unset, some did not exist, and a handful were set.
After changing them to what you provided the camera says it can not allocate frame buffer (malloc failed).

I (821) gpio: GPIO[15]| InputEn: 0| OutputEn: 1| OpenDrain: 0| Pullup: 0| Pulldown: 0| Intr:0 
I (861) camera: Detected camera at address=0x3c
I (861) camera: Detected OV3660 camera
I (861) camera: Camera PID=0x3660 VER=0x00 MIDL=0x00 MIDH=0x00
I (1181) cam_hal: buffer_size: 32768, half_buffer_size: 4096, node_buffer_size: 2048, node_cnt: 16, total_cnt: 0
I (1181) cam_hal: Allocating 1843 Byte frame buffer in PSRAM
E (1181) cam_hal: cam_dma_config(306): frame buffer malloc failed
E (1191) cam_hal: cam_config(390): cam_dma_config failed
E (1191) camera: Camera config failed with error 0xffffffff
W (1201) SYSTEM FAULT: ESP_FAIL
I (1201) SYSTEM: Connecting to wifi using provided credentials.

[WangYuxin-esp]

The current error message indicates that memory cannot be allocated from the psram. Therefore, please check whether the device has a psram and whether the option of enabling psram is selected(see: CONFIG_ESP32_SPIRAM_SUPPORT). If the sample code can run, I suggest you directly copy the sdkconfig.defaults file to your project, so that some of the options can be automatically selected.

[Cpt-Squirrell]

I'm well aware these errors are PSRAM related. This ESP32 has 8 MB of PSRAM.
Removing (.old-ifying) the sdkconfig file and copying over the example's config.defaults yielded the following when ran in my solution:

I (575) SYSTEM: Initialising camera.
I (575) gpio: GPIO[22]| InputEn: 1| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:2 
I (584) cam_hal: cam init ok
I (587) sccb: pin_sda 25 pin_scl 23
I (591) sccb: sccb_i2c_port=1

I (595) gpio: GPIO[15]| InputEn: 0| OutputEn: 1| OpenDrain: 0| Pullup: 0| Pulldown: 0| Intr:0 
I (634) camera: Detected camera at address=0x3c
I (636) camera: Detected OV3660 camera
I (636) camera: Camera PID=0x3660 VER=0x00 MIDL=0x00 MIDH=0x00
I (955) cam_hal: buffer_size: 32768, half_buffer_size: 4096, node_buffer_size: 2048, node_cnt: 16, total_cnt: 0
Guru Meditation Error: Core  0 panic'ed (LoadProhibited). Exception was unhandled.

Core  0 register dump:
PC      : 0x4009329b  PS      : 0x00060633  A0      : 0x80094351  A1      : 0x3ffbb900  
0x4009329b: block_size at /Documents/esp-idf/esp-idf-v4.3.4/components/heap/heap_tlsf_block_functions.h:75
 (inlined by) block_locate_free at /Documents/esp-idf/esp-idf-v4.3.4/components/heap/heap_tlsf.c:447
 (inlined by) tlsf_malloc at /Documents/esp-idf/esp-idf-v4.3.4/components/heap/heap_tlsf.c:757

A2      : 0x3f800014  A3      : 0x00000028  A4      : 0x3ffb5488  A5      : 0x00060620  
A6      : 0x000000fe  A7      : 0x00000001  A8      : 0xffffffff  A9      : 0x0000000a  
A10     : 0xfffffc00  A11     : 0x00000000  A12     : 0x3ffbb7f4  A13     : 0x3f419498  
A14     : 0x00000001  A15     : 0xff000000  SAR     : 0x00000016  EXCCAUSE: 0x0000001c  
EXCVADDR: 0x00000003  LBEG    : 0x4008b785  LEND    : 0x4008b795  LCOUNT  : 0xfffffffd  
0x4008b785: strlen at /builds/idf/crosstool-NG/.build/xtensa-esp32-elf/src/newlib/newlib/libc/machine/xtensa/strlen.S:84

0x4008b795: strlen at /builds/idf/crosstool-NG/.build/xtensa-esp32-elf/src/newlib/newlib/libc/machine/xtensa/strlen.S:96


Backtrace:0x40093298:0x3ffbb900 0x4009434e:0x3ffbb920 0x40081d3d:0x3ffbb940 0x40081f76:0x3ffbb960 0x400dbe74:0x3ffbb980 0x400dc34b:0x3ffbb9c0 0x400dbb7d:0x3ffbb9f0 0x400db6de:0x3ffbba30 0x400db7ed:0x3ffbbb10 0x40152c07:0x3ffbbb50 0x40091871:0x3ffbbb70
0x40093298: block_locate_free at /Documents/esp-idf/esp-idf-v4.3.4/components/heap/heap_tlsf.c:445
 (inlined by) tlsf_malloc at /Documents/esp-idf/esp-idf-v4.3.4/components/heap/heap_tlsf.c:757

0x4009434e: multi_heap_malloc_impl at /Documents/esp-idf/esp-idf-v4.3.4/components/heap/multi_heap.c:197

0x40081d3d: heap_caps_malloc at /Documents/esp-idf/esp-idf-v4.3.4/components/heap/heap_caps.c:145

0x40081f76: heap_caps_calloc at /Documents/esp-idf/esp-idf-v4.3.4/components/heap/heap_caps.c:395

0x400dbe74: cam_dma_config at /Documents/projects/project_name/components/esp32-camera/driver/cam_hal.c:274

0x400dc34b: cam_config at /Documents/projects/project_name/components/esp32-camera/driver/cam_hal.c:389

0x400dbb7d: esp_camera_init at /Documents/projects/project_name/components/esp32-camera/driver/esp_camera.c:302

0x400db6de: initialise_local at /Documents/projects/project_name/main/main.c:101

0x400db7ed: app_main at /Documents/projects/project_name/main/main.c:144

0x40152c07: main_task at /Documents/esp-idf/esp-idf-v4.3.4/components/freertos/port/port_common.c:145 (discriminator 2)

0x40091871: vPortTaskWrapper at /Documents/esp-idf/esp-idf-v4.3.4/components/freertos/port/xtensa/port.c:168

The ESP32 also endlessly reboots following it.
Using the example's sdkconfig file instead yields (I think) identical results.

[WangYuxin-esp]

Add the sdkconfig file in the following path, then execute the idf.py set-targetcommand, and then compile it.
projects
└── project-root
├── build/
├── components/
│ └── esp32-camera/
├── main/
│ ├── CMakeLists.txt
│ └── main.c
├── CMakeLists.txt
├── sdkconfig.defaults // add adkconfig.defaults here.
└── .vscode

[Cpt-Squirrell]

That is also where it is placed.

[WangYuxin-esp]

So this is probably a problem with the current code, you can replace the current code with the example code and try again.

[Cpt-Squirrell]

Well now I am very confused.
I replaced the source file in my folder with the source file from the example. The only change I did was to define all the pins (and subsequently remove the include for pins) and it still fails the same way with panic LoadProhibited. Something must be wrong about how things are found or included . . .

[me-no-dev]

I think that the timer cam does not have PSRAM, so you need to have that disabled in menuconfig. You would also need config.fb_location = CAMERA_FB_IN_DRAM;. fbcount should be 1 and with that you can grab quite high res JPEGs

[Cpt-Squirrell]

That would be very odd if it does not have PSRAM. On the sales page it most certainly says it has 8 MB PSRAM.
But I will try none the less. If anything, I will at least have it functioning and I don't need PSRAM either way.

[Cpt-Squirrell]

I think the good news is that I've gotten past the initialization of the camera successfully but I am now met with another (I'm pretty sure an unrelated) error from cam_hal saying cam_hal: NO-SOI. If the camera will actually snap a photo correctly now then I'm satisfied; though the original issue is not fixed. This ESP has 8 MB PSRAM and it was set up in config yet I could not initialize the camera with PSRAM whatsoever.

Update: It's only JPEG format causing NO-SOI. Only other posts about it I've found relate to bad sensors or boards. I find that hard to believe though.

[me-no-dev]

NO-SOI is normal during init and size/other changes. The warning means that the code did not find JPEG Start Of Image.

You are correct... the product page does say 8MB PSRAM. Strange what is causing this...

[Cpt-Squirrell]

It does not say NO-SOI only during setup. It spams it after initialization, filling the terminal.

[me-no-dev]

many NO-SOI usually mean that there is an issue with the connection. Could you try QVGA resolution?

[Cpt-Squirrell]

Same result. However, whilst looking at the terminal and at the same time shaking the device by its cable it's clear that there is a correlation. Could it be that the flex-cable is wrongly seated or is it something more sinister?
Quick update: Bad idea to reseat it. The camera came pre-seated from the factory and it was clamped in there well. When trying to get it back in I risk damaging the cable. 😐
Update 2: Maybe I overreacted a little. Still nothing that helped.
Update 3: I have now tested the code on 3 separate but identical ESPs (third one being completely fresh out of the anti-static bag) and all three show the exact same behavior.

[WangYuxin-esp]

Also，many NO-SOI usually mean that there is a problem with the pin connection. Or the FPC line is too long. You can refer to the appearance of the official board here.

[Cpt-Squirrell]

Well, I'm connected with a USB-C so there shouldn't be (I hope) anything wrong with the pin-outs. So if there is something wrong with the pins then it's in the definitions.

Update: I double checked the pin definitions and one of them (D0) was wrong. After fixing that it now never says NO-SOI! Though there is a new message from cam_hal saying FB-OVF exactly 6 times; I will however assume it's harmless since the rest of the code proceeds after them. (Small correction: it can say NO-SOI once further up.)
Update 2: I went ahead and tried getting the frame buffer without having anything to do with it and it started spamming the terminal with FB-OVF and NO-EOI. Also tried returning it immediately after but same result. I might however be using the methods wrong; what I am doing now is simply getting the frame buffer with the get method and providing its return value as argument for the return method.
The ESP reboots by a stack overflow happening a few seconds after it spams the terminal.
Also, once again, it's only JPEG which causes this.

[WangYuxin-esp]

Maybe the xclk is too high. Please try to lower the xclk. ->
xclk = 10M. fb_count = 2;

[Cpt-Squirrell]

No difference.
Just to be on the safe side, this is the code I use to get and return the frame buffer. It runs once.

    camera_fb_t *frame_buffer;
    frame_buffer = esp_camera_fb_get();
    esp_camera_fb_return(frame_buffer);

[WangYuxin-esp]

FRAMESIZE_96X96?，Not all resolutions are well supported in JPEG mode. Try changing the resolution.

[Cpt-Squirrell]

I'm pretty sure I've tried that frame size before but testing it now . . .
. . . no difference.
It appears to sometimes be fast enough to report Failed to get the frame on time! before it overflows.

[WangYuxin-esp]

Please ensure that the current task stack size is large enough.
I used esp32-eye to do some tests here. The ov3660 camera sensor works normally in the following configurations:
1）xclk = 10M+JPEG+QVGA+fb_count = 2
2）xclk = 10M+RGB565+QVGA+fb_count = 2

I (4433) cam_hal: cam init ok
I (4436) sccb: pin_sda 18 pin_scl 23
I (4451) camera: Detected camera at address=0x3c
I (4453) camera: Detected OV3660 camera
I (4453) camera: Camera PID=0x3660 VER=0x00 MIDL=0x00 MIDH=0x00
I (4774) cam_hal: buffer_size: 32768, half_buffer_size: 4096, node_buffer_size: 2048, node_cnt: 16, total_cnt: 3
I (4774) cam_hal: Allocating 15360 Byte frame buffer in PSRAM
I (4780) cam_hal: Allocating 15360 Byte frame buffer in PSRAM
I (4787) cam_hal: cam config ok
I (4804) ov3660: Calculated VCO: 100000000 Hz, PLLCLK: 100000000 Hz, SYSCLK: 25000000 Hz, PCLK: 5000000 Hz
I (4840) pic_s: Starting pic server on port: '80'
I (4842) pic server: Begin capture frame
W (4929) cam_hal: NO-SOI
I (7367) pic_s: pic len 10160
I (8704) pic_s: pic len 10201
I (10582) pic_s: pic len 10132

In addition, may I know what functions you want to use this development board to achieve? As far as I know, ESP32S3 is the latest chip with camera.

[Cpt-Squirrell]

Your example project works without errors or warnings. I will dissect it and see what I can get out of it. I noticed you did not use JPEG format though; I quickly checked if it works with JPEG and it appears to work anyways. If I even after that can't get the project to work then I suppose I'll have to rework it from scratch and see where it fails. If that also returns empty handed then I can only conclude that I have a cursed computer (wouldn't be unlike me with my luck) or corrupt setup.

The original issue (the title) is still not resolved but as long as the DRAM alone is sufficient then I don't need the original issue fixed. If you want to debug the issue to find out if it's something fixable then I can do more tests for you, otherwise this issue can be closed and I thank you for the help. If I run into new trouble then I can open a new issue for that topic.

In addition, may I know what functions you want to use this development board to achieve? As far as I know, ESP32S3 is the latest chip with camera.
The ESPs only job is to receive a remote signal to transfer a single fresh image from its camera to a server where it will be further processed.

[WangYuxin-esp]

Generally, ESP32S3 has better performance in camera related projects. However, the current requirement is only to send a picture, so ESP32 can perfectly support this function. The library supporting JPEG compression is ported to ESP32, so JPEG compression can be completed. However, the memory of ESP32 is limited. The resolution of the compressed pictures should be about 720p, and the speed is average. If you need a large resolution image, it is recommended to use a sensor like OV3660 that can output JPEG directly.

[Cpt-Squirrell]

This device does have an OV3660 actually. It would be great to have as high resolution of an image as possible and delay/ performance is not a factor. Is JPEG the optimal format for resolution?

[WangYuxin-esp]

Is JPEG the optimal format for resolution?
->Yes. Data in jpeg format is compressed data. The sensor that can output jpeg directly sends a smaller amount of data to ESP32.

[github-actions]

This issue appears to be stale. Please close it if its no longer valid.