Panic: Cache disabled but cached memory region accessed in v3.6.6 #794
Comments
|
The I looked up the PC address |
|
We have some info on using the backtrace here. http://wiki.fluidnc.com/en/installation#backtrace-decoding-windows |
|
Thanks, that helped a bit, but I still got nothing that makes sense.
My findings so far: |
|
"Cache disabled but cached memory region accessed" usually means that the ESP32 is trying to fill its instruction cache from FLASH in an interrupt service routine. We try to mark all ISR code with IRAM_ATTR so it runs from instruction RAM and does not need to access FLASH, but the C++ compiler makes that difficult. Both switch statements and virtual methods generate code fragments that land in FLASH, regardless of IRAM_ATTR on their enclosing functions. We have a linker-script workaround for that but sometimes we miss something. The backtrace is often fairly useless for debugging this situation. I will try to repro the problem and see if I can find out what we missed. |
|
Please supply a GCode file that panics. Also tell us what sender you are using - WebUI, UGS, or whatever. If you are using a serial sender, is WebUI also connected? How long does it take before the panic happens? I know that it is unlikely to be deterministic, but is it a few minutes, or hours, or what? |
|
I've been streaming with UGS over serial, with the WebUI opened in background. The panic happens within 5 to 40 minutes. I was unable to replicate the problem while streaming from SD (command issued in Fluidterm) without the browser UI opened. |
|
Is WebUI using auto-reporting or polling? |
|
Ouch. __digitalWrite is in FLASH. That is a huge problem because it is used by the stepper interrupt, and it could be displaced from icache and then refilled during an ISR. |
|
Foiled again by the Arduino Framework: framework-arduinoespressif32/cores/esp32/esp-hal-gpio.c: extern void ARDUINO_ISR_ATTR __digitalWrite(uint8_t pin, uint8_t val)
{
gpio_set_level((gpio_num_t)pin, val);
}framework-arduinoespressif32/cores/esp32/esp-hal.h: #if CONFIG_ARDUINO_ISR_IRAM
#define ARDUINO_ISR_ATTR IRAM_ATTR
#define ARDUINO_ISR_FLAG ESP_INTR_FLAG_IRAM
#else
#define ARDUINO_ISR_ATTR
#define ARDUINO_ISR_FLAG (0)
#endifframework-arduinoespressif32/tools/sdk/esp32/sdkconfig: |
Auto-reporting, 50ms. Food for thought: while researching the issue, I came upon a post that suggested the following:
Would that work? |
|
I may have fixed it. Re your suggestion: The step timing code in the GPIO case is too critical, by far, to do in a task. In the I2SO case, it already works that way. |
|
Hey, I just saw the PR. Thanks for the quick response. Tomorrow I'll try to reproduce with and without that patch. |
|
For the record, linking to results of the test: #796 (comment) |
Fix #794 - change Arduino __digital* to gpio_* in IRAM
|
Fixed in |
Controller Board
FYSETC E4
Machine Description
Modded 3018
Input Circuits
No response
Configuration file
Startup Messages
What happened?
While running gcode, the controller randomly panics:
Other Information
No response
The text was updated successfully, but these errors were encountered: