电

{"answer":"根因：HAL_Delay基于SysTick中断维护的uwTick全局变量做忙等，其内部循环依赖SysTick中断持续递增uwTick。当在中断上下文中调用时，若该中断优先级高于或等于SysTick（通常SysTick为最低优先级），SysTick中断无法抢占当前ISR，uwTick不再更新，HAL_Delay陷入永久等待，形成死锁；即使优先级允许抢占，长延时也会严重阻塞中断响应。此外HAL_Delay内部未做重入保护，多上下文调用存在竞态。替代方案：1) 中断中绝对禁止阻塞延时，改用状态机+时间戳非阻塞方式，在主循环中判断超时；2) 需要短延时时使用DWT周期计数器或硬件定时器做忙等，不依赖SysTick；3) 用独立硬件定时器产生单次中断或标志位实现异步延时；4) 若必须同步等待，可临时提升SysTick优先级（不推荐，破坏实时性）。实操建议：代码审查中禁止在ISR及回调中调用HAL_Delay，用静态分析或宏重定义在调试版中拦截。","extras":[{"content":"本质是优先级反转：SysTick被高优先级ISR屏蔽，uwTick冻结。建议在FreeRTOS下用vTaskDelay或xTaskGetTickCount，中断里只置标志。","author":"嵌入式老张"},{"content":"可把HAL_Delay替换为基于DWT->CYCCNT的忙等，精度高且不依赖中断，但仅适合微秒级短延时，长延时仍应状态机化。","author":" CortexM小兵"},{"content":"调试时可在HAL_Delay入口加断言检查IPSR寄存器非零即报错，快速定位ISR误用，比事后排查死锁高效。","author":"硬件萌新"}],}

2026-11-03

HAL_Delay依赖SysTick中断递增的uwTick，并在循环中等待uwTick差值。若在中断上下文中调用，且当前中断优先级高于或等于SysTick优先级，SysTick中断无法抢占，uwTick不再更新，HAL_Delay会永久阻塞，导致死锁或看门狗复位。即使SysTick优先级更高，HAL_Delay在ISR中忙等也会拉长中断响应时间，破坏实时性。实操建议：绝不在ISR中调用HAL_Delay；需要短延时用DWT周期计数器或NOP循环，需要定时用硬件定时器或状态机；若必须用tick，确保SysTick为最高优先级并改用非阻塞的HAL_GetTick差值判断，但ISR中仍不推荐忙等。

2026-11-02

HAL_Delay依赖SysTick中断递增的uwTick，并在while中等待uwTick差值达到延时值。若在中断上下文中调用，且该中断优先级不低于SysTick（或SysTick被屏蔽），SysTick中断无法抢占执行，uwTick不再更新，循环永不退出，形成死等。即使优先级允许抢占，长时间忙等也会破坏实时性。推荐用DWT周期计数器实现无阻塞微秒延时：使能DWT，CoreDebug->DEMCR |= CoreDebug_DEMCR_TRCENA_Msk；DWT->CYCCNT=0；DWT->CTRL |= DWT_CTRL_CYCCNTENA_Msk。延时函数读取起始CYCCNT，按SystemCoreClock换算目标周期数，循环等待(CYCCNT-start)>=ticks。注意CYCCNT为32位，在168MHz下约25.5秒回绕，需用无符号差值比较；DWT一般仅Cortex-M3/M4/M7支持，M0无此功能。该方式不依赖中断，可在中断中安全使用，但仍是忙等，超长延时建议用定时器。

2026-11-01

补充一点：ADC任务里不要调用任何WiFi相关API，WiFi回调里也不要直接操作ADC，全部通过队列解耦，避免核间死锁。

2026-11-01

建议将ADC采样任务固定在Core 1，WiFi上传任务固定在Core 0（WiFi协议栈默认运行在Core 0，避免跨核抢占）。ADC任务优先级设为5~6，WiFi任务设为3~4，确保采样实时性。核间同步不要用忙等或全局变量轮询，推荐使用FreeRTOS队列：ADC任务以固定周期（如1kHz）采样，将数据打包成结构体通过xQueueSend发送到深度8~16的队列；WiFi任务用xQueueReceive阻塞等待，攒批后上传。若需严格节拍，ADC任务用vTaskDelayUntil保证周期稳定。注意ADC连续采样时避免在WiFi任务中调用阻塞式API影响采样；共享缓冲区用队列或双缓冲+信号量保护。栈大小：ADC任务2048字节，WiFi任务4096字节以上。优先级不要高于configMAX_PRIORITIES-1，且WiFi任务不宜设得过高以免饿死采样。

2026-11-01

别在idle钩子里喂狗，那等于把看门狗废了。正确做法是让高优先级任务有阻塞点，或单独建低优先级喂狗任务。

2026-10-31

ESP32双核下WiFi协议栈访问SPI Flash时会禁用Cache，此时若另一核执行Flash内代码或访问映射数据，会触发Cache访问异常或总线冲突。规避要点：1) 将ISR及被中断路径调用的函数用IRAM_ATTR放入IRAM，确保Cache禁用窗口内仍可执行；2) 对共享外设/总线操作使用portENTER_CRITICAL_ISR/portEXIT_CRITICAL_ISR或自旋锁（portMUX_TYPE）保护，临界区代码必须位于IRAM，且尽量短；3) 避免在临界区或ISR中调用printf、malloc、Flash常量字符串等；4) 用xTaskCreatePinnedToCore把WiFi任务与实时任务分核，减少同核抢占；5) 通过esp_int_wdt与Cache禁用API（spi_flash_disable_interrupts_caches_and_other_cpu）理解窗口，必要时用IRAM安全API。注意IRAM_ATTR只解决代码位置，不替代同步，临界区需配合自旋锁保证双核互斥。

2026-10-28

先确认时钟延展是否真的发生：用逻辑分析仪抓SCL，看从机在ADDR/TXE/RXNE等事件后是否拉低SCL超过主机超时阈值。常见根因有三类：1) 从机中断优先级过低或被长临界区阻塞，导致TXE/RXNE未及时响应而硬件自动拉低SCL；2) 从机在ADDR匹配后未及时写DR（发送方向）或读DR（接收方向），STM32 I2C外设会保持SCL低；3) 主机侧超时设置过短（如HAL的I2C_TIMEOUT仅几ms）。规避建议：把I2C从机中断设为较高优先级，缩短临界区，避免在中断中做耗时操作；发送方向提前把数据写入DR或使用DMA；接收方向保证每字节及时读走；主机侧适当增大超时并实现总线恢复（9个时钟脉冲+STOP）。若主机不支持时钟延展，则从机侧必须保证响应延迟小于主机超时，必要时改用软件模拟从机或降低速率。

2026-10-28

根因是HAL_Delay依赖SysTick中断递增的全局变量uwTick，并通过HAL_IncTick在SysTick_Handler中更新。若在中断上下文调用HAL_Delay，而当前中断优先级不低于SysTick（通常SysTick为最低优先级），SysTick中断无法抢占，uwTick不再递增，HAL_Delay会死等超时。即使优先级允许，长时间忙等也会阻塞其他中断，破坏实时性。替代方案：1) 短延时用DWT周期计数器忙等，如DWT->CYCCNT，需先使能DWT；2) 用硬件定时器做单次延时或状态机，避免阻塞；3) 中断中只置标志/发信号，把延时逻辑放到主循环或RTOS任务，用vTaskDelay或软件定时器；4) 若必须阻塞，用__NOP循环校准的忙等，但需评估中断延迟。注意不要在中断里调用带互斥的HAL函数。

2026-10-28

核心思路是让DMA双缓冲的HT/TC中断只负责"搬运数据到软件缓冲区"，而IDLE中断负责"判定一帧结束"，两者通过原子操作共享状态，避免在HT/TC里直接处理协议。具体做法：1）DMA配置为循环模式双缓冲，HT和TC中断里只更新一个volatile的写指针/计数，用__disable_irq()或LDREX/STREX保护临界区，把当前半缓冲区长度和序号记录到环形队列；2）IDLE中断到来时，先读DMA剩余计数NDTR并结合当前活动缓冲区计算出本帧实际字节数，再把HT/TC已登记的数据拼接成完整帧；3）关键是把"帧结束判定"和"数据搬运"解耦：HT/TC只做无锁入队，IDLE只做帧边界标记，消费端在任务里按标记取帧；4）若帧长可能跨越HT边界，需在IDLE处理中检查是否有未消费的半缓冲数据，避免把一帧拆成两段；5）最后清IDLE标志前先读SR再读DR，防止清错标志。这样可消除HT与IDLE同时触发时的丢包。

2026-10-27