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

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

[复制链接]
zero99 发布时间:2016-9-20 16:02
无法使用内置 Bootloader 的 DFU 方式进行固件升级
" A& g  }0 [3 l, c
/ y9 B  ~8 Z: W6 F
1 前言
( G4 J! R) H- Q8 U5 W* ]本文将针对客户无法使用内置Bootloader的DFU方式进行固件升级的问题进行分析。
' a* A1 ?, V( V9 ?3 Z$ `) w3 [9 }0 x& {5 E5 E0 _' ]8 j
% O, p  I% l1 x3 w3 {$ t0 M
2 问题描述% |6 ~+ O/ X3 W. U5 T% ]
客户使用的是STM32F205VET6,做了个最小系统测试板,在BOOT0=1,BOOT1=0的情况下连接PC,使用PC端软件DfuSeDemo无法检测到DFU设备,但是同样在Bootloader模式下,却可以通过串口1进行固件升级。4 A  g6 [$ G# `+ E3 T' G# J0 ]

8 a; ~1 k8 _: S8 v. V- H
; {5 P. O  T9 n4 H3 问题分析
9 r: L8 U" U& U! i' y. [- K) w# s8 F首先怀疑的是USB线路问题,因此,在却换到正常模式(BOOT0=0,BOOT1=0)时,使用CubeMx做了个简单的鼠标HID测试程序验证,结果发现在正常模式下测试程序是能正常运行的,从这点可以说明USB不存在线路不通的问题。
8 p% J6 _, V) q% F
9 @* b2 l* F" L. Q其次,检查各个管脚的电平,VDD,BOOT0,BOOT1均未发现异常。
$ _/ ^9 R7 R2 K, }于是打开应用文档AN2606-STM32 microcontroller system memory boot mode.pdf,通过此应用文档可知,不同的Bootloader版本可用于固件升级的方式不尽相同,如3.2节如下内容:; Z: ?5 Z# Q- j  F* T1 }8 \
11.png ) z6 `( c9 E; y9 n( {8 ^
2 L, K. k( @, Z+ @: ?& x$ u, _8 L
因此怀疑此MCU的BID是否会不支持DFU?通过上图可知,BID可以通过SWD直接读取,因此我们需要找到保存此BID信息的地址。
6 h( \' _3 O- z+ Z: B8 S通过应用文档AN2606 3.2节的表3:
, n! L3 F/ [5 o, ^3 v! @ 12.png 7 N. S8 @5 D9 @5 c9 P1 E

# [$ J& p. ^- G' W( m- w' j/ u- p6 p如上图可知,STM32F2的Bootloader存在两种BID,可以通过地址为0x1FFF77DE这个地址的值来获取,如为0x20则只支持USART,若为0x33,则支持USART,CAN,DFU这3种方式。于是使用PC端软件STM32 ST-LINK Utility通过SWD读取0x1FFF77DE这个地址的值,如下图所示:
% H6 {- C! _5 l 13.png , p( _; a2 b$ ~6 R/ J  T/ C* l
如上图,可见客户使用的STM32F205的BID为0x33,是同时支持USART,CAN和DFU这3种方式的,因此,排除Bootloader版本问题的可能性。
; ~  x& a% Q. Z6 C& u* f$ u
9 C, i) F# _* U8 V* M% {在上述可能性都排除外,客户提出怀疑芯片本身或Bootloader烧录的代码有问题,于是找出一块STM32F4-DISCOVERY板进行MCU替换,替换后的结果为STM32F205在放到DISCOVERY板上则能正常通过Bootloader的DFU方式进行固件升级,因此,这就明确排除了芯片本身问题的可能性,因此,只可能是用户板子外围电路的问题。
% P; o9 K2 J4 A6 T& l再次回到AN2606这个应用文档,在15.2.2节找到Bootloader的工作流程图,如下所示:
: o/ m% v/ V& [1 l" k9 ]* C! x 14.png
& G8 \+ `, Y5 |2 D
( |9 J' ?( X5 y7 U通过上图可知,Bootloader是依次检查USART->CAN->DFU的方式,怀疑Bootloader程序在DFU之前由于某种未知原因是否已经进入到USAR或CAN的方式中而一直没有出来?( t. `  a  e  D5 b

: f1 Y1 n: }0 C6 p! m: u- A8 q为了排除这种可能性,我们针对USART1的RX脚PA10,USART3的RX脚PB11和PC11拉高,同时将CAN2的RX脚PB5拉低进行测试,结果还是无法检测到DFU设备。
6 T) ~5 _+ k! f/ M
2 }) ~" `9 }( g8 r5 a0 f8 N再次回到上图进行分析,如上图,若USART和CAN都没有检测到的话,Bootloader程序会检测USB线是否连接,然后检测外部HSE,若HSE不存在,则产生系统复位,否则将会重现配置系统主频到60M。. X+ p+ }( y* P3 }9 W

$ @; D( y2 W) ~, N/ b% O+ T, B由于我们是连着USB线且在正常运行模式下USB是能正常工作的,因此,这里检测USB线结果应该是通过的,于是按照程序流程,接下来检测外部HSE,若检测失败则复位系统。与是用示波器查看, l* z1 w$ ]" t: ~% R6 v
VDD与NRST脚的波形,发现系统在VDD上电后有3次复位,如此,可以得出Bootloader程序在检测外部HSE时结果为失败,如下:- \( x  u# K% _8 ~. C7 r/ S
15.png : J3 k- \9 L" y5 |
( z' M9 U* V, p4 ?  B4 H
为什么会检测外部HSE失败? 用户使用的HSE是8M晶振,与DISCOVERY板一样都是8M外部晶振,对比用户的外部晶振电路与DISCOVERY的对应电路,如下图所示:. Z* z" j* c; R1 z* ~0 c
16.png   D3 d0 u: Q1 X9 e' Q" `
6 ], P: B, @  J1 i# W7 }
如上图,左边为客户板子的晶振电路,右边为DISCOVERY板的晶振电路,对比可知,用户的负载电容使用的是33pF,且多了个1M的反馈电阻。
$ m0 c" l, A, o( p5 {首先将反馈电阻去掉后测试,结果还是一样。进一步将客户板子的晶振负载电容换成20pF后进行测试,结果可以正常检测到DFU设备,如此可见,正是因为这个负载电容的原因造成Bootloader的DFU无**常工作!
* q5 O  e4 s1 |. c' \$ D
$ f- O9 E2 l) k  k. {$ l2 J0 S+ I+ x5 s0 X3 v& l1 _2 J- t( ]
4 总结: U! C5 y, m, Q1 ?# U2 \
此问题是由于晶振负载电容过大,导致内置Bootloader程序在检测外部HSE的时间点与实际HSE稳定震荡所需的时间不同步造成,结果就是检测不到HSE,进而引起系统复位,最终无法使用Bootloader的DFU方式进行固件升级。
1 f0 g5 ?  _& k4 ~+ I! L% k; @* I- F1 l( e

# b3 m) _  x/ S) B5 A5 本文所涉及到的文档与软件下载链接) L2 L5 a* f# R( I# A  f+ d8 [
AN2606 https://www.stmcu.org.cn/document/detail/index/id-200918" J& e$ j7 @  Y2 i
DfuSeDemo https://www.stmcu.org.cn/document/detail/index/id-2143395 d1 A& J  X- B( t7 m' s
STM32 ST-LINK Utility https://www.stmcu.org.cn/document/detail/index/id-215840
/ f! ^9 d# t9 \# \
5 Y6 ~- P* q: j, S1 X0 k8 R5 \& P
+ q; X$ o/ _3 l0 ]& u( q& q7 T9 p6 Z点击下载文档
( P5 q+ F4 i4 e7 N) G查看更多实战经验! P$ O" z2 J: u8 A. u
5 S3 O0 R, }, w# I7 k" ~
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 手机版