ESP32运行6个并行无限任务触发Core0 LoadProhibited报错求解

首先明确异常本质：
LoadProhibited是Xtensa架构的内存访问错误，代表CPU尝试访问未映射、无访问权限的内存地址。你日志里的崩溃点在FreeRTOS的tick中断处理函数xTaskIncrementTick，但这个位置90%以上概率不是根因——从EXCVADDR: 0x80059309可以看到，访问的非法地址属于Flash代码映射区，说明是应用层代码踩内存，把FreeRTOS内核维护的任务就绪链表、任务控制块（TCB）指针改坏了，等到tick中断触发调度器遍历任务链表时，才访问到非法地址触发panic。

按以下优先级排查：

• 第一优先级排查任务栈溢出
  6个并发任务最常见的问题就是栈分配不足。注意xTaskCreate的栈大小单位是字（word），ESP32平台1字=4字节，很多人会误把单位当字节，导致实际分配的栈只有预期的1/4。
  排查操作：打开ESP-IDF配置菜单，把CONFIG_FREERTOS_CHECK_STACKOVERFLOW设置为强检测模式（CONFIG_FREERTOS_CHECK_STACKOVERFLOW_STRONG），复现问题时会直接打印出溢出的任务名，不会等到内核数据被踩坏才在调度器里崩溃。
  注意：任务中如果调用printf、浮点运算、WiFi/蓝牙协议栈API、使用大的局部数组，栈大小至少要分配3072字（12KB）以上，不要直接用configMINIMAL_STACK_SIZE跑业务任务。
• 排查任务逻辑是否饿死空闲任务
  所有无限循环任务的循环体内，必须添加带阻塞的FreeRTOS API调用，比如vTaskDelay()、带超时的队列/信号量等待，不能写纯CPU空转的死循环。如果6个任务优先级都高于空闲任务，且全程无阻塞，会直接饿死空闲任务，导致内核无法完成内存回收、看门狗喂狗等必要操作，最终触发内存结构损坏。
  错误示例：

  void bad_task(void *arg) {
    while(1) {
      // 无任何阻塞操作，占满CPU
      read_sensor();
      toggle_gpio();
    }
  }
  

  哪怕业务逻辑不需要延时，也至少加vTaskDelay(1)让出CPU时间片。
• 排查内存越界写问题
  如果开了栈溢出检测没报问题，就逐个检查所有任务的内存操作：
  • 局部数组是否存在写越界，比如定义长度10的数组，写入下标10及以上的位置
  • 是否存在野指针、访问已释放内存的操作
  • 中断服务函数里是否调用了不带FromISR后缀的FreeRTOS API
  • 多任务/中断同时访问同一个全局变量、外设、共享资源时，是否加了互斥锁保护
    这类踩内存问题的特征就是崩溃位置不固定，这次崩在tick处理函数，下次可能崩在memcpy、printf等完全不相关的位置，不要被表面崩溃点误导。
• 检查任务创建返回值
  不要调用xTaskCreate后默认任务创建成功，必须判断返回值是否为pdPASS。如果剩余SRAM不足，任务创建会失败，后续如果对空任务句柄做操作，会直接破坏内核内存结构。

快速验证技巧：先把6个任务的栈大小统一调到4096字（16KB），每个任务循环开头加vTaskDelay(10)，如果修改后异常消失，再逐个缩小栈大小、调整延迟时间，定位具体是哪个任务存在栈不足、无阻塞的问题。

内容的提问来源于stack exchange，提问作者preetjhota