Using FatFs directly fails with a Guru Meditation Error

balix53
Posts: 19
Joined: Mon Jan 21, 2019 8:47 am

Using FatFs directly fails with a Guru Meditation Error

Postby balix53 » Thu Jan 07, 2021 3:51 pm

Hi,

I am developing an application with FS features and it uses directly FatFs API for FS operations. At some point I got crashes with the FS in SD card, I have tested FS in flash to see if there was any difference and it worked as expected.

So I went back to the basic example for SD card on the Github repository: https://github.com/espressif/esp-idf/tr ... ge/sd_card

(Note that I use IDF version 3.3.4)

The example works fine but I am required to use the FatFs API so I switched from POSIX to see if the example was working.

I only tried to change the file creation with the following code:

Code: Select all

	
	// First create a file.
	ESP_LOGI(TAG, "Opening file");
	FIL file;
	FRESULT res;
	res = f_open(&file, "/sdcard/hello.txt", FA_CREATE_ALWAYS);
	if (FR_OK != res) {
		ESP_LOGE(TAG, "Failed to open file for writing, result=%d", res);
		return;
	}
	ESP_LOGI(TAG, "File opened");
But I got a Guru Meditation:
I (0) cpu_start: App cpu up.
I (262) heap_init: Initializing. RAM available for dynamic allocation:
I (269) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM
I (275) heap_init: At 3FFB3008 len 0002CFF8 (179 KiB): DRAM
I (281) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM
I (287) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (294) heap_init: At 40089100 len 00016F00 (91 KiB): IRAM
I (300) cpu_start: Pro cpu start user code
I (318) cpu_start: Starting scheduler on PRO CPU.
I (0) cpu_start: Starting scheduler on APP CPU.
I (320) example: Initializing SD card
I (320) example: Using SDMMC peripheral
***ERROR*** A stack overfloGuru Meditation Error: Core 1 panic'ed (LoadProhibited). Exception was unhandled.
Core 1 register dump:
PC : 0x4008652c PS : 0x00060633 A0 : 0x800865ca A1 : 0x3ffb5ce0
0x4008652c: prvCheckTasksWaitingTermination at C:/Tools/msys32/home/balix/esp-idf/components/freertos/tasks.c:4560

A2 : 0x00000000 A3 : 0x00000001 A4 : 0x00000001 A5 : 0x00000001
A6 : 0x00060021 A7 : 0x00000000 A8 : 0x80086516 A9 : 0x3ffb5cc0
A10 : 0x3ffb3ca0 A11 : 0x00000000 A12 : 0x00000000 A13 : 0x00000001
A14 : 0x00000003 A15 : 0x00060023 SAR : 0x00000000 EXCCAUSE: 0x0000001c
EXCVADDR: 0x00000048 LBEG : 0x00000000 LEND : 0x00000000 LCOUNT : 0x00000000

ELF file SHA256: 5bdc9160105c94bf

Backtrace: 0x4008652c:0x3ffb5ce0 0x400865c7:0x3ffb5d00 0x40084d21:0x3ffb5d20
0x4008652c: prvCheckTasksWaitingTermination at C:/Tools/msys32/home/balix/esp-idf/components/freertos/tasks.c:4560

0x400865c7: prvIdleTask at C:/Tools/msys32/home/balix/esp-idf/components/freertos/tasks.c:4560

0x40084d21: vPortTaskWrapper at C:/Tools/msys32/home/balix/esp-idf/components/freertos/port.c:403


CPU halted.
So my questions are:

- Is there something wrong in my code? The backtrace only points to FreeRTOS task code.

- In general are there any recommendations when using directly FatFs API? Even though this is supported I have the impression that no one really use the FS like this on ESP32.

The original issue I was investigating had the following backtrace:
C:/Users/balix/ESP32-WROVER/esp-idf/components/freertos/queue.c:1442 (xQueueGenericReceive)- assert failed!
abort() was called at PC 0x4008931d on core 0
0x4008931d: xQueueGenericReceive at C:/Users/balix/ESP32-WROVER/esp-idf/components/freertos/queue.c:2038


ELF file SHA256: f3472044f1e23acb

Backtrace: 0x400880dd:0x3ffc9bc0 0x4008836d:0x3ffc9be0 0x4008931d:0x3ffc9c00 0x400fa2e2:0x3ffc9c40 0x40100511:0x3ffc9c90 0x400f7aa8:0x3ffc9cb0 0x400f7b23:0x3ffc9d20 0x400fb63d:0x3ffc9d50 0x400fb526:0x3ffc9d70 0x400fb921:0x3ffc9d90 0x400fb9

51:0x3ffc9db0 0x400fba6d:0x3ffc9dd0 0x400fd9a9:0x3ffc9e10 0x400f57b1:0x3ffc9e80 0x400f5ec6:0x3ffc9ea0
0x400880dd: invoke_abort at C:/Users/balix/ESP32-WROVER/esp-idf/components/esp32/panic.c:715

0x4008836d: abort at C:/Users/balix/ESP32-WROVER/esp-idf/components/esp32/panic.c:715

0x4008931d: xQueueGenericReceive at C:/Users/balix/ESP32-WROVER/esp-idf/components/freertos/queue.c:2038

0x400fa2e2: sdmmc_host_do_transaction at C:/Users/balix/ESP32-WROVER/esp-idf/components/driver/sdmmc_transaction.c:119

0x40100511: sdmmc_send_cmd at C:/Users/balix/ESP32-WROVER/esp-idf/components/sdmmc/sdmmc_cmd.c:34

0x400f7aa8: sdmmc_read_sectors_dma at C:/Users/balix/ESP32-WROVER/esp-idf/components/sdmmc/sdmmc_cmd.c:495

0x400f7b23: sdmmc_read_sectors at C:/Users/balix/ESP32-WROVER/esp-idf/components/sdmmc/sdmmc_cmd.c:447

0x400fb63d: ff_sdmmc_read at C:/Users/balix/ESP32-WROVER/esp-idf/components/fatfs/src/diskio_sdmmc.c:39

0x400fb526: ff_disk_read at C:/Users/balix/ESP32-WROVER/esp-idf/components/fatfs/src/diskio.c:69

0x400fb921: move_window at C:/Users/balix/ESP32-WROVER/esp-idf/components/fatfs/src/ff.c:4710

0x400fb951: check_fs at C:/Users/balix/ESP32-WROVER/esp-idf/components/fatfs/src/ff.c:4710

0x400fba6d: find_volume at C:/Users/balix/ESP32-WROVER/esp-idf/components/fatfs/src/ff.c:4710

0x400fd9a9: f_stat at C:/Users/balix/ESP32-WROVER/esp-idf/components/fatfs/src/ff.c:4710
So to me there seems to be something wrong maybe between FreeRTOS and the SD device driver.

But first I would like to know what I did wrong with the example, maybe it will help me understand this.

Thanks,

Benjamin

PS: I am using the ESP32 WROVER kit and since some of the JTAG and SD pins are shared, I cannot run gdb to investigate.

chegewara
Posts: 1388
Joined: Wed Jun 14, 2017 9:00 pm

Re: Using FatFs directly fails with a Guru Meditation Error

Postby chegewara » Thu Jan 07, 2021 5:51 pm

balix53 wrote:***ERROR*** A stack overfloGuru
You have to find out which task is short on stack, that probably will solve guru meditation crash.

balix53
Posts: 19
Joined: Mon Jan 21, 2019 8:47 am

Re: Using FatFs directly fails with a Guru Meditation Error

Postby balix53 » Fri Jan 08, 2021 9:00 am

Yes thanks that was it ! I had to raise the main task stack size to get it to run. Also my path was wrong, I replaced "/sdcard/hello.txt" by "hello.txt".

I will continue to adapt the POSIX example to find out if that works but is there anyway that my original issue could be related to a memory issue? As far as I can tell I did not see any log about a stack overflow.

chegewara
Posts: 1388
Joined: Wed Jun 14, 2017 9:00 pm

Re: Using FatFs directly fails with a Guru Meditation Error

Postby chegewara » Fri Jan 08, 2021 9:19 am

balix53 wrote: As far as I can tell I did not see any log about a stack overflow.
It is in there, just it is a bit masked because of guru:
balix53 wrote: I (320) example: Using SDMMC peripheral
***ERROR*** A stack overfloGuru Meditation Error: Core 1 panic'ed (LoadProhibited). Exception was unhandled. <--- STACK OVERFLOW
Core 1 register dump:
BTW posix works pretty good with esp32; i am working on project where i have foreign code imported from linux, its working with just a few small changes

balix53
Posts: 19
Joined: Mon Jan 21, 2019 8:47 am

Re: Using FatFs directly fails with a Guru Meditation Error

Postby balix53 » Fri Jan 08, 2021 2:19 pm

I was talking about the other project I work on (last trace in my first post).
chegewara wrote: BTW posix works pretty good with esp32; i am working on project where i have foreign code imported from linux, its working with just a few small changes
Good to know! Just by curiosity do you remember these changes?

chegewara
Posts: 1388
Joined: Wed Jun 14, 2017 9:00 pm

Re: Using FatFs directly fails with a Guru Meditation Error

Postby chegewara » Sat Jan 09, 2021 7:10 am

Some oflags does not exist in esp32 for fopen, dont remember which one, and few functions like posix_fallocate does not exist.

Who is online

Users browsing this forum: No registered users and 59 guests