最近有个STM32用户反映,他们目前在调试STM32G431CBU6这款芯片。使用ST官方的Cube库进行编程,发现时钟没法配置到技术手册上告知的170MHz。当然这个170MHz的频率要经过PLL倍频产生。不管选用内部时钟源还是外部晶振,只要配置成170MHz,芯片肯定会复位。
基于HSI时钟源的相关时钟配置代码大致如下:
他尝试做了各种软硬件调整排查,经过反复测试验证,发现设置PLL所产生的时钟只有在不高于80MHz时,芯片才能正常运行。可STM32芯片手册白纸黑字明明写着主频可以跑到170MHz啊!
由于死活找不出软件或硬件方面的原因,几近内心崩溃。甚至不直觉地开始怀疑该芯片是否真的支持170MHz的主频。所以他的问题简单直接,STM32G4到底支不支持170MHz的主频?
关于STM32G4系列的主频参数,是最基本而核心的一个参数,手册是不可能写错的。何况本人之前也使用STM32G4的开发板做过一些测试,都是基于170MHz进行的。
鉴于这种情况,我们首先可以检查一个参数,即CPU通过FLASH控制器取指时的那个延时等待参数,它配置得是否合适会影响MCU的正常工作。我们知道CPU的访问速率通常要比FLASH控制器的取指速率快得多,这个延时等待参数的配置需要跟CPU的主频匹配。各个STM32系列的参考手册里都有个对照表。下图是STM32G4系列的。
按照上面表格来看,如果内核时钟跑到170MHz,这个Latency参数应该设置为8。
经了解,他已经注意到这个参数了,并将这个参数做了正确配置。看来不是这方面的原因,再换个方向看看。
主频的提高往往意味着功耗的增大或噪声及干扰方面可能加剧。于是试图从系统供电能力、电源稳定度、时钟稳定性方面查找原因,依然没有发现明显问题。
建议他对STM32芯片所有电源或电源相关管脚逐个排查连接、焊接情况,当然也包括VDDA脚的连接情况。遇到类似这种没法一下子从软硬件上找出与异常症状之间明显的逻辑关系时,这样做往往是个简单而且比较有效的排错办法。
经针对相关管脚的逐个排查,很快发现芯片的VDDA脚虚焊了,重新处理后芯片于170MHz运行稳健。
问题终于得以解决。看到这里,相信很多人会认为该问题不复杂、也谈不上深奥,可这类问题原因往往容易被我们忽视掉,难就难在一会半会想不到可能的原因所在。
在我们的实际调试过程中可能很多类似的问题,虽谈不上多么复杂或深奥,但往往由于我们内心深处从头到尾存在对某些点的忽视或者想当然,导致一时半会找不到问题原因而耽误时间。比方一个大小端的选择、一个变量数据宽度的适时调整、一个虚焊的BOOT脚等,它们都很可能将我们困住好一阵子。
在此分享相关案例, 愿各位在MCU嵌入式开发过程中多些经验的积累,令开发过程尽量平坦而舒心些。
全部0条评论
快来发表一下你的评论吧 !