Interrupt causes panic on Core0

[bdring]

I have a timer interrupt that causes a "Guru Meditation Error: Core 0 panic'ed (Interrupt wdt timeout on CPU0)
"..... Core 0 was running in ISR context:

I am trying to port the Grbl CNC firmware to ESP32. The timer is used to handle step pulse timing. The steps can occur at more than 30kHz. I can get the firmware working using high priority tasks and semaphores , but that limits my speed to the RTOS frequency. Therefore, I believe I need to use interrupts. The code in the interrupt should take less than 10usec. It only takes about 30usec on and Arduino UNO. The code is too big to post here, but I could upload it to GitHub.

I have read dozens of topics related to this, but nothing seems to fix it. I want to use the Arduino IDE to make the code more accessible to average users. I have updated my esp32 files from github within the last week.

1. Does this mean the interrupt was running on Core0. Is that the case for Arduino IDE generated code? I thought it ran on Core1.
2. Can the ESP32 run fast and deterministic code like this
3. Can someone explain how interrupts interact with cores and freertos?
4. Are there any sdkconfig options that might help? What is the best way to manage those options in the Arduino IDE? Do I just edit sdkconfig or sdkconfig.h. Is there a way to manage that on a per project basis?

Thanks for any help you give.

Bart

[kolban]

Howdy Bart and welcome to the forum. Unfortunately experience tells me that there are commonly not quick answers to broad questions. What I would suggest is if you want fresh eyes to look at a puzzle, reduce the puzzle to its barest essence that is the absolute minimum amount of code necessary to recreate the same problem.

When an exception occurs, it is usually a good thing to try and find the exact line that the exception occurs at. Also, is the problem "deterministic" ... meaning does it happen the same way each time you run your app. While never impossible, it is not that likely that by mentioning the software you are porting (Grbl CNC) that readers will know what that means. Unless one is super strong (and that would rule me out) porting black box code from one platform to another without understanding the original code can be very tricky.

[bdring]

Thanks for the reply.

I found the problem was due to a rmt_write_items(...) statement in the interrupt. It would always execute the first time through the interrupt and then fail the second time through. Replacing it with bit banging works. Do you know of any issues with the RMT in interrupts? My RMT should be super fast. Here is the config.

step_x_config.rmt_mode = RMT_MODE_TX;
step_x_config.channel = RMT_CHANNEL_0;
step_x_config.gpio_num = X_STEP_PIN;
step_x_config.mem_block_num = 1;
step_x_config.tx_config.loop_en = 0;
step_x_config.tx_config.carrier_en = 0;
step_x_config.tx_config.idle_output_en = 1;
step_x_config.tx_config.idle_level = RMT_IDLE_LEVEL_LOW;
step_x_config.tx_config.carrier_level = RMT_CARRIER_LEVEL_HIGH;
step_x_config.clk_div = 80; // 80MHx / 80 = 1MHz 0r 1uS per count

rmt_config(&step_x_config);
rmt_driver_install(step_x_config.channel, 0, 0); // rmt_driver_install(rmt_channel_t channel, size_t rx_buf_size, int rmt_intr_num)

rmt_items[0].duration0 = 3;
rmt_items[0].level0 = 1;
rmt_items[0].duration1 = 0;
rmt_items[0].level1 = 0;

I wrote 2 blog posts about what I am trying to do.

http://www.buildlog.net/blog/2017/11/es ... th-timers/
http://www.buildlog.net/blog/2017/11/es ... h-the-rmt/

[ESP_Dazz]

rmt_write_items() internally calls xSemaphoreTake() which is not ISR safe. I suggest you defer calling of rmt_write_items() to a task instead.