CH32V003待机唤醒异常：AWUWR赋值差异导致无法唤醒

核心原因：整数运算差异与隐性配置问题 #

1. 计算结果的实际差异 #

你提到传入StandBySeconds=2u时两个表达式写入寄存器的值相同，但实际计算结果并不一致：

• (199 * 2u)/100 = 398/100 = 3（整数除法向零取整）
• (201 * 2u)/100 = 402/100 = 4

这两个值都在PWR_AWUWR的6位范围（0~0x3F）内，因此写入的是不同数值——这直接导致唤醒周期差异：值为3时对应预期的2秒唤醒，值为4时对应更长的唤醒时间，表现为“无法唤醒”。

2. 汇编指令差异的影响 #

在-O0优化等级下，GCC会保留所有中间计算步骤，你观察到的add/sub指令差异，是编译器针对不同常量选择的整数除法实现逻辑不同：

• 对于(199*2)/100，编译器通过加法+移位的组合快速得到结果3
• 对于(201*2)/100，则使用减法+移位的方式得到结果4

这种差异本身不会直接出错，但结合CH32V003的待机机制，可能存在隐性影响：

• 不同计算路径的指令周期不同，导致写入PWR_AWUWR后到进入待机的时间差，恰好使得AWU模块未完成初始化就进入休眠，无法触发唤醒
• 极端情况下，计算过程中使用的寄存器可能意外干扰PWR模块的其他控制位（如AWU使能位），但概率较低

3. 类型转换的隐性风险 #

虽然201*2u的结果未达到32位无符号整数溢出阈值，但如果seconds是8位无符号类型（unsigned char），201作为int类型与它运算时，可能触发隐性类型转换的未定义行为：

• 201超出unsigned char的取值范围（0~255），编译时可能被截断，但作为int参与运算时不会影响结果，不过这种场景可能导致编译器生成异常代码逻辑。

解决方案 #

• 显式指定常量类型：将常量改为无符号类型（如201u），确保运算全程为无符号整数，消除类型转换风险
• 直接写入计算后的值：对于固定待机时长，直接写PWR->AWUWR = 3;替代运行时计算，避免编译差异
• 添加内存屏障：写入PWR_AWUWR后，执行__asm__ volatile ("fence" ::: "memory");确保寄存器写入完成后再进入待机

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