This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] MSP430FR5969:SRAM/FRAM 测试和存储器分配

Guru**** 2029180 points
Other Parts Discussed in Thread: MSP430FR5969
请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/microcontrollers/msp-low-power-microcontrollers-group/msp430/f/msp-low-power-microcontroller-forum/1461010/msp430fr5969-sram-fram-test-and-memory-allocation

器件型号:MSP430FR5969

工具与软件:

你(们)好  我需要执行测试来检查 MSP430FR5969中的存储器是否正常工作。

我有一个简单的函数、该函数具有一个局部数组和两个循环。 第一个循环将循环索引分配给数组中的每个元素。 第二个循环检查数组的每个元素是否等于循环索引。 我假设数组被分配在 RAM 的堆栈部分中。 当我更改本地阵列的大小时、TI CCS 中的"Memory Allocation"面板仍然报告相同的 RAM 和堆栈使用情况、报告的 FRAM 和 FRAM2使用情况也不会改变。 如果我将阵列大小更改为一个 与微控制器 RAM 大小一样大的值、那么每次调用 RAM 测试函数时、TI CCS 都不会就此发出警告、但微控制器会复位。 仅当我将本地阵列的大小更改为大于微控制器的 SRAM 和 FRAM 组合大小时、TI CCS 才会生成"阵列太大"。 CCS 为什么不能可靠地生成该错误? 我缺少什么? 如何 确保不会遇到分配问题?

我在微控制器的链接器文件中查看存储器部分的地址。 其中、RAM 来源为0x1C00、长度为0x0800。 假设 RAM 段的第一个地址为0x1C00、最后一个地址为0x23FF。 当我调试上述函数时、本地数组中的某些元素的地址超出了预期的 RAM 范围。 但我还注意到、这些段及其地址并不是连续的、存储器段之间有一些未使用的地址。 存储器映射方式如下表所示、从最低存储器地址到最高、并且我还在链接器文件中包含了存储器映射规格部分。 我不知道如何读取链接器文件、因此我想问我的解释是否正确、存储器中是否有未映射的范围。 如果实际上有未映射范围、即使它们未映射、它们是否存在于芯片中? 如果它们存在、它们的用途是什么?

我还希望通过校验和算法或 CRC 模块执行指令完整性检查。 我如何知道指令驻留在了哪个地址? 我可以使用在项目文件夹中生成的.map 文件中的信息吗? 或者您会有其他建议吗?

谢谢。

起始地址 结束地址
SFR 0x0000 0x000F
外设_8位 0x0010 0x00FF
外设_16位 0x0100 0x01FF
未映射范围 0x0200 0x17FF
INFOD 0x1800 0x187F
INFOC 0x1880 0x18FF
INFOB 0x1900 0x197F
INFOA 0x1980 0x19FF
未映射范围 0x1A00 0x1BFF
RAM 0x1C00 0x23FF
未映射范围 0x2400 0x43FF
FRAM 中 0x4400 0xFF7F
签名和中断向量 0xFF80 0xFFFF
FRAM2 0x10000 0x13FF7

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
/****************************************************************************/
/* Specify the system memory map */
/****************************************************************************/
MEMORY
{
SFR : origin = 0x0000, length = 0x0010
PERIPHERALS_8BIT : origin = 0x0010, length = 0x00F0
PERIPHERALS_16BIT : origin = 0x0100, length = 0x0100
RAM : origin = 0x1C00, length = 0x0800
INFOA : origin = 0x1980, length = 0x0080
INFOB : origin = 0x1900, length = 0x0080
INFOC : origin = 0x1880, length = 0x0080
INFOD : origin = 0x1800, length = 0x0080
FRAM : origin = 0x4400, length = 0xBB80
FRAM2 : origin = 0x10000,length = 0x3FF8 /* Boundaries changed to fix CPU47 */
JTAGSIGNATURE : origin = 0xFF80, length = 0x0004, fill = 0xFFFF
BSLSIGNATURE : origin = 0xFF84, length = 0x0004, fill = 0xFFFF
IPESIGNATURE : origin = 0xFF88, length = 0x0008, fill = 0xFFFF
INT00 : origin = 0xFF90, length = 0x0002
INT01 : origin = 0xFF92, length = 0x0002
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    这一切似乎毫无意义。 每次通过 FRAM 硬件中的 ECC 自动访问 FRAM 时、都会对其进行检查。 您可以启用中断、以便在发生错误时执行某些代码。

    对于内存分配、编译器只能通过做出假设来处理这种情况。 这很容易混淆。 因此、为了避免分配错误、请务必记住这一点。 除非您知道有可用空间、否则不要分配全局或自动的大型数组。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    关键是、微控制器在其应用环境中时需要进行自我检查。 我想通过在 SRAM 和微控制器的 FRAM 中进行 March 测试来执行该测试。 最好使阵列尽可能大。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Andy、您好!

    这些"未映射"区域通常根本不存在、硬件地址是位置、因此 CPU 知道如何访问非易失性存储器或 RAM 区域、地址按照从 FRAM 到外设地址到中断地址等的顺序排列 具有大型中断可防止任何溢出、还可防止对区域进行意外的"有效"访问。

    您的代码是否进行了优化? 这可能是导致在整个可用内存溢出之前不会出现分配问题的潜在原因。

    若要读取链接器、请更正如下:origin + Length = End Address。

    此致、
    Luke

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    具有大断点保护、可防止出现任何溢出、还可防止对某个区域进行意外的"有效"访问。

    另请参见 VMAIE。