STM32F103C8T6 USB CDC 在 72MHz 下停止模式唤醒后断开（HSE 8MHz）—— 求助

技术讨论 嵌入式系统 / Embedded Systems
, , ,
1

大家好，

我正在调试 STM32F103C8T6 开发板上一个间歇性的 USB CDC 问题。从停止模式唤醒后，电脑有时会丢失虚拟串口（除非硬复位，否则不会重新枚举）。希望大家能帮忙检查我的时钟 / USB 初始化序列是否合理，以及是否有经过验证的解决方案。

硬件及器件

  • MCU：STM32F103C8T6，基于 8MHz HSE 通过 PLL 倍频 9 倍运行在 72MHz。
  • 开发板：“小蓝板”（Blue Pill）版型；LDO 将 5V 转为 3.3V，VDD 引脚附近配备 0.1µF+1µF 去耦电容，8MHz HC-49 晶振搭配 22pF 负载电容。
  • USB：全速设备，D + 通过 1.5kΩ 电阻上拉至 3.3V；D+/D - 线路串联 22Ω 电阻。

故障现象

  • 首次上电：USB CDC 在 Windows 10 和 Ubuntu 22 系统上均能正常枚举。
  • 进入停止模式约 5-30 秒后唤醒，主机有时无法识别 CDC 设备（无新的 PID/VID 事件，串口消失）。插拔 USB 线不一定有效，按下 NRST 复位引脚总能恢复。复现率约 10%-30%。

已尝试的操作

  1. 停止模式唤醒后，重新使能 HSE/PLL，再重启 USB 时钟。
  2. 切换 USB 外设时钟，并执行 USBD_DeInit ()→USBD_Init () 序列。
  3. 时钟切换后确保调用 SystemCoreClockUpdate () 函数。
  4. 在 RCC 和 USB 初始化步骤之间延长 1-10ms 延时。
  5. 用示波器检测 3.3V 电源纹波：唤醒期间纹波 < 20mVpp；D + 空闲状态约 3.3V。

时钟 / RCC 配置序列（HAL 库）

// 从停止模式唤醒：重新使能HSE/PLL，并将SYSCLK切换回PLL时钟
__HAL_PWR_CLEAR_FLAG(PWR_FLAG_WU);

HAL_RCC_OscConfig(&(RCC_OscInitTypeDef){
  .OscillatorType = RCC_OSCILLATORTYPE_HSE,
  .HSEState = RCC_HSE_ON,
  .PLL.PLLState = RCC_PLL_ON,
  .PLL.PLLSource = RCC_PLLSOURCE_HSE,
  .PLL.PLLMUL = RCC_PLL_MUL9
});

HAL_RCC_ClockConfig(&(RCC_ClkInitTypeDef){
  .ClockType = RCC_CLOCKTYPE_SYSCLK | RCC_CLOCKTYPE_HCLK | RCC_CLOCKTYPE_PCLK1 | RCC_CLOCKTYPE_PCLK2,
  .SYSCLKSource = RCC_SYSCLKSOURCE_PLLCLK,
  .AHBCLKDivider = RCC_SYSCLK_DIV1,
  .APB1CLKDivider = RCC_HCLK_DIV2,
  .APB2CLKDivider = RCC_HCLK_DIV1
}, FLASH_LATENCY_2);

SystemCoreClockUpdate();

USB 重新初始化代码片段

// 时钟稳定后完全重启设备栈
USBD_DeInit(&hUsbDeviceFS);
__HAL_RCC_USB_FORCE_RESET();
HAL_Delay(2);
__HAL_RCC_USB_RELEASE_RESET();
__HAL_RCC_USB_CLK_ENABLE();

USBD_Init(&hUsbDeviceFS, &FS_Desc, DEVICE_FS);
USBD_RegisterClass(&hUsbDeviceFS, &USBD_CDC);
USBD_CDC_RegisterInterface(&hUsbDeviceFS, &USBD_Interface_fops_FS);
USBD_Start(&hUsbDeviceFS);

观察结果

  • 若跳过停止模式，仅在运行模式↔睡眠模式之间切换，系统稳定。
  • 唤醒后若将 SYSCLK 保持在 HSI（不启用 PLL），系统似乎更稳定，但我需要 72MHz 时钟满足时序要求。
  • 通过 GPIO 将 D + 拉低约 10ms（模拟断开）可提高恢复概率，但无法达到 100%。

求助问题

  1. 对于 F103 芯片，停止模式唤醒后，是否有标准的使能顺序 / 时序（HSE→PLL→USBFS）可避免 CDC 设备异常？
  2. 唤醒后强制 USB “软断开”（D + 拉低）是否属于 F1 系列的最佳实践，或是否有更优的协议栈级复位方法？
  3. 是否存在已知勘误，涉及停止模式后 HSE 启动 + PLL 锁定影响 USB SOF（帧同步信号）或 48MHz 时钟域？
  4. 推荐在 USB 时钟恢复时先使用 HSI，再切换到 PLL，还是始终优先稳定 PLL？
  5. 您遇到过哪些板级问题可能导致该现象：D + 电阻容差、ESD 二极管 / 泄漏、晶振负载过重、LDO 瞬态响应不良等？
1個讚
2

嗨，你好，

這是一個F1系列裝置與停止模式後USB重新列舉的經典且極其令人沮喪的問題！你絕對沒有瘋，而且你已經嘗試過所有標準的故障排除步驟。這種間歇性問題（10–30% 的重現率）指向在複雜的時鐘重新配置期間存在微妙的時序/亞穩態問題。

以下是本人的分析與建議著重的方向，特別是圍繞USB外設的時鐘域與所需的48 MHz時鐘穩定性。

:alarm_clock: 時鐘序列健全性檢查與48 MHz領域

你的RCC序列在重新啟用HSE/PLL方面看起來標準且正確。問題不太可能出在PLL本身，而是USB外設（需要由PLL / 1.5產生的48 MHz時鐘）從斷電狀態轉換到全速操作時的處理方式。

  1. USB時鐘來源限制： USB FS時鐘必須來自PLL，特別是PLLCLK / 1.5以達到$48\text{ MHz}$。即使PLL短暫不穩定，也可能導致裝置發送的前幾個幀起始(SOF)封包損毀，使主機PC忽略該裝置（僵屍CDC）。
  2. 重置時序： __HAL_RCC_USB_FORCE_RESET()與__HAL_RCC_USB_RELEASE_RESET()序列是正確的，但其持續時間可能不夠或與喚醒後的PLL鎖定時間相對而言不夠精準。F103的數據手冊顯示HSE的啟動時間與PLL的鎖定時間是分開的。你基本上是在進行：
    • 喚醒 \rightarrow 啟動HSE/PLL
    • …（PLL鎖定）…
    • USB時鐘啟用 + 重置脈衝
    • …（立即執行USBD_Init）…

如果在釋放USB重置時PLL剛好穩定，初始時鐘可能仍然邊緣。2毫秒延遲可能不足以確保整個PLL/USB時鐘鏈完全穩固。

:hammer: 建議的解決方法：分離/重新連接操作

你觀察到拔掉D+下拉有助於恢復是關鍵。強制進行物理分離/重新連接通常是向主機PC發出裝置消失並重新出現的唯一可靠方式。

其運作原理： USB列舉由主機處理。如果裝置在喚醒週期中的時鐘不穩定，主機可能會看到無回應的裝置（或垃圾數據），並簡單地將其忽略，使埠口處於「暫停」或「錯誤」狀態，等待物理重置（你的NRST提供）。軟體分離/重新連接會強制主機的USB控制器重新啟動其埠口列舉狀態機。

在你的時鐘穩定後嘗試以下序列：

  1. 時鐘穩定性： 確保HSE/PLL完全穩定且$\text{SYSCLK} = 72\text{ MHz}$（你目前的RCC區塊）。
  2. USB停用（軟體分離）：
    • 停用內部D+上拉電阻（如果使用內部上拉）。對於Blue Pill/外部D+上的1.5 k$\Omega$，你需要使用GPIO主動將D+拉低一段短時間。
    • 將D+引腳配置為GPIO輸出低電位。
    • HAL_Delay(10);（10毫秒是常見的可靠最小分離時間）。
  3. USB重新初始化（重新連接）：
    • 將D+引腳重新配置為USB功能（或重新啟用內部上拉電阻）。
    • 執行你的完整USB重新初始化序列：
      USBD_DeInit(&hUsbDeviceFS);
__HAL_RCC_USB_FORCE_RESET();
HAL_Delay(2); // 仍然建議保留
__HAL_RCC_USB_RELEASE_RESET();
__HAL_RCC_USB_CLK_ENABLE();

USBD_Init(&hUsbDeviceFS, &FS_Desc, DEVICE_FS);
// ...（其餘初始化）
USBD_Start(&hUsbDeviceFS);
    • 主機現在應該會看到D+上拉電阻並開始重新列舉。

這是最佳實踐嗎？ 對於F1系列而言，是的，在從停止模式喚醒時強制進行軟體分離以實現可靠的USB重新列舉是一種眾所周知的實用解決方法。

:magnifying_glass_tilted_right: 板級陷阱

雖然你的電源軌看起來乾淨（$\lt20\text{ mVpp}$漣波優異），但仍需考慮以下因素：

  • 晶體負載電容（22 pF）： 對於8 MHz HC-49晶體，$22\text{ pF}$處於較高端，可能會略微增加HSE啟動時間或影響喚醒後的頻率穩定性。大多數8 MHz晶體建議使用$10\text{ pF}$至$15\text{ pF}負載電容。雖然可能性較低，但值得查閱晶體的數據手冊以確認其推薦的\text{C}_{\text{L}}$（負載電容）。
  • D+電阻容差： 你的$1.5\text{ k}\Omega$上拉電阻正確。確保其未顯著偏移（例如$\text{+/-} 5%$），因為此電阻會向主機信號傳達全速裝置的狀態。
  • ESD二極體/漏電流： 如果你在D+/D-上有外部ESD保護二極體，請確保它們不會增加顯著的電容或漏電流，這可能會干擾精細的$3.3\text{ V}$信號。

務必嘗試D+ GPIO分離/重新連接操作。它解決了主機與裝置喚醒狀態不同步的根本問題。

3

你好。这在 F103 + Blue Pill 上是个经典坑，主要原因在于Host 端没能识别到设备断开，以及 Blue Pill 的硬件设计缺陷。

针对你的问题，直接给解决方案：

1. 核心原因：D+ 上拉电阻与软连接
Blue Pill 开发板的 D+ 上拉电阻（R10）通常直接焊在 3.3V 上，而不是受 MCU GPIO 控制。

  • 现象： 当 MCU 进入停止模式或复位时，D+ 依然通过电阻被拉高。主机（PC）认为设备一直连接且空闲，不会重新枚举。
  • 你的操作： 你提到“拉低 10ms”，这时间太短了。PC 端的 USB 协议栈（尤其是 Windows）通常需要检测到 D+ 低电平持续 100ms 以上（建议 500ms-1s）才会判定为设备断开（SE0 状态）。

2. 解决方案：强制重枚举序列
在 SystemCoreClockUpdate() 之后，USB 初始化之前，加入这段“暴力”重置代码：

// 1. 强制配置 PA12 (D+) 为 GPIO 输出低电平，模拟拔线
GPIO_InitTypeDef GPIO_InitStruct = {0};
__HAL_RCC_GPIOA_CLK_ENABLE();

GPIO_InitStruct.Pin = GPIO_PIN_12;
GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_PP;
GPIO_InitStruct.Pull = GPIO_NOPULL;
GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW;
HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);

HAL_GPIO_WritePin(GPIOA, GPIO_PIN_12, GPIO_PIN_RESET); // 拉低 D+

// 2. 延时足够长的时间让 Host 识别断开
HAL_Delay(600); // 建议 500ms - 1000ms，10ms 绝对不够

// 3. 释放引脚，交还给 USB 外设控制（此时上拉电阻会再次拉高 D+，触发 Host 枚举）
// 注意：后续的 USBD_Init 会重新配置引脚为复用功能，这里只要不再强制输出低即可

3. 关于时钟配置的补充
F103 的 USB 时钟必须是 48MHz。

  • 检查点： 确保 RCC 配置中 RCC_USBCLKSOURCE_PLL_DIV1_5 被正确设置。
  • 72MHz (SysClk) / 1.5 = 48MHz。如果这步错了，USB 会因为时序不对而无法通讯，即使枚举了也会报“无法识别的设备”。

4. 针对你问题的快速回答

  • 时序顺序： HSE -> PLL -> Flash Latency -> SysClk -> 强制 D+ 拉低 600ms -> USB Init。
  • 最佳实践： 对于没有三极管控制上拉电阻的板子，软件控制 PA12 拉低是唯一的“软断开”标准做法。
  • 勘误： F103 停止模式唤醒通常没有会导致 USB 彻底挂掉的硅片勘误，问题主要出在 Host 状态机没复位。

建议下一步：
把那段 10ms 的拉低延时改成 600ms，问题应该就能解决。

4

针对你的问题，我遇到过类似情况。从停止模式唤醒后USB CDC异常，通常是时钟恢复时序和USB外设状态未完全复位导致的。以下是关键要点和建议：

1. 时钟恢复顺序与勘误
F103在停止模式唤醒后，默认使用HSI（8MHz）作为系统时钟。你重新启用HSE和PLL的步骤是正确的，但存在一个关键时序：必须等待PLL锁定后，再使能USB时钟。USB FS需要精确的48MHz时钟（由PLL提供）。如果USB时钟在PLL不稳定时被启用，会导致USB PHY工作异常，主机无法识别。

建议在HAL_RCC_OscConfig后，增加检查PLLRDY标志的等待：

while(__HAL_RCC_GET_FLAG(RCC_FLAG_PLLRDY) == RESET);

然后再执行HAL_RCC_ClockConfig。

2. USB外设的彻底复位
你执行的USBD_DeInit和强制复位序列是必要的，但顺序可以优化。ST的勘误表（针对某些F1型号）指出，从停止模式唤醒后，USB外设可能需要一个更长的复位脉冲。建议将USB时钟禁用、复位、再使能的延时增加到至少10ms。

更可靠的做法是，在唤醒后先保持USB时钟禁用，等系统时钟完全稳定（PLL锁定且SYSCLK切换完成）后，再执行以下硬复位序列：

__HAL_RCC_USB_CLK_DISABLE();
__HAL_RCC_USB_FORCE_RESET();
HAL_Delay(10);
__HAL_RCC_USB_RELEASE_RESET();
__HAL_RCC_USB_CLK_ENABLE();
// 然后再执行USBD_Init等初始化

3. 关于“软断开”DP拉低
强制DP拉低10ms模拟断开是有效的“土办法”，也确实是F1系列常用的最佳实践之一。这能确保主机检测到物理断开并触发重新枚举。为了提高成功率，建议在拉低DP前，先确保USB外设时钟已停止，并在拉低后保持足够时间（10-20ms）。这不是协议栈级的方法，但硬件上最直接。

4. 时钟源切换建议
不要在USB工作时切换到HSI。正确的做法是：唤醒后，目标就是快速稳定地恢复原来的72MHz PLL时钟。应优先稳定PLL，确保其锁定，然后再处理USB。在PLL稳定前，不要让USB外设有任何时钟。

5. 板级可能原因
根据你的描述，硬件问题可能性较低，但可以排查：

  • 晶振负载电容：22pF对于8MHz HC-49是典型值，但唤醒时HSE启动慢可能导致PLL锁定时间变长。可尝试将电容减小到18-20pF，并检查晶振两端波形是否干净。
  • USB信号线：串联22Ω电阻是标准的，确保D+的上拉电阻（1.5kΩ）直接来自MCU的3.3V，且电源在唤醒瞬态能保持稳定。
  • 电源：唤醒瞬间电流增大可能导致LDO轻微跌落。虽然你测的纹波很小，但可以在VDD与地之间增加一个10µF的钽电容，增强瞬态响应。

总结与推荐步骤

  1. 唤醒后时钟恢复：启用HSE → 等待HSE就绪 → 启用PLL → 等待PLL锁定 → 切换SYSCLK到PLL → 更新SystemCoreClock。
  2. 彻底复位USB：先禁用USB时钟，强制复位并保持10ms以上，再释放复位并重新使能时钟。
  3. 重新初始化USB栈：调用USBD_DeInit和USBD_Init序列。
  4. 可选“软断开”：如果上述步骤后问题仍间歇出现，在USB重新初始化前，将DP（PA12）配置为推挽输出并拉低至少15ms，然后再初始化和上拉。

按这个顺序操作，应该能大幅提高唤醒后USB CDC的恢复可靠性。

2個讚