Closed higaski closed 9 months ago
The backtrace shows the rmt_encode_check_result
is accessing a function or data that is not in the internal RAM. I highly suspect this is caused by your customized encoding function and the encoder object is not in the internal RAM.
For example, here, this object will be malloc from PSRAM because you set the Kconfig CONFIG_SPIRAM_MALLOC_ALWAYSINTERNAL
Thank you that has been the issue yes.
Maybe the following snippet (from rmt_private.h
) should be made visible so that custom encoders can use it?
#if CONFIG_RMT_ISR_IRAM_SAFE || CONFIG_RMT_RECV_FUNC_IN_IRAM
#define RMT_MEM_ALLOC_CAPS (MALLOC_CAP_INTERNAL | MALLOC_CAP_8BIT)
#else
#define RMT_MEM_ALLOC_CAPS MALLOC_CAP_DEFAULT
#endif
Answers checklist.
IDF version.
ESP-IDF v5.2-beta1 (&ESP-IDF v5.3-dev-1353-gb3f7e2c8a4)
Espressif SoC revision.
ESP32-S3 (QFN56) (revision v0.1)
Operating System used.
Linux
How did you build your project?
Command line with idf.py
If you are using Windows, please specify command line type.
None
Development Kit.
ESP32-S3-DevKitC-1
Power Supply used.
USB
What is the expected behavior?
I've written a custom RMT encoder which triggers a core panic during SPIFFS access and I don't have the slightest idea why. I've had my fair share of "flash access during IRAM interrupt panics" (see #12271) but this one completely escapes me.
Since the RMT encoder alone is about 500 lines and can't really be shortened, here is the entire project folder: esp_idf_issue_13032.zip
Or here on GH: https://github.com/higaski/esp_idf_issue_13032
The entire example is basically an adapted version of the one I've already once linked in #12271.
What is the actual behavior?
For some reason there is a core panic exception once SPIFFS get accessed while RMT transmissions are running.
Steps to reproduce.
Debug Logs.
More Information.
No response