问题描述：3KW电源在客户端长时间运行时，电源累计运行时间中断。
原因分析：如果电源长时间运行，运行时间可能会变短或者运行时间增加较少。此行为表明执行时间变量可能已在某个时刻被清除，并且复位可能在MCU 运行时发生。接下来，编写一个测试程序版本，记录复位次数并检索复位状态寄存器的值。当MCU 复位时，我们从闪存中取出复位计数变量的值，加1，然后写入下一个值。将值返回到闪存。每次复位时，复位寄存器的值都会被赋值给复位寄存器变量，复位计数变量和复位寄存器变量在运行过程中通过CAN通信发送。
复位寄存器的说明如下：
的复位次数算1次。经过一周的长时间测试，我发现已经重置了3次。至此，已经确认MCU运行过程中偶尔会发生看门狗复位。
进一步查看看门狗复位的原因，并查看软件，看来只有发生异常时，才会进入while(1)无限循环，等待看门狗复位。然后它会屏蔽while(1) 并打开。尝试在异常处理代码中添加对flash 的写操作，在进入异常之前写入堆栈的内容，并保存它，以便下次可以看到问题出在哪里。进入异常后，程序异常停止，Flash无法工作，所有MCU外设停止工作，CAN通信也停止。目前无法知道堆栈的状态，也不清楚异常是在哪里触发的。我查看了CM3的权威指南，发现此时需要对MCU进行chiplock。
我能够获取PC 和LR 值来确定问题发生之前程序最后运行的位置，但芯片被锁定，所以目前无法执行此操作，只能显示。如果您分析代码和电源本身来提出问题，您会发现电源可能会受到外部干扰，并且电源在这个方向上使用两个外部上升沿。使用中断来检测两个风扇的速度并确定风扇故障状态。如果用示波器检查风扇转速信号，会发现实际波形噪声比较大。是这里的原因吗？我试过了，屏蔽了这两个中断，用查询方式检测风扇转速信号的高低电平次数，测试了2个月电源，复位也没发现问题。问题到这里就解决了。
解决方案：将原来检测风扇转速来判断风扇故障的中断方式改为查询方式，检测风扇转速信号的高低时间来判断风扇故障。这个问题已经彻底解决了。
经验总结：当STM32F103进入外部中断时，如果引脚上的干扰比较大，MCU可能会进入硬故障。如果此时再次触发，芯片将被锁定，只能等待。在此电源上，顶部风扇信号是具有连续上升沿的方波，干扰出现时MCU 会自然锁定。如果后面使用中断，一定要特别注意多次触发硬故障来锁定芯片。
版权声明：本文由今日头条转载，如有侵犯您的版权，请联系本站编辑删除。
