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

使用HSI无法将PLL倍频到64M的话题

[复制链接]
STMCU小助手 发布时间:2021-2-24 11:13
使用HSI无法将PLL倍频到64M的话题

) r- @5 x' h  p5 B: S7 A
某客户使用STM32F103芯片开发产品,程序代码基于STM32F1的标准库进行开发。在设计初期,他用最小核心板调试程序。样板上有个8MHz外部晶体,但他一直使用HSI。所以最终产品就没有放置外部8M晶体。但等样机回来后,发现用内部HSI作为时钟源时,系统时钟无法通过PLL倍频64MHz,最高只能到48MHz可以正常运行,再高的话,程序执行后就会进入硬件故障中断,即HardFault_Handler()。
) {3 y# P9 [$ R9 b! t6 G9 T) x+ {- t
但之前程序在最小核心板上是调试通过了的,于是他试着把之前最小核心板上的外部晶体拆掉,程序竟然也跑不起来了。
1 [# A+ a' I7 u# m+ U
这似乎表明,如果没有外部晶体,使用HSI就无法倍频至64MHz。这就奇怪了?!难道不接外部晶体,内部HSI就无法倍频至64MHz吗?

" [: m( ?; d$ i
到此,客户反映的情况应说很清楚了。对于STM32F1系列而言,不论是手册的表述还是实际应用,我们知道即使使用HSI的作为时钟源,通过PLL是完全可以倍频到64MHz的。

' D6 W. H: t5 W! t. l
如果说只是单纯地倍频到不了64MHz的话,原因可能性较大的有2种情况:
第一、因为疏忽,配置参数出现失误导致超频。这也可能导致芯片功能异常。
第二、MCU的供电有问题。一般表现在MCU的电源脚没有全部接上电源,即只是部分电源脚接上了电源;再一种可能性就系统供电能力不足。因为MCU主频越高,功耗也相对越高。如果供电跟不上的话也会出现性能异常。
具体到本案例,上面第一种情况可以很快排除。因为在外接晶体时,使用HSI还是可以倍频到64MHz的。现在问题的症结就是,为什么只有外接晶体时,HSI才能被倍频到64MHz。

3 g; U8 q, R( s& O2 s7 ~- `, B' X
要解开这个症结,就有必要了解下基于STM32F1标准固件库芯片启动时的有关时钟的基本配置流程。
芯片复位后首先要运行一个启动文件,启动文件里就有对系统时钟的一些基本配置。不妨就以STM32F1系列为例【如基于标准固件库,其它STM32系列在这点上基本一样】。
# E* V3 U- s$ Y4 V# I
启动文件里面有个SystemInit( )函数,它又调用了SetSysClock()时钟配置函数。该函数就是做有关系统时钟、外设时钟、AHB时钟以及指令预取和Flash读取等待延时等配置的。在SetSysClock()里会根据默认的或用户预定义的系统时钟频率去对有关时钟、指令预取、FLASH等待进行配置。
' H1 l) R# }8 Q2 r
5.1.jpg

& E- U1 x* j: F1 j
对于STM32F103xx,用户若不对代码额外调整,启动代码里默认使用HSE 8Mhz,SYSTEM CLOCK 为72MHz来进行配置。如果外部晶振没接上,就默认使用HSI作为系统时钟。
! |1 a3 s, |9 Z6 q3 o6 f: w
具体结合到这里,外接晶体时,启动时默认使用HSE并通过PLL倍频到72MHz;没有外接晶体时,直接使用HSI作为系统时钟。之后用户自己重新利用HSI进行系统时钟配置。若经前者的途径过来,用户就可以将PLL倍频到64MHz,而经后者却不行。这两种操作有哪些差别呢?

: d0 @7 M+ r7 G& x3 u6 K
5.2.png
8 `* F+ G( @* F6 j/ K3 t
启动代码默认HSI作为系统时钟,一路默认设置,并无过多代码。那我们重点看看SetSysClock()调用到的SetSysClockTo72()的代码,看能否有所发现,或者说代码里有什么特别的没有。

9 c5 Y7 {- `/ r  d% S/ _
5.3.jpg
) q$ e4 d( g; I) f8 [3 J. b, _
从该函数里可以看到红色三角形标注的代码,令人想起有关指令预取和FLASH等待状态的配置。那个flash等待状态的配置,不同的系统时钟下,参数是不一样的。系统时钟频率越高,这个等待状态参数值越大。毕竟FLASH控制器读取FLASH数据的速度是很有限的,而CPU对指令的运行速度可以很高,当CPU对指令的访问速度高于或远高于FLASH控制器所能提供的速度时,就涉及到读取等待和指令预取问题。结合CPU的时钟和FLASH本身的读取时间,打开指令预取,合理配置FLASH等待就很关键,否则当CPU时钟高到一定程度时就会出现功能异常。

2 Q, Z5 a. T7 n
结合本案例来看,当板上放了晶体时,刚好符合启动代码默认外部HSE作时钟源配置出72MHz的条件,并在这个过程中开启指令预取和配置了等待延时。后面当用户把时钟源换为HSI并利用PLL倍频到64Mhz时,就无需再做指令预取和FLASH等待配置,系统也能正常运行。当板子上没放外部晶体时,启动代码默认HSI作为系统时钟,且该过程没做指令预取和FLASH等待的配置【因系统时钟频率低,此时也的确不需要额外设置,使用默认0等待即可】。之后,当用户使用HSI利用PLL进行倍频时,他自己也没做指令预取和FLASH等待的配置,当系统时钟频率配置较高时出现功能异常也就不意外了。后来建议客户在使用HSI对PLL进行倍频前,加入上面提到的相关配置代码后就得以解决。

/ x; ?' w1 s: a2 G' w& X7 v+ p
5.4.jpg
$ l( `* u, H, w& y9 o1 M
其实,如果客户的软件开发是基于ST公司推出的工具STM32CubeMx来进行的话,类似上面的问题是比较容易避免的。对于刚接触STM32的人来说,使用STM32CubeMx可以大大节省开发时间。当然,任何东西都有其两面性,工具给我们带来方便的同时,有时可能会让我们对一些基本的、细节的东西缺乏相应的了解和把握。所以,条件允许的话,多研读技术手册、多分析参考代码也是有必要的。

  W! A: X/ o! o# _9 e
文章出处: 茶话MCU

- W; e, w2 F4 j8 X
收藏 评论0 发布时间:2021-2-24 11:13

举报

0个回答

所属标签

相似分享

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