-
Notifications
You must be signed in to change notification settings - Fork 7.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ADC in continous mode STOPS when using FATFS (IDFGH-14463) #15237
Comments
Making this trick when there is a timeout, makes it run another hour, until FATFS is active again
|
is this code correct? ( |
Hi Safocl. I only use this interupt to detect, if incomming is 50 or 60Hz. It does not interfear with the ADC at all, except I set the sampling frequency to 40 or 48 KHz when initializing, in order to have same number of samples for a period (200 samples).
This also do not explain, why the error occurs, exactly every whole hour, when I run the FATFS task. Also at 14:00, 15:00, 16:00 etc. |
Here is a standalone code, ready for you to compile and run. It replicates the fault. As soon as the fasfs is called, the ADC have a TIMEOUT, and do not recover This is the log
Complete code to replicate
|
this variable is not changed from code. it always is
|
driver/timer.h is deprecated |
|
this code wait
|
You need to activate PSRAM in sdkconfig. |
I have simplified the code, the error persists. Log
code
|
Unless I made some stupid mistake, that I have overlooked, it seems to me, like FATFS is stopping the DMA and when the ADC buffer is empty, it goes into TIMEOUT, due to there is not comming data from the DMA anymore. |
Hmm, this is getting stranger and stranger.
SO what is the strange relationship between the filesize that I write with FATFS and the ADC_FRAME_SIZE ?? What is going on here?? AND not to forget. When I write, IT WORKS, I do not know, if it keeps working. Remember, in my original code, it works sometimes, and fails sometimes, even though both file size and frame_size if fixed. But in order to evaluate why this is, I need to understand, the relationship between FATFS and ADC. Notes: |
OK, I can now confirm, that even though it works immediately after modifications with no timeout, it fails over time, and goes into a timeout loop. |
|
maybe there's a memory overflow going on here -- or an error that you don't catch and continue the program? |
I do have test_file == NULL check in my real code. This is minimized code to reproduce the fault I am having. The only code running is the one you see here. Nothing else. I dont see any memory overflow anywhere. The system is running flawlessly for days, until I save a file using FATFS. Have you tried running the code? It should now be ready to run even without PSRAM. |
Adding this gives me nothing: esp_log_level_set("adc_continuous", ESP_LOG_VERBOSE); |
I do not even have to write anything into the file, this generates same error Does FATFS use DMA? I can not find any clear answers.
|
The error occurs when fclose is called - not fopen. |
the program continues to work even after an error, and further memory access will generate undefined behavior. |
the error is reached even before working with the file. |
Please try the latest much simpler code
|
my code do not reach to |
this is deprecated -- please don't use it for code... |
Please try the latest code I just sent, its much simpler. My partition.csv looks like this, there need to be a storage section
and I have this in my platformio.ini
|
I will make sure to exclude driver/timer.h in my real code, thank you. |
hmmm... qemu don't work with ADC? my hardware normally evaluates this code, but qemu don't (produce TIMEOUT ERROR)... |
my hardware is esp32 with 4Mib flash mem... |
If you use an emulator, do you then get data fra the ADC? I dont know.... Try this, since OTA is not in this simple example
|
this code on real esp32 (nodemcu-32) hardware do not produce ERROR |
I can't compile your code - it reports the error |
I'm disappointed with platformio -- it doesn't keep up with the times (library and toolchain updates) |
I have used Platformio for many years, but I do consider changing to espidf. Hm, strange. I just compiled this code below, and it produces this log:
|
@FrankBJensen deleting the code to use FAT produces normal execution? |
Yes. Then it runs for months. I have 7 products running my software. I only use FAT if I want to store statestics. I am only using FAT on 2 of these 7 units, the task with FAT is disabled on the 5 pcs.. And only the 2 units with FAT fails. The other 5 units never fail. One has been running more then 90 days. This is the reason why I began to investigate this error. And then suddenly I discovered, that the error occured exactly at a whole hour, eg. 14:00:00 or 15:00:00, and that is exactly the time, where I run my statestics task. Then I began pulling the code to bits and pieces, to find out, what caused this, ending up in me narrowing it down to the FAT save procedure. And this is where this thread started, and I copied my actual code snippets to a separate project, in order to better investigate, and have some real compilable code to post here. |
this code on my hardware reports panic error:
|
Strange. Can you see what line? I have no idea, what cache it talks about. At least you have Data OK now :-) |
You can change core to 1, and see if it moves with the adc_task:
|
maybe you need to add this to platformio.ini in order to see, what line causes the panic
|
i don't use pio... |
the last debug report:
|
What do this return (earlier in the code)? Is the filesystem mounted?
|
yes -- it is successfully |
That is strange. If I enable this logging below,
Then I get this log (and note, timeout just after write......)
|
So it fails here There must be something wrong with the mount or something....... You do have 4mb flash, and you dont adress more than that? Can you compile using my sdkconfig? Just in case, there is a setting somewhere with cache? |
my hardware is not ESP32-S3 -- but it is ESP32 |
OK. But the file system should work on any ESP32, I guess.... Do you have another project, where the filesystem is working? |
Googling, something like this keeps comming up:
Maybe try turning wear leveling OFF ? |
no |
I made a new file-only project from scratch. I made the partition 512K like you, and that gave me some problems, so I had to change sector and wear level size to 512 bytes, in order for it to mount successfully. Maybe you should try changing sector and wear level size to 512 bytes?? log
code
|
yes, i did it. |
ets Jul 29 2019 12:21:46
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:2
load:0x3fff0030,len:7112
load:0x40078000,len:15644
ho 0 tail 12 room 4
load:0x40080400,len:4
load:0x40080404,len:3860
entry 0x4008063c
[0;32mI (31) boot: ESP-IDF 46acfdce-dirty 2nd stage bootloader[0m
[0;32mI (31) boot: compile time Jan 22 2025 02:09:52[0m
[0;32mI (31) boot: Multicore bootloader[0m
[0;32mI (36) boot: chip revision: v3.1[0m
[0;32mI (40) boot.esp32: SPI Speed : 40MHz[0m
[0;32mI (45) boot.esp32: SPI Mode : DIO[0m
[0;32mI (49) boot.esp32: SPI Flash Size : 4MB[0m
[0;32mI (54) boot: Enabling RNG early entropy source...[0m
[0;32mI (59) boot: Partition Table:[0m
[0;32mI (63) boot: ## Label Usage Type ST Offset Length[0m
[0;32mI (70) boot: 0 nvs WiFi data 01 02 00009000 00006000[0m
[0;32mI (77) boot: 1 phy_init RF data 01 01 0000f000 00001000[0m
[0;32mI (85) boot: 2 factory factory app 00 00 00010000 00100000[0m
[0;32mI (92) boot: 3 storage Unknown data 01 81 00110000 00100000[0m
[0;32mI (100) boot: End of partition table[0m
[0;32mI (104) esp_image: segment 0: paddr=00010020 vaddr=3f400020 size=0ad54h ( 44372) map[0m
[0;32mI (128) esp_image: segment 1: paddr=0001ad7c vaddr=3ff80000 size=00018h ( 24) load[0m
[0;32mI (128) esp_image: segment 2: paddr=0001ad9c vaddr=3ffb0000 size=02374h ( 9076) load[0m
[0;32mI (137) esp_image: segment 3: paddr=0001d118 vaddr=40080000 size=02f00h ( 12032) load[0m
[0;32mI (147) esp_image: segment 4: paddr=00020020 vaddr=400d0020 size=247f0h (149488) map[0m
[0;32mI (202) esp_image: segment 5: paddr=00044818 vaddr=40082f00 size=0ddf4h ( 56820) load[0m
[0;32mI (232) boot: Loaded app from partition at offset 0x10000[0m
[0;32mI (232) boot: Disabling RNG early entropy source...[0m
I (244) cpu_start: Multicore app
I (253) cpu_start: Pro cpu start user code
I (253) cpu_start: cpu freq: 160000000 Hz
I (253) app_init: Application information:
I (253) app_init: Project name: test_issue
I (257) app_init: App version: 1
I (261) app_init: Compile time: Jan 22 2025 02:10:19
I (266) app_init: ELF file SHA256: 6bb8bab43...
I (270) app_init: ESP-IDF: 46acfdce-dirty
I (274) efuse_init: Min chip rev: v3.1
I (278) efuse_init: Max chip rev: v3.99
I (282) efuse_init: Chip rev: v3.1
I (286) heap_init: Initializing. RAM available for dynamic allocation:
I (293) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM
I (298) heap_init: At 3FFB2CF0 len 0002D310 (180 KiB): DRAM
I (303) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM
I (308) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (314) heap_init: At 40090CF4 len 0000F30C (60 KiB): IRAM
I (321) spi_flash: detected chip: generic
I (323) spi_flash: flash io: dio
I (327) main_task: Started on CPU0
I (337) main_task: Calling app_main()
I (3337) FATFS: FAT filesystem mounted
File opened
/fatfs/test.bin have been written, size: 10 1
|
OK, that seems to work. Based on that, I made this modified code. If you use same project, and paste this, then file should work. The fault with timeout still persists. Please try this Log
Code
|
Answers checklist.
IDF version.
5.3.0
Espressif SoC revision.
ESP32-S3-N16R8V
Operating System used.
Windows
How did you build your project?
VS Code IDE
If you are using Windows, please specify command line type.
None
Development Kit.
Custom board
Power Supply used.
External 3.3V
What is the expected behavior?
That the ADC keeps sampling continously
What is the actual behavior?
The ADC stops sampling with an TIMEOUT error, when I use FatFS to store a file.
Steps to reproduce.
When I run this below (around 11K totally is stored), the ADC goes into timeout, and never recovers. I have read about this problem under heavy load in 5.0.2, but has it been solved? I do have a heavy load, around 70% in the ADC task, and initially the task (not same task) that uses the filesystem was running on same core, but moving that task to the second core, did not make any difference.
Debug Logs.
More Information.
I tried to separate the 2 tasks on different cores - does not help.
I have tried to increase the ADC buffers, and funny enough, when the buffer is real big, like 10K, sometimes it surveives the filewrite, but ADC still stops most of the times
There is no overrun of the buffer
There is no memory leaks or nothing
I have changed my FATFS to write in bulks with a delay, to make sure there are time for the ADC task. The ADC task have hightst priority of all my tasks.
The task just keeps looping with ESP_ERR_TIMEOUT and do not recover
The text was updated successfully, but these errors were encountered: