[参考译文] LAUNCHXL-F280049C：存储器地址映射&amp；UniFlash 输出文件超过闪存大小 KB

jiaxin sun 说：

错误文件*。out 文件480KB 超出组0的256KB 闪存大小。

除代码和数据外、.out 文件还包含使用调试器所需的所有符号信息。 因此、.out 文件大小与目标器件闪存大小没有实际关系。

我意识到、在很长时间的时间里、TI ARM 控制器项目都有用于 LM 闪存实用程序的内部 HEX2BIN 转换。 它们还会创建*。out 文件、因此我想我们只需使用内存分配工具来求近似值。

尊敬的 Siddharth：

奇怪的是、技术简介(TB)不同意数据表、因为它指出 M0-M1是2kB、每个1Kx16谁在乎。 似乎表8-1不是 x49c 的正确内存映射。

LS0-7具有相同的奇数地址范围：TB 显示4KB、然后是2Kx16。 因此、扩展都是欠大的、内存分配工具读取的是 KB。

根据 CCS 内存分配工具、GS0-GS3每个为16KB (16000字节)、标注为8Kx16、存储器范围为 KB 而不是 K。

为什么数据表范围中的 KB 大小被除以2、表8-1似乎是相关的2倍？

x49c 不是具有100KB 的 SRAM 和256KB 的闪存、而是具有8KB 扇区、每个扇区2个组 x16？ 数据表头仅显示256KB 或单组闪存以及分配的32,768K (LS0-LS7)的100KB RAM。 如果 x49c 具有 256KB 的闪存、则每个扇区为8KB、而不是4KB。 如果事实并非如此、则 x49c 只有128KB 的闪存4KB 扇区、而数据表错误地提示它在第1页中具有256KB 的闪存。 闪存具有32位数据端口还是128位数据端口无关紧要、这不会改变显示的总存储容量为256KB 的情况。

好像有人混淆了16位数据总线存储器、认为它与以千字节为单位的实际存储空间有任何相关性。 如果我们对闪存256,000/32进行分频、则每个扇区中有16KB 的16,000B/16=1000或(4096B)个扇区、而不是2048字节。 CPU 寄存器以前只有8位宽、现在是64位宽、但这不能为它们提供更大的存储器范围、它只需要更高的地址范围以更快的速度访问存储字。

相反、如果 表8-1正确、那么 x49甚至不应该运行4096KB 扇区和4KB LSRAM 段。 甚至 M0-M1也只有1KB。  

FLASHB0_SA：origin = 0x080002，length = 0x00FFFE /*片上闪存*/
FLASHB1_SA：origin = 0x090000、length = 0x010000 /*片上闪存、user parameters storage */

BOOT_RSVD：origin = 0x000002、length = 0x0000F3 /* M0的一部分，引导 ROM 将此用于堆栈*/
RAMM0_1：origin = 0x0000F5、length = 0x000800 /* 2KB：1Kx16专用于 CPU (M0和 M1)*/

RAMLS0_1：origin = 0x008000，length = 0x002000 /* 4KBx2：2Kx16不能被使用，为快速对象保留*/
RAMLS2_3：origin = 0x00A000，length = 0x002000 /* 4KBx2：2Kx16在 CPU 和 CLA 之间共享(LSx RAM)*/
RAMLS4_7：origin = 0x00C000、length = 0x002000 /* CPU 与 CLA 共享4KBx2：2Kx16 (LSx RAM)*/

RAMGS0：origin = 0x00E000、length = 0x004000 /* 16KB：(8Kx16)在 CPU 和 DMA (GSx RAM)之间共享*/
RAMGS1：origin = 0x012000、length = 0x004000 /* 16KB：(8Kx16)在 CPU 和 DMA 之间共享(GSx RAM)*/

您好！  

同意这是令人困惑的。  在 C28x 上,一个  byte/char 是指16位。  

请参阅与 CCS 内存分配工具相关的主题  

https://e2e.ti.com/support/tools/code-composer-studio-group/code-composer-studio---internal/f/code-composer-studio---internal-forum/1090445/ccs-memory-allocation-view-bug-for-c2000/4038454

此致

西达尔特

6188425 说：

同意这是令人困惑的。  在 C28x 上,一个  byte/char 是指16位。  [/报价]

此外、16位宽的数据总线不能在 SRAM 或闪存中提供更多的存储空间、它只能提高吞吐量、而不能提高容量！ 购买 MCU 时、相对于预期应用固件的闪存大小始终为 KB、而不是 Kx16。 上面发布的内存大小正常工作、并且 CCS 编译器未给出地址重叠错误。 我认为表8-1适用于较旧的 Piccolo C28x MCU 类别、如 F68x 或 F69x、但不适用于较新的类别。

与1KB 相比、2KB 的 M0_M1设置为0KB 时、CPU 为什么不停止？ 不应是技术简介图2和表8-1显示 M0的0.5Kx16？ 请注意、M0-M1以下的每个大小都以一致的间隔进行 Kx16、M0-M1除外、这是没有道理的。 下面是技术简介中的一个拼写错误？

存储块 M0和 M1的大小均为2KB (1Kx16)、

更复杂的是、TI 为什么会坚持认为社区内存容量大于实际容量、而从营销角度来看这是毫无意义的呢？ 数据表表格似乎反映了较早一代的 Piccolo C28x MCU 类、并且从未像某人复制粘贴的那样进行更新。

示例： TMS ARM Cortex MCU 类数据表显示512KB 某些1024KB 闪存容量、实际情况下仅为256KB 还是512Kx16？

您所访问的页面不存在!

您共享的链接是否 可从外部访问？ 正如 GI 也提到的,此链接会导致页面未找到,  
https://e2e.ti.com/support/tools/code-composer-studio-group/code-composer-studio---internal/f/code-composer-studio---internal-forum/1090445/ccs-memory-allocation-view-bug-for-c2000/4038454

是的,谢谢,这个非内部 URL 工作. 但这种 讨论令人不安!

重新定义一个"字节"不能接受讨论。 字节= 8位周期。 高级数据类型(如"char"为16位)与 因 硬件设计而异的任何其他高级数据类型(int、long、double 等)没有区别、这是正常的。 但是字节的定义。。。 这是一个完全不同的讨论,与重新定义什么是"位"相同。  术语 "字"的创建是为了处理多字节数据大小、最初为16位或双字节、但现在被视为其他高级数据类型。  

而在这个话题,使用 KW 对于 kiloWord 也是非常令人困惑的 EES... 不能告诉你这趟火车开了多少次船。  

Unknown 说：

重新定义"字节"不应成为讨论对象。 字节= 8位周期

同意8位= 1个字节、将 KW 分配给 RAM 会更令人困惑。 因此、它似乎能在1k x 16位= 2KB 物理 LSRAM 的范围内正常工作。 那么、1K x16是逻辑可寻址数据空间？ 似乎数据表 TRM 应使用"物理"和"逻辑"一词来表示差异。  

Unknown 说：

在主题中,使用 KW for kiloWord 也是非常令人困惑的 EES...

真的以为这是千瓦的刮头从来没有连接点它是千言万语。 记忆怎么会变成这么热  

Siddharth 为了 向您需要用一致的文档添加更多支持信息、我从 sprsp61b.pdf 文件中提供此信息、在该文件中、用户可以找到在开始页面上定义的闪存空间。  

显然、KB 是 KW 的一半、这意味着一个字节是16位、而 KW 是32位、但我认为可以放心地假设 这里的字是16位、 字节是8位。  

PS 感谢以上指向28004x 内存映射的链接、它增加了对  我将在28003x 行提出的不同文档问题的支持。