{var%20f='http://v.t.sina.com.cn/share/share.php?appkey=1515056452',u=z||d.location,p=['&url=',e(u),'&title=',e(t||d.title),'&source=',e(r),'&sourceUrl=',e(l),'&content=',c||'gb2312','&pic=',e(p||'')].join('');function%20a(){if(!window.open([f,p].join(''),'mb',['toolbar=0,status=0,resizable=1,width=440,height=430,left=',(s.width-440)/2,',top=',(s.height-430)/2].join('')))u.href=[f,p].join('');};if(/Firefox/.test(navigator.userAgent))setTimeout(a,0);else%20a();})(screen,document,encodeURIComponent,'','','https://www.xiaopingtou.cn/data/attach/logo/logo.png', '推荐 慧心的眼眸 的问题《无法使用内置Bootloader的DFU方式进行固件升级》','https://www.xiaopingtou.net/q-137464.html','页面编码gb2312|utf-8默认gb2312'));){kind=link}
1 前言本文将针对客户无法使用内置Bootloader的DFU方式进行固件升级的问题进行分析。2 问题描述客户使用的是STM32F205VET6，做了个最小系统测试板，在BOOT0=1，BOOT1=0的情况下连接PC，使用PC端软件DfuSeDemo无法检测到DFU设备，但是同样在Bootloader模式下，却可以通过串口1进行固件升级。3 问题分析首先怀疑的是USB线路问题，因此，在却换到正常模式(BOOT0=0,BOOT1=0)时，使用CubeMx做了个简单的鼠标HID测试程序验证，结果发现在正常模式下测试程序是能正常运行的，从这点可以说明USB不存在线路不通的问题。其次，检查各个管脚的电平，VDD，BOOT0，BOOT1均未发现异常。
于是打开应用文档AN2606-STM32 microcontroller system memory boot mode.pdf，通过此应用文档可知，不同的Bootloader版本可用于固件升级的方式不尽相同，如3.2节如下内容：
图1 BID定义
因此怀疑此MCU的BID是否会不支持DFU？通过上图可知，BID可以通过SWD直接读取，因此我们需要找到保存此BID信息的地址。
通过应用文档AN2606 3.2节的表3：
图2 F2的BID地址
如上图可知，STM32F2的Bootloader存在两种BID，可以通过地址为0x1FFF77DE这个地址的值来获取，如为0x20则只支持USART，若为0x33，则支持USART，CAN，DFU这3种方式。于是使用PC端软件STM32 ST-LINK Utility通过SWD读取0x1FFF77DE这个地址的值，如下图所示：
图3 F2的BID值
如上图，可见客户使用的STM32F205的BID为0x33，是同时支持USART，CAN和DFU这3种方式的，因此，排除Bootloader版本问题的可能性。
在上述可能性都排除外，客户提出怀疑芯片本身或Bootloader烧录的代码有问题，于是找出一块STM32F4-DISCOVERY板进行MCU替换，替换后的结果为STM32F205在放到DISCOVERY板上则能正常通过Bootloader的DFU方式进行固件升级，因此，这就明确排除了芯片本身问题的可能性，因此，只可能是用户板子外围电路的问题。再次回到AN2606这个应用文档，在15.2.2节找到Bootloader的工作流程图，如下所示：
图4 Bootloader的工作流程图
通过上图可知，Bootloader是依次检查USART->CAN->DFU的方式，怀疑Bootloader程序在DFU之前由于某种未知原因是否已经进入到USAR或CAN的方式中而一直没有出来？
为了排除这种可能性，我们针对USART1的RX脚PA10，USART3的RX脚PB11和PC11拉高，同时将CAN2的RX脚PB5拉低进行测试，结果还是无法检测到DFU设备。再次回到上图进行分析，如上图，若USART和CAN都没有检测到的话，Bootloader程序会检测USB线是否连接，然后检测外部HSE，若HSE不存在，则产生系统复位，否则将会重现配置系统主频到60M。由于我们是连着USB线且在正常运行模式下USB是能正常工作的，因此，这里检测USB线结果应该是通过的，于是按照程序流程，接下来检测外部HSE，若检测失败则复位系统。与是用示波器查看VDD与NRST脚的波形，发现系统在VDD上电后有3次复位，如此，可以得出Bootloader程序在检测外部HSE时结果为失败，如下：
图5 HSE 检测失败
为什么会检测外部HSE失败？ 用户使用的HSE是8M晶振，与DISCOVERY板一样都是8M外部晶振，对比用户的外部晶振电路与DISCOVERY的对应电路，如下图所示：
图6 HSE对比
如上图，左边为客户板子的晶振电路，右边为DISCOVERY板的晶振电路，对比可知，用户的负载电容使用的是33pF，且多了个1M的反馈电阻。
首先将反馈电阻去掉后测试，结果还是一样。进一步将客户板子的晶振负载电容换成20pF后进行测试，结果可以正常检测到DFU设备，如此可见，正是因为这个负载电容的原因造成Bootloader的DFU无法正常工作！4 总结此问题是由于晶振负载电容过大，导致内置Bootloader程序在检测外部HSE的时间点与实际HSE稳定震荡所需的时间不同步造成，结果就是检测不到HSE，进而引起系统复位，最终无法使用Bootloader的DFU方式进行固件升级。参考资料：http://www.makeru.com.cn/ 嵌入式学习交流群：561213221
于是打开应用文档AN2606-STM32 microcontroller system memory boot mode.pdf，通过此应用文档可知，不同的Bootloader版本可用于固件升级的方式不尽相同，如3.2节如下内容：
图1 BID定义
因此怀疑此MCU的BID是否会不支持DFU？通过上图可知，BID可以通过SWD直接读取，因此我们需要找到保存此BID信息的地址。
通过应用文档AN2606 3.2节的表3：
图2 F2的BID地址
如上图可知，STM32F2的Bootloader存在两种BID，可以通过地址为0x1FFF77DE这个地址的值来获取，如为0x20则只支持USART，若为0x33，则支持USART，CAN，DFU这3种方式。于是使用PC端软件STM32 ST-LINK Utility通过SWD读取0x1FFF77DE这个地址的值，如下图所示：
图3 F2的BID值
如上图，可见客户使用的STM32F205的BID为0x33，是同时支持USART，CAN和DFU这3种方式的，因此，排除Bootloader版本问题的可能性。
在上述可能性都排除外，客户提出怀疑芯片本身或Bootloader烧录的代码有问题，于是找出一块STM32F4-DISCOVERY板进行MCU替换，替换后的结果为STM32F205在放到DISCOVERY板上则能正常通过Bootloader的DFU方式进行固件升级，因此，这就明确排除了芯片本身问题的可能性，因此，只可能是用户板子外围电路的问题。再次回到AN2606这个应用文档，在15.2.2节找到Bootloader的工作流程图，如下所示：
图4 Bootloader的工作流程图
通过上图可知，Bootloader是依次检查USART->CAN->DFU的方式，怀疑Bootloader程序在DFU之前由于某种未知原因是否已经进入到USAR或CAN的方式中而一直没有出来？
为了排除这种可能性，我们针对USART1的RX脚PA10，USART3的RX脚PB11和PC11拉高，同时将CAN2的RX脚PB5拉低进行测试，结果还是无法检测到DFU设备。再次回到上图进行分析，如上图，若USART和CAN都没有检测到的话，Bootloader程序会检测USB线是否连接，然后检测外部HSE，若HSE不存在，则产生系统复位，否则将会重现配置系统主频到60M。由于我们是连着USB线且在正常运行模式下USB是能正常工作的，因此，这里检测USB线结果应该是通过的，于是按照程序流程，接下来检测外部HSE，若检测失败则复位系统。与是用示波器查看VDD与NRST脚的波形，发现系统在VDD上电后有3次复位，如此，可以得出Bootloader程序在检测外部HSE时结果为失败，如下：
图5 HSE 检测失败
为什么会检测外部HSE失败？ 用户使用的HSE是8M晶振，与DISCOVERY板一样都是8M外部晶振，对比用户的外部晶振电路与DISCOVERY的对应电路，如下图所示：
图6 HSE对比
如上图，左边为客户板子的晶振电路，右边为DISCOVERY板的晶振电路，对比可知，用户的负载电容使用的是33pF，且多了个1M的反馈电阻。
首先将反馈电阻去掉后测试，结果还是一样。进一步将客户板子的晶振负载电容换成20pF后进行测试，结果可以正常检测到DFU设备，如此可见，正是因为这个负载电容的原因造成Bootloader的DFU无法正常工作！4 总结此问题是由于晶振负载电容过大，导致内置Bootloader程序在检测外部HSE的时间点与实际HSE稳定震荡所需的时间不同步造成，结果就是检测不到HSE，进而引起系统复位，最终无法使用Bootloader的DFU方式进行固件升级。参考资料：http://www.makeru.com.cn/ 嵌入式学习交流群：561213221
友情提示: 此问题已得到解决，问题已经关闭,关闭后问题禁止继续编辑，回答。
一周热门 更多>