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

程序运行在 STM32H750 的外扩 FLASH 上两小时后死机

[复制链接]
STMCU小助手 发布时间:2023-1-11 14:04
1.问题现象
客户使用 STM32H750VBT6,通过 QSPI 外扩了一个 4M 的 NOR FLASH,采用memory map 模式。当程序跳转运行到外设 FLASH 后,大约两个小时后程序死机。
* H+ K! R, q8 V1 O
客户使用的 IDE 是 KEIL,此问题可以固定重现。在 KEIL 调试模式下重现问题时,通过多次观察发现,程序死的位置总体上会停在两个位置,并不是同一个位置。一个是 TIM15函数的入口;另一个是进入中断函数后的一个赋值语句。
4 O' H) A+ N$ K
2.问题分析及测试
通过拜访客户,观察到死机位置处于即将进入但还未进入的 TIM15 中断入口处。查看客户的原理图,发现两个 VCAP 并未从外部相连,于是要求客户直接从外部将此两个引脚飞线短连。但是,后来经测试问题仍然重现。
+ i8 S/ X& W: J0 w/ @
又观察到 PC13 连接为 GPIO 输出引脚,用于驱动一外部组件。考虑到备份域相关的一些引脚其驱动能力相对弱一些,于是让客户将 PC13 引脚断开后再测试,结果问题仍然重现。
2 v8 O3 K2 h; ]$ O9 }: e+ f
上面是一些硬件相关的怀疑点,从测试结果来看,与此问题无关。看来主要可能还是软件方面的问题。在软件上确定客户已经打开了 IO 补偿功能, IO 速度设置的是 HIGH,即使让客户修改成 “VERY_HIGH”,经测试问题仍然存在。

/ l3 |1 z+ {# ^' z: P' R1 {
由于之前发生过一个从低功耗唤醒后死机的问题,是与 Cache 相关的问题,于是测试将 CACHE 关闭的情况。这次经测试客户反馈问题没再重现 !
: u# ~3 ]. w3 \* k' w/ U- h8 ?
但客户同时也反馈,之前的代码也存在稍微修改一处代码,问题就不再重现的现象,没有找到具体规律。

2 [1 s* t% b0 s2 r4 j$ C
这次代码修改也没排除这种可能性。为了让关闭 Cache 的方法更具说服力,于是让客户在调试模式下通过手动关闭 CACHE的方式,代码仍然保持为原先可以重现问题的代码。如下图所示 :

6 c4 b0 \/ N5 N& {( k$ g0 o
微信图片_20230110185139.png
1 `" Y/ g6 n8 M! Z
如上图所示,在代码运行到使用 CACHE 后一行设置断点,当程序停下来后,打开 Sys Ctrl/Cfg 窗口(菜单 view->system viewer->Core peripherals->system control and configuration),将对应的位去掉。最终客户反馈,关闭 DC,或者 IC 任何一个或者两个都关闭,问题现象消失。至此可以确定地是,此问题与 CACHE 相关 !

; g5 s* q+ A1 w" O5 @9 `: q3 A3 {
于是查看客户的 MPU 相关配置,并将 Cube 包里的 H750 示例工程中的 MPU 配置发给客户测试下,但问题仍然存在。
8 K; u; I. q' N' t7 K: c
接下来查看勘误手册,发现 2.4.4 节有 QSPI 相关的内容:

. v8 g$ M7 s; H( l3 O5 j* b& H
微信图片_20230110185135.png
; }. p! b' ]' `) E# T/ @& s- D6 d6 |! A8 H) U( ?! p' O
这里有提到在 QSPI 外设 FLASH 并工作在 memory-mapped 模式的时候,当读取由FSIZE 定义的最后一个字节的时候,不管内容如何,有可能会导致 AXIs 总线 STALL 掉。

% n5 w9 ]" C7 V9 D5 h
并同时给出了三种规避措施。其中第一种是将 FSIZE 定义得比实际大,以留有足够的裕量。于是让客户修改代码:在 QSPI 初始化时将 size 设置成大一倍:
面红色部分表示的 nor flash 设置成实际的两倍大小。 0 a7 r' K2 P5 R( C' `

8 l; z5 {# v3 J" g$ j
同时考虑到此处定义了实际两倍大小的 FLASH,多出来的另外一半实际是不存在的,为了避免 CPU 意外访问这个实际不存在的区域,使用 MPU“告诉”CPU 这多出来的一半区间是不可访问的。
$ ]* z) Q( h& ^- H
于是 MPU 按如下来配置:
使用串口终端工具,分别连接 USART1,USART3,发送对应的 UART Bootloader 命令,得到下图 3 的命令交互。
' C8 Q6 h9 J: ]) L6 u1 d
图3. MPU 配置
微信图片_20230110185129.png
' |0 A2 i8 C5 I% l) S; p' B6 |/ e  K, a
客户再次测试,问题不再重现。为了进一步验证问题,客户尝试按原先的代码直接读取 NOR FLASH 的最后一个字节,问题还会重现,再次验证此方法的有效性,至此问题解决。

: w) G& ~2 ^  Q" Y
3.后记
有些人可能会问,NOR FLASH 的最后一个字节 CPU 真的会去访问吗 ? 客户的程序占满了整个 FLASH 空间了吗 ? 若那个地址没有代码那还会不会有这个问题。

8 Q1 L7 ]! U# A- G
其实勘误手册 2.4.4 节也提到了,不管 FSIZE 定义的空间最后的一个字节内容是什么,均会有此问题。那么 CPU 为什么会去访问此地址呢 ? 其实这是 M7 内核的指令预取和分支预测试探性访问导致的。
( u) _& Z' e. U3 W& @, R/ v
在 M7 编程手册中可以找到如下内容:

' O9 p; \& v. O4 ^ 微信图片_20230110185126.png , S: v* V: v4 @# [7 h/ U$ g

4 N6 r6 o" k! h" c# B
正是上述特性才导致 CPU 会提前访问 NOR FLASH 上的地址,即使当前 PC 指针还未指到那里。我们可以通过合适的MPU配置防止因试探性访问外存而导致问题。
8 r1 A$ f9 Q* v$ W/ X6 W: w  N' r1 v
7 q0 `6 G6 x7 {; k& D, I
赞 收藏 评论0 发布时间:2023-1-11 14:04

举报

0个回答

所属标签

相似技术帖

官网相关资源

关于
我们是谁
投资者关系
意法半导体可持续发展举措
创新与技术
意法半导体官网
联系我们
联系ST分支机构
寻找销售人员和分销渠道
社区
媒体中心
活动与培训
隐私策略
隐私策略
Cookies管理
行使您的权利
官方最新发布
人形机器人运动控制、感知与智能配电
半导体创新技术与应用方向
EE架构与软件定义汽车
12V/48V 汽车智能配电(SPD)
区域控制单元(ZCU)与分区架构
关注我们
st-img 微信公众号
st-img 手机版