stm32的RAM自检，在读写RAM中的数据时，程序总是进入HardFault，检查没有溢出。

zhangxiaolin

最近项目增加单片机的RAM ROM自检功能。在坐第一个RAM自检的功能时就遇到问题。stm32的RAM起始地址，和空间大小如下图所示
因此在编写Test_RAM时，按照先将RAM空间中的写满0x00，在读回空间中的数据和0x00做对比，判断读回的数据是否都是0x00。如果都是0X00在向空间中写入0XFF，同样再读回RAM空间中的数据，和0XFF做对比，判断读回的数据是否都是0XFF，如果两次对比都没有问题，则认为RAM是OK的。现在编写如下伪代码： ，程序在读写数据时，特别容易进入HardFault,硬件错误中断函数，不知道为什么？是溢出了？不应该溢出，求大神指点。

zc123

zhangxiaolin 发表于 2019-5-14 14:56
先写入0X00，读出0X00的代码截图如下：这这部分代码只测试向RAM指定区域写入0X00，然后读出数据。不执行 ...

单纯看代码，没有问题，不过这样情况就复杂了
(1)编译器生成的汇编结果不正确(这个只能结合汇编一起调试，找出错误的汇编语句，再具体分析)
(2)芯片RAM本身存在问题，这个概率极低，但也不是不可能
只能靠你自己了

zc123

因为你根本不能这么写，你定义的栈也在这个0x20000000范围内，你相当于修改了栈内的数据，出现hardfault很正常，不出现才是运气好，你这种自检，代码里面不能覆盖栈的空间，看你.s文件分配多大，起始地址不要包含栈空间，如果实在要求包含栈的全覆盖，修改ResetHandler函数，在调用SystemInit之前用汇编实现

zhangxiaolin

zc123 发表于 2019-5-14 10:16
因为你根本不能这么写，你定义的栈也在这个0x20000000范围内，你相当于修改了栈内的数据，出现hardfault很 ...

启动文件中栈的大小定义为：Stack_Size      EQU     0x00000800  ; 从新定义起始地址，即：unsigned char *a = (unsigned char *)0x20000800; 待写入读出数据进行检测的RAM空间大小从新定义。即：b=0x10000-0x00000800;  for(b = 0; b<0xF800;b++) {}。软件还是进入HardFault、另外自己不会汇编语言，求大神支招。

zc123

zhangxiaolin 发表于 2019-5-14 13:31
启动文件中栈的大小定义为：Stack_Size      EQU     0x00000800  ; 从新定义起始地址，即：unsigned cha ...

把改过的代码截图看下，理论没什么其他问题

warship

没有汇编基础，
这种工作还是放弃吧。
RAM区是堆栈空间，也是你的各种变量的生存之地，
请问一下，你的那些a呀b呀什么的，还有子程序调用时的程序指针、通用寄存器如何保存和恢复？
你得知道RAM中那些空间是你可以自由支配的！！！
另外，ROM如何检查，这又涉及到你的程序代码存于什么空间的问题。

zhangxiaolin

zc123 发表于 2019-5-14 14:19
把改过的代码截图看下，理论没什么其他问题

先写入0X00，读出0X00的代码截图如下： 这这部分代码只测试向RAM指定区域写入0X00，然后读出数据。不执行读写0XFF，在debug模式下非常容易进入HardFault，直接download到主板，显示测试OK。debug模式下，Memory中的数据如下： 从RAM测试区域的起始地址：0x20000800    到   结束地址：0x2000FFFF中的数据全是0x00，即整个待测RAM区域数据写入读取OK。同样的方法流程：添加向RAM中写入0XFF，然后读取0XFF的测试代码，代码截图如下： ，测试不过，终端打印显示error1,同样是DOWNLOAD至主板，程序没有崩溃，测试结果均有打印输出。但是如果进入debug模式后，容易进入hardfault。在debug模式下的memory截图如下： ，说明向待测区域写入0XFF是不成功的，再读取的时候不符合条件肯定报错。为什么会有这些数据写入，写入的数据明明是0xFF.求大神指点。

zhangxiaolin

zc123 发表于 2019-5-14 15:54
单纯看代码，没有问题，不过这样情况就复杂了
(1)编译器生成的汇编结果不正确(这个只能结合汇编一起调试 ...

写入0XFF，debug模式下，部分地址的数据并不是0XFF,奇怪。

zhangxiaolin

warship 发表于 2019-5-14 14:48
没有汇编基础，
这种工作还是放弃吧。
RAM区是堆栈空间，也是你的各种变量的生存之地，

额，现在是向地址中写入0X00，读取也没问题。然后写入0XFF，debug模式下部分地址下的数据不是0XFF，分析不出来为什么。

edmund1234

这样的测试是可以用的， 但必须放在startup_stm32f1xx.s做
不止是栈你不能动， 你函数里这么多局部变量， 寄存器是不够放的， 也是放RAM， 这怎么可能做呢？
一定要做的话， 就把局部变量减少，局部变量前加register， 把RAM的内容读出->保存->写0x00 ->读 ->写0xFF ->读 ->还原， 再继续下一个地址。
意思是测试完要把数据还原， 祝你好运吧

zhangxiaolin

edmund1234 发表于 2019-5-14 17:15
这样的测试是可以用的， 但必须放在startup_stm32f1xx.s做
不止是栈你不能动， 你函数里这么多局部变量，  ...

嗯嗯，在开机的时候，先进行RAM自检，如果OK的话再进入后边的应用，如果有问题的话就直接报警，不执行后边的逻辑。因此涉及到的局部变量应该不会很多，开机就进行RAM自检，因此也不涉及数据还原过程吧，我将数据置为0XFF，检测完后，再置回0x00，就可以了吧。

zhangxiaolin

zc123 发表于 2019-5-14 15:54
单纯看代码，没有问题，不过这样情况就复杂了
(1)编译器生成的汇编结果不正确(这个只能结合汇编一起调试 ...

在这个代码的基础上进行的测试，在向待测试的RAM空间中写入0XFF，查看Memory,发现一小段连续地址的内容不是写入的0XFF,(在6楼已经截图)，怀疑是板子RAM有问题，换战舰的板子试了一下，同样代码调试运行，测试通过，前述的问题不再出现。因此判断是板子的RAM有问题。后和公司硬件工程师沟通，大概内容是，他们认为RAM出现问题的概率非常小，一般都是ROM容易会有问题，怀疑是我程序的问题。

warship

zhangxiaolin 发表于 2019-5-14 18:03
在这个代码的基础上进行的测试，在向待测试的RAM空间中写入0XFF，查看Memory,发现一小段连续地址的内容不 ...

尽管在战舰上测试通过，也不能判断是板子RAM的问题，
这种测试偶然性很大，
公司的硬件工程师说得对，
你程序的问题几乎百分百。

zhangxiaolin

warship 发表于 2019-5-14 18:53
尽管在战舰上测试通过，也不能判断是板子RAM的问题，
这种测试偶然性很大，
公司的硬件工程师说得对，
...

嗯嗯，是的，程序在debug模式下还是容易进入HardFault的