如何检查嵌入式系统上堆和堆栈 RAM 的一致性
我正在开发一个使用 LEON2 处理器 (Sparc V8) 的项目。 处理器使用 8MB RAM，需要在引导自检期间进行一致性检查。 我的问题是，我的 Boot 显然使用了一小部分 RAM 作为其堆/BSS/堆栈，我无法在不导致应用程序崩溃的情况下对其进行修改。 我的RAM测试非常简单，将某个值写入所有RAM地址，然后将它们读回以确保RAM芯片可以寻址。
此方法可用于大部分可用 RAM，但如何安全地检查剩余 RAM 的一致性？
I'm working on a project using a LEON2 Processor (Sparc V8).
The processor uses 8Mbytes of RAM that need to be consistency checked during the Self-Test of my Boot.
My issue is that my Boot obviously uses a small part of the RAM for its Heap/BSS/Stack which I cannot modify without crashing my application.
My RAM test is very simple, write a certain value to all the RAM address then read them back to be sure the RAM chip can be addressed.
This method can be used for most of the RAM available but how could I safely check for the consistency of the remaining RAM?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
一般来说，需要测试每个字节的 RAM 测试将作为处理器启动时首先发生的事情之一完成。通常，在此之前要做的唯一一件事是硬件初始化，RAM 测试需要进行硬件初始化才能访问 RAM。
它通常用禁用中断的汇编语言来完成，原因之一是因为这是确保不使用 RAM 的唯一方法。
如果您想在此之后执行 RAM 测试，您仍然需要在系统启动的早期进行。您也许可以分两遍进行 - 其中任何变量/堆栈/测试所需的任何内容都位于低 RAM 中，并且该测试测试高 RAM。然后使用高 RAM 中的数据再次运行测试，同时测试低 RAM。
另请注意：验证您是否读回写入的某个值是一个简单的测试，也许比什么都不做要好，但它可能会错过某些类型的常见故障（特别是对于外部 RAM：缺少或交叉焊接地址线。
您可以找到更详细的信息 ）有关基本 RAM 测试的信息，请参见：
Generally a RAM test that needs to test every single byte will be done as one of the first things that happens when the processor starts. Often the only other thing that's done before it is the hardware initialization that needs to happen for the RAM test to be able to access RAM.
It'll usually be done in assembly language with interrupts disabled, for one reason because that's about the only way you can ensure that no RAM is used.
If you want to perform a RAM test after that point, you still need to do it pretty early in the system start-up. You could maybe do it in two passes - where any variables/stack/whatever the test needs for its own purposes are in low RAM, and that test tests high RAM. Then have the test run again with it's data in high RAM while it tests low RAM.
Another note: verifying that you read back a certain value written is a simple test that maybe better than nothing, but it can miss certain types of common failures (common particularly with external RAM: missing or cross soldered address lines.
You can find more detailed information about basic RAM tests here:
由于我正在对安全相关设备进行编程，因此我必须在操作期间进行完整的 RAM 测试。
我将测试分为两个测试：
将唯一值写入每个寻址线到达的地址，在写入所有值后，读回这些值并将其与预期值进行比较。此测试检测寻址线的短路（或卡住@低/高）（意味着您想在地址 0xFF40 上写入 0x55，但由于短路，该值存储在 0xFF80 处，因此您无法通过测试 2 检测到这一点：
您将 RAM 的前 4 个字节保存在 CPU 的寄存器中，然后您首先清除单元格，写入 0x55，验证，写入 0xAA，验证并恢复保存的内容（您当然可以使用其他模式）等等，您必须使用寄存器的原因是通过使用变量，该变量将被该测试破坏。
您甚至可以通过此测试来测试您的堆栈。
在我们的项目中，我们一次测试 4 个单元，并且必须运行此测试，直到测试整个 RAM。
我希望这有一点帮助。
as I am programming a safety-relevant device, I have to do a full RAM test during operation time.
I split the test in two tests:
you write unique values to the addresses reached by each addressing line and after all values are written, the values are read back and compared to the expected values. This test detects short-circuits (or stuck@low/high) of addressing lines (meaning you want to write 0x55 on address 0xFF40, but due to a short-circuit the value is stored at 0xFF80, you cannot detect this by test 2:
You save e.g. the first 4 bytes of RAM in CPU's registers and afterwards you first clear the cells, write 0x55, verify, write 0xAA, verify and restore saved content (you can use other patterns of course) and so on. The reason you have to use the registers is that by using a variable, this variable would be destroyed by that test.
You can even test your stack with this test.
In our project, we test 4 cells at a time and we have to run this test until whole RAM is tested.
I hope that helped a bit.
如果您在 C 运行时环境启动之前进行测试，您可以毫无问题地清理堆和 BSS 区域。
一般来说，堆栈在运行时设置期间不会被太多使用，因此您可以将其丢弃而不会产生任何不良影响。只需检查您的系统即可。
如果您需要在测试期间使用堆栈或需要保留它，只需将其移动到已测试的区域，调整堆栈指针。之后只需恢复旧堆栈并继续即可。
一旦进入运行时环境，就没有简单的方法可以做到这一点。
If you do your testing before the C run time environment is up you can trash the Heap and BSS areas without any problems.
Generally the stack does not get used much during run time setup so you may be able trash it with no ill effect. Just check your system.
If you need to use the stack during testing or need to preserve it just move it to an already tested area adjust the stack pointer. After wards just restore the old stack and continue.
There is no easy ways of doing this once you entered your runtime environment.