你的浏览器版本过低,可能导致网站不能正常访问!
为了你能正常使用网站功能,请使用这些浏览器。

【实战经验】无法使用内置 Bootloader 的 DFU 方式进行固件升...

[复制链接]
zero99 发布时间:2016-9-20 16:02
无法使用内置 Bootloader 的 DFU 方式进行固件升级
/ y. ?) L& S& c8 g+ I6 {

# k, K8 I- c& E+ J* e1 前言
3 z! k' X# C' s* }, E本文将针对客户无法使用内置Bootloader的DFU方式进行固件升级的问题进行分析。! M) }' w' y1 e% p1 M1 u
! S# ^( k2 W3 D  X. v5 T) i, t

) r% O; c% z( g' K0 b* Z& |( ?  I* a2 问题描述. d) [0 a) R2 N9 ]
客户使用的是STM32F205VET6,做了个最小系统测试板,在BOOT0=1,BOOT1=0的情况下连接PC,使用PC端软件DfuSeDemo无法检测到DFU设备,但是同样在Bootloader模式下,却可以通过串口1进行固件升级。7 `8 [4 V6 ^0 y# K$ A, W
8 K! G6 g: N% r' r: W

% o7 `/ S, Q( ^7 l3 问题分析6 L$ K- a3 ~  Q) d% q
首先怀疑的是USB线路问题,因此,在却换到正常模式(BOOT0=0,BOOT1=0)时,使用CubeMx做了个简单的鼠标HID测试程序验证,结果发现在正常模式下测试程序是能正常运行的,从这点可以说明USB不存在线路不通的问题。
) {$ _" A- I) B2 f  J
- N3 m8 q( H! m其次,检查各个管脚的电平,VDD,BOOT0,BOOT1均未发现异常。
: a* a, j6 ~% z5 ~6 v+ T* U, O于是打开应用文档AN2606-STM32 microcontroller system memory boot mode.pdf,通过此应用文档可知,不同的Bootloader版本可用于固件升级的方式不尽相同,如3.2节如下内容:- Z& f$ }. w' u$ ~! W. t
11.png   y, ]' i5 W0 T' [$ y

) |8 [7 D# [* Y因此怀疑此MCU的BID是否会不支持DFU?通过上图可知,BID可以通过SWD直接读取,因此我们需要找到保存此BID信息的地址。
# K3 _" G7 o+ w# ~8 B通过应用文档AN2606 3.2节的表3:
3 h5 B$ ~, U7 ^3 V4 V2 j 12.png 1 \4 w  ^! i+ e1 |
$ Q6 V9 y# `4 a" {& w
如上图可知,STM32F2的Bootloader存在两种BID,可以通过地址为0x1FFF77DE这个地址的值来获取,如为0x20则只支持USART,若为0x33,则支持USART,CAN,DFU这3种方式。于是使用PC端软件STM32 ST-LINK Utility通过SWD读取0x1FFF77DE这个地址的值,如下图所示:
' u; C$ i! t$ I2 n0 I 13.png 2 O9 v2 i1 T: q* _$ ^
如上图,可见客户使用的STM32F205的BID为0x33,是同时支持USART,CAN和DFU这3种方式的,因此,排除Bootloader版本问题的可能性。
, e2 m/ a5 o# B7 ^* y. |
- J- B  @1 B9 X1 a$ E, e在上述可能性都排除外,客户提出怀疑芯片本身或Bootloader烧录的代码有问题,于是找出一块STM32F4-DISCOVERY板进行MCU替换,替换后的结果为STM32F205在放到DISCOVERY板上则能正常通过Bootloader的DFU方式进行固件升级,因此,这就明确排除了芯片本身问题的可能性,因此,只可能是用户板子外围电路的问题。
4 u+ T$ H  r+ B再次回到AN2606这个应用文档,在15.2.2节找到Bootloader的工作流程图,如下所示:
# ?( ?- a  N4 U4 C& o 14.png
+ j4 b" u5 F9 y2 U/ a' C9 y7 A" W2 C
通过上图可知,Bootloader是依次检查USART->CAN->DFU的方式,怀疑Bootloader程序在DFU之前由于某种未知原因是否已经进入到USAR或CAN的方式中而一直没有出来?
* d% P! G) f4 \3 O! S$ x' k2 J0 a( r2 V- r# `4 P
为了排除这种可能性,我们针对USART1的RX脚PA10,USART3的RX脚PB11和PC11拉高,同时将CAN2的RX脚PB5拉低进行测试,结果还是无法检测到DFU设备。% w" y& O) W. Z7 |" O/ y6 `

/ G  ^: ^' [  q% H5 G& K. ?' @9 w. m* r再次回到上图进行分析,如上图,若USART和CAN都没有检测到的话,Bootloader程序会检测USB线是否连接,然后检测外部HSE,若HSE不存在,则产生系统复位,否则将会重现配置系统主频到60M。
  X# ^1 ^8 \+ K6 d0 z. t! U+ B) j6 ?; O! F% _: f" e
由于我们是连着USB线且在正常运行模式下USB是能正常工作的,因此,这里检测USB线结果应该是通过的,于是按照程序流程,接下来检测外部HSE,若检测失败则复位系统。与是用示波器查看
7 y/ N* p- V) `$ f4 Y0 UVDD与NRST脚的波形,发现系统在VDD上电后有3次复位,如此,可以得出Bootloader程序在检测外部HSE时结果为失败,如下:7 g" Z; y, g; l( ]
15.png ( b0 W) [2 r5 M) u9 O

8 g" f# K/ F2 k为什么会检测外部HSE失败? 用户使用的HSE是8M晶振,与DISCOVERY板一样都是8M外部晶振,对比用户的外部晶振电路与DISCOVERY的对应电路,如下图所示:
$ c* _; b! i, ]3 i% C) ?4 V+ z3 h 16.png
6 q; J, m1 x- l! c. ]5 G
, P$ D2 q. ^8 W* M7 t3 s如上图,左边为客户板子的晶振电路,右边为DISCOVERY板的晶振电路,对比可知,用户的负载电容使用的是33pF,且多了个1M的反馈电阻。
; Y: s, t7 z: n首先将反馈电阻去掉后测试,结果还是一样。进一步将客户板子的晶振负载电容换成20pF后进行测试,结果可以正常检测到DFU设备,如此可见,正是因为这个负载电容的原因造成Bootloader的DFU无**常工作!& @( E& o5 B9 {8 t3 S* n* K

. @5 @$ l0 E, E" J, J2 p! A' ~1 U1 J" N
4 总结
0 W4 R0 {- Y8 X( ]5 \6 e此问题是由于晶振负载电容过大,导致内置Bootloader程序在检测外部HSE的时间点与实际HSE稳定震荡所需的时间不同步造成,结果就是检测不到HSE,进而引起系统复位,最终无法使用Bootloader的DFU方式进行固件升级。
7 V" W, N2 z; \5 B( w
; ]  @$ ?$ Z2 r$ {: Z: u9 E% F, G+ r# ]  \% b2 v
5 本文所涉及到的文档与软件下载链接6 \7 m# R$ T$ l7 D! t
AN2606 https://www.stmcu.org.cn/document/detail/index/id-200918
) Z) u, n6 d* H- d8 H' GDfuSeDemo https://www.stmcu.org.cn/document/detail/index/id-214339
* n8 g" Z* N3 _( Q" Z! m! ^8 ?STM32 ST-LINK Utility https://www.stmcu.org.cn/document/detail/index/id-215840) i3 s2 T6 L8 C8 K4 b' l, q

3 G) A* k( t" s9 E& Q4 e
- F0 K% l8 h6 U2 t) O! k点击下载文档
5 a% [# i" |" B6 W  ?查看更多实战经验$ e- ^6 R- P; R$ w( H- I. {5 t

: Y7 b+ {+ Z9 R, h5 Q
1 收藏 3 评论3 发布时间:2016-9-20 16:02

举报

3个回答
天道酬勤DW 回答时间:2016-10-8 16:53:47
这个分析的好,厉害
wdshuang09 回答时间:2016-10-8 18:25:08
问题分析的很透彻,学习了
xiaoxiao0932 回答时间:2016-12-15 15:07:58
谢谢分享啊~

所属标签

相似分享

关于意法半导体
我们是谁
投资者关系
意法半导体可持续发展举措
创新和工艺
招聘信息
联系我们
联系ST分支机构
寻找销售人员和分销渠道
社区
媒体中心
活动与培训
隐私策略
隐私策略
Cookies管理
行使您的权利
关注我们
st-img 微信公众号
st-img 手机版