杜

如果用了 CUBEMX 生成, 记得在 main 里先 HAL_Init 再配时钟，顺序反了也会出这种问题。

2026-11-04

在Cortex-M3/M4/M7上可用DWT->CYCCNT做周期级计时。移植步骤：1) 使能调试跟踪：CoreDebug->DEMCR |= CoreDebug_DEMCR_TRCENA_Msk；2) 清零并启动：DWT->CYCCNT=0; DWT->CTRL |= DWT_CTRL_CYCCNTENA_Msk；3) 读取前后差值delta，耗时=delta/SystemCoreClock（秒），纳秒=delta*1e9/SystemCoreClock。注意SystemCoreClock需为实际主频，必要时用HAL_RCC_GetHCLKFreq()刷新。溢出处理：CYCCNT为32位，最大2^32-1个周期，72MHz约59.6s、168MHz约25.6s，超过会回绕。用无符号减法uint32_t d=end-start天然处理单次回绕；若测量可能跨多次回绕，需在中断或轮询中累计高位，或用64位软件扩展。建议测量前后关中断或保证被测时间远小于回绕周期，并避免在低功耗停时钟场景使用。

2026-11-03

在FreeRTOS中，vTaskDelayUntil用于固定周期任务，它基于上一次唤醒时间计算绝对延迟；而vTaskDelay是相对延迟，从调用时刻开始计时。混用会导致周期漂移：例如任务本应每10ms运行一次，但若在周期任务中交替使用两者，vTaskDelay的调用会引入额外延迟（如任务执行时间），使下一次vTaskDelayUntil的基准时间被推后，累积误差。排查时，首先检查任务代码中是否同时出现两个API；其次用GPIO翻转或示波器测量任务实际周期，对比预期；最后统一使用vTaskDelayUntil并确保传入的PreviousWakeTime变量正确初始化且仅在该任务中修改。若需动态调整周期，应重新计算基准时间或使用软件定时器。

2026-11-02

ESP32双核跑FreeRTOS，任务分配核心是xTaskCreatePinnedToCore的xCoreID参数：0为PRO_CPU，1为APP_CPU，tskNO_AFFINITY表示不绑定。实战坑点：1）Arduino框架下loopTask默认跑在Core1，WiFi/BT协议栈任务也在Core1，若把高实时任务也放Core1会与协议栈抢CPU，建议实时控制放Core0、网络放Core1；2）vTaskDelay(0)不会让出CPU，需用vTaskDelay(1)或taskYIELD；3）跨核共享变量必须用临界区portENTER_CRITICAL或原子操作，普通volatile不够；4）Core0上跑死循环且不开看门狗会触发TWDT，需vTaskDelay喂狗；5）用uxTaskGetStackHighWaterMark监控栈，双核下栈溢出更隐蔽。建议用xTaskCreatePinnedToCore显式绑定，配合uxTaskPriorityGet和vTaskPrioritySet动态调优，并用esp_timer或逻辑分析仪验证任务实际调度周期。

2026-11-02

STM32硬件I2C从机模式下，时钟延展（Clock Stretching）导致主机读超时，常见原因是从机在SCL低电平期间未及时释放总线。排查步骤：1）用逻辑分析仪抓取SCL/SDA波形，确认从机是否在ACK后拉低SCL超过主机超时时间；2）检查从机中断优先级，若I2C中断被高优先级任务阻塞，会导致延展超时；3）确认从机在发送数据前是否已正确设置I2C_CR2的NACK/ACK及数据寄存器。修复建议：1）提高I2C中断优先级，确保及时响应；2）在从机发送数据时，避免在中断内执行耗时操作；3）若主机不支持长延展，可缩短从机延展时间，例如在I2C中断中尽快写入DR寄存器；4）检查硬件上拉电阻是否合适，避免上升沿过慢导致误判。若问题依旧，可尝试关闭从机时钟延展功能（若主机支持），或改用DMA方式减少中断延迟。

2026-11-01

TWDT误触发在ESP32双核下常见根因是：TWDT默认监控两个核心的IDLE任务，而IDLE任务优先级为0，任何高优先级任务长期占用CPU（如忙等、长临界区、关中断过久）都会让对应核心的IDLE得不到调度，从而触发TWDT。排查步骤：1) 用esp_task_wdt_status()确认被监控任务；2) 检查是否有任务在while(1)中不阻塞；3) 检查portENTER_CRITICAL或taskENTER_CRITICAL区是否过长；4) 检查是否在中断中长时间关中断。配置建议：在menuconfig中开启CONFIG_ESP_TASK_WDT_CHECK_IDLE_TASK_CPU0/CPU1，按需只监控一个核心；对确实需要长时间运行的任务，用esp_task_wdt_add()注册并周期性esp_task_wdt_reset()，但不要在IDLE钩子里喂狗——IDLE钩子本身就在IDLE上下文运行，喂狗会掩盖CPU饥饿问题。更推荐用esp_task_wdt_init()设置合理超时（如5-10s），并配合任务设计保证每个核心都有阻塞点让IDLE运行。若使用vTaskDelay或阻塞式API，IDLE自然获得调度，无需额外喂狗。

2026-10-31

先明确机理：EXTI 边沿检测器锁存 PR 位后，经与 IMR/EMR 相与送 NVIC 挂起。若 ISR 中只清 NVIC 挂起而未清 EXTI->PR，退出后 PR 仍为 1，会再次触发；反之若在中断入口前有抖动或电平持续满足，也会重复进入。排查路径：1) 在 ISR 首行读 EXTI->PR，确认哪一位置位，并检查是否在清除前又发生新边沿；2) 标准写法是先清 EXTI->PR（写 1 清除），再执行用户逻辑，必要时在清 PR 后短暂关中断或加软件消抖；3) 检查 GPIO 配置是否为浮空/上拉，信号源是否有振铃，示波器看边沿；4) 确认 NVIC 优先级与抢占配置，避免高优先级中断延迟导致多次挂起合并；5) 若用 HAL，确认 HAL_GPIO_EXTI_IRQHandler 内已清 PR，且用户回调未重复调用；6) 检查是否误开双边沿触发（RTSR/FTSR 同时置位）。最后用调试器在 ISR 入口计数并观察 PR 变化定位。

2026-10-30

ESP32的WiFi协议栈默认绑定在CPU0，且其任务优先级较高，用户任务若也放在CPU0且长时间不让出CPU，会阻塞IDLE任务喂狗，触发任务看门狗（TWDT）或中断看门狗复位。核心策略是：1）将用户计算密集型任务用xTaskCreatePinnedToCore固定到CPU1，CPU0只保留WiFi、LWIP和必要的轻量任务；2）确保每个任务循环内有阻塞点（vTaskDelay、队列等待、信号量），避免死循环独占；3）适当提高看门狗超时或对长任务调用esp_task_wdt_reset()，但不要滥用；4）检查configTASK_WDT相关配置，确认IDLE任务能运行；5）用uxTaskGetStackHighWaterMark和vTaskGetRunTimeStats监控CPU占用。若必须用CPU0，降低任务优先级并主动让出。

2026-10-30

ESP32-S3 双核调优的核心是：把 Wi-Fi 协议栈固定在 Core0，把应用任务按实时性分到 Core1，并让 Wi-Fi 任务优先级高于普通应用任务。具体做法：1) 创建应用任务时用 xTaskCreatePinnedToCore 显式绑定核心，实时控制/采样任务绑 Core1，优先级设为 5~10；2) Wi-Fi 协议栈任务由 IDF 内部创建，通常运行在 Core0，优先级较高（约 23），不要试图降低它，而是避免在 Core0 上放长耗时任务；3) 把日志、文件、网络收发等阻塞型任务放 Core0 低优先级（1~3），利用阻塞让出 CPU；4) 关键临界区用互斥量而非长时间关中断，避免影响 Wi-Fi 时隙；5) 用 vTaskPrioritySet 动态提升突发任务优先级，配合队列/信号量做事件驱动。验证时用 esp_timer 打点统计任务切换和 Wi-Fi 丢包率，若 Core0 空闲率低于 20% 需拆分任务。注意双核共享缓存和内存带宽，避免两核同时高负载访问 PSRAM。

2026-10-29

核心思路：用PWM输入模式（从模式复位+双通道捕获）。配置：TIMx_CH1接PWM信号，CH1边沿捕获上升沿，CH2（同一引脚映射到TI1）捕获下降沿；从模式选择Reset Mode，触发源选TI1FP1。这样每次上升沿到来时，硬件自动复位CNT，CH1捕获周期值（CCR1），CH2捕获高电平时间（CCR2），占空比=CCR2/CCR1。关键配置：两通道都设为输入捕获、预分频一致；IC1映射TI1，IC2映射TI1（非TI2），极性分别为上升/下降；从模式SMS=100（复位模式），TS=101（TI1FP1）。使能CC1IE/CC2IE，在中断里读CCR1、CCR2即可，CPU占用极低。精度取决于定时器时钟和捕获分辨率，建议定时器时钟尽量高、ARR设最大，避免溢出。注意输入滤波ICF和预分频要匹配信号频率。

2026-10-23