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.
您好、香榭丽舍
我向我们的客户询问这一点。
由于 LS RAM 可以加密、CLA 到 CPU 不能加密。 这种理解是否正确?
加密区域可以访问 CPU 到 CLA RAM、也就是说、加密 CLA 区域可以获取从 CPU 传输的数据
但 CPU 无法通过 CLA 到 CPU RAM 在 CLA 中获取加密数据
2. 客户现在遇到的问题是、当他们不使用 DCSM 时、代码运行正常、但在使用 DCSM 之后、当代码未经解密而运行时、加密的 CLA 无法访问 CPU 到 CLA 的数据(DAC 输出的数据、输出为0)。
我检查了客户的.cmd 文件的配置、不应出现未加密 RAM 访问加密 RAM 的错误。 您会帮助分析原因吗? 谢谢!
MEMORY { PAGE 0 : /* BEGIN is used for the "boot to Flash" bootloader mode */ /* not boot used*/ BEGIN : origin = 0x080000, length = 0x000002 CLA_PROG_RAM : origin = 0x008000, length = 0x003800 RESET : origin = 0x3FFFC0, length = 0x000002 RAMGS1 : origin = 0x00E000, length = 0x002000 RAMGS2 : origin = 0x010000, length = 0x002000 /* Flash sectors */ /* BANK 0 */ HEADERINFO : origin = 0x084000, length = 0x000100, fill 0xFFFF /* on-chip Flash */ CPU_PROG_FLASH : origin = 0x084102, length = 0x00BEFE/* on-chip Flash */ /* BANK 1 */ CLA_PROG_FLASH : origin = 0x090000, length = 0x004000 /* on-chip Flash */ FLASH_BANK1_SEC4 : origin = 0x094000, length = 0x001000 /* on-chip Flash */ FLASH_BANK1_SEC5 : origin = 0x095000, length = 0x001000 /* on-chip Flash */ FLASH_BANK1_SEC6 : origin = 0x096000, length = 0x001000 /* on-chip Flash */ FLASH_BANK1_SEC7 : origin = 0x097000, length = 0x001000 /* on-chip Flash */ FLASH_BANK1_SEC8 : origin = 0x098000, length = 0x001000 /* on-chip Flash */ FLASH_BANK1_SEC9 : origin = 0x099000, length = 0x001000 /* on-chip Flash */ FLASH_BANK1_SEC10 : origin = 0x09A000, length = 0x001000 /* on-chip Flash */ FLASH_BANK1_SEC11 : origin = 0x09B000, length = 0x001000 /* on-chip Flash */ FLASH_BANK1_SEC12 : origin = 0x09C000, length = 0x001000 /* on-chip Flash */ FLASH_BANK1_SEC13 : origin = 0x09D000, length = 0x001000 /* on-chip Flash */ FLASH_BANK1_SEC14 : origin = 0x09E000, length = 0x001000 /* on-chip Flash */ FLASH_BANK1_SEC15 : origin = 0x09F000, length = 0x001000 /* on-chip Flash */ PAGE 1 : BOOT_RSVD : origin = 0x000002, length = 0x0000F3 /* Part of M0, BOOT rom will use this for stack */ RAMM1 : origin = 0x000400, length = 0x000400 /* on-chip RAM block M1 */ RAMLS7 : origin = 0x00B800, length = 0x0007F8 RAM_STACK : origin = 0x00C000, length = 0x000C00 RAMGS0 : origin = 0x00CC00, length = 0x001400 RAMGS3 : origin = 0x012000, length = 0x002000 CLA1_MSGRAMLOW : origin = 0x001480, length = 0x000080 CLA1_MSGRAMHIGH : origin = 0x001500, length = 0x000080 } SECTIONS { codestart : > BEGIN, PAGE = 0, ALIGN(4) .text : >>CPU_PROG_FLASH, PAGE = 0, ALIGN(4) .cinit : > CPU_PROG_FLASH, PAGE = 0, ALIGN(4) .pinit : > CPU_PROG_FLASH, PAGE = 0, ALIGN(4) .switch : > CPU_PROG_FLASH, PAGE = 0, ALIGN(4) .reset : > RESET, PAGE = 0, TYPE = DSECT /* not used, */ .cio : > RAMGS1, PAGE = 0 .stack : > RAM_STACK, PAGE = 1 .ebss : > RAMGS0, PAGE = 1 .esysmem : > RAMGS3, PAGE = 1 .econst : > CPU_PROG_FLASH, PAGE = 0, ALIGN(4) ramgs0 : > RAMGS0, PAGE = 1 ramgs1 : > RAMGS3, PAGE = 1 .reset : > RESET, PAGE = 0, TYPE = DSECT /* not used, */ /* CLA specific sections */ Cla1Prog : LOAD = CLA_PROG_FLASH, RUN = CLA_PROG_RAM, LOAD_START(_Cla1ProgLoadStart), RUN_START(_Cla1ProgRunStart), LOAD_SIZE(_Cla1ProgLoadSize), PAGE = 0, ALIGN(4) Cla1ToCpuMsgRAM : > CLA1_MSGRAMLOW, PAGE = 1 CpuToCla1MsgRAM : > CLA1_MSGRAMHIGH, PAGE = 1 /*.TI.ramfunc : LOAD = CPU_PROG_FLASH, */ GROUP { .TI.ramfunc { -l F021_API_F28004x_FPU32.lib} } LOAD = CPU_PROG_FLASH, RUN = RAMGS1 | RAMGS2, LOAD_START(_RamfuncsLoadStart), LOAD_SIZE(_RamfuncsLoadSize), LOAD_END(_RamfuncsLoadEnd), RUN_START(_RamfuncsRunStart), RUN_SIZE(_RamfuncsRunSize), RUN_END(_RamfuncsRunEnd), PAGE = 0, ALIGN(4) .scratchpad : > RAMLS7, PAGE = 1 .bss_cla : > RAMLS7, PAGE = 1 Cla1DataRam : > RAMLS7, PAGE = 1 .const_cla : LOAD = CLA_PROG_FLASH, RUN = CLA_PROG_RAM, RUN_START(_Cla1ConstRunStart), LOAD_START(_Cla1ConstLoadStart), LOAD_SIZE(_Cla1ConstLoadSize), PAGE = 0 CodeInfoFile : > HEADERINFO, PAGE = 0 } /* //=========================================================================== // End of file. //=========================================================================== */
此致、
Julia
您好!
有人能回答我的问题吗? 谢谢!
此致、
Julia
尊敬的 Julia:
过去一周我不在办公室。 对延迟答复表示歉意。
[引用 userid="486218" URL"~/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1131122/tms320f280049c-cpu-read-secured-cla-data-through-cla-to-cpu-msgram ]LS RAM 可以加密、因此 CLA 到 CPU 不能加密。 这种理解是否正确?[/引述]您的理解是正确的。
[引用 userid="486218" URL"~/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1131122/tms320f280049c-cpu-read-secured-cla-data-through-cla-to-cpu-msgram "]加密区域可以访问 CPU 到 CLA RAM、也就是说、加密 CLA 区域可以获取从 CPU 传输的数据
但 CPU 无法通过 CLA 到 CPU RAM 在 CLA 中获取加密数据
[/报价]下面我将根据我从您的问题中收集的任何内容进行回答。 如果您认为我未正确解释您的问题、请随时修改您的问题。
CLA 可以使用加密区域(LS RAM)获取从 CPU 到 CLA RAM 传输的数据。
CLA 到 CPU RAM 只能由 CLA 写入、而不能由 CPU 写入。
[引用 userid="486218" URL"~/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1131122/tms320f280049c-cpu-read-secured-cla-data-through-cla-to-cpu-msgram ]客户现在遇到这样的问题:当他们不使用 DCSM 时、代码运行正常、但在使用 DCSM 后、当代码未经解密而运行时、加密的 CLA 无法访问 CPU 到 CLA 的数据(按 DAC 输出的数据、输出为0)。 [/报价]我看到您使用术语"加密 CLA..." 您能否告诉我您是否将 CLA 称为外设(如果是、则您的理解不正确)。 LS RAM 是安全的、CLA 可以访问这些存储器。
此外、代码在没有解密的情况下运行时、您的意思是什么?
请分享已为程序配置的安全设置、以便对此进行进一步分析。
您好 Pramod、
"加密 CLA"意味着将安全的 LS RAM 分配给 CLA、抱歉我没有清楚地表达。 现在的问题是、当客户未设置密码时、代码运行良好、但是当客户设置密码时、CLA (被分配了安全 LS RAM)无法从 CPU 到 CLA (不安全)读取数据、客户使用 DAC 输出数据、但输出为0。
由于客户的政策、我无法披露 这部分安全设置代码、我已将代码脱机发送给您。
DAC 的初始化在 CPU 中进行配置、表示 DAC 输出值的变量将在 CPU 中累积、然后写入 CPU 到 CLA MSGRAM、然后由 CLA 读取。
此致、
Julia
此线程正在脱机处理、并将在解析查询后发布结论。
谢谢、此致
Pramod
Pramod、
该线程将被锁定。 是否有更新以关闭它?
Santosh、
我确定 了根本原因(将数据从不安全的存储器复制到安全存储器、当区域安全时不允许这样做)。 但是、如果问题得到解决、则会收到客户的一个消息。
谢谢、此致
Pramod
已确定根本原因。 应用中使用的 memcpy 函数实际上导致了从不安全的存储器到安全存储器的数据传输、当区域是安全的时、不允许这种传输。 这导致 CLA 配置不正确、因此应用程序无法运行。 一旦 memcpy 例程被移动到安全存储器、数据传输就会发生、而没有任何问题、应用程序就能够运行。
Julia、如有必要、请添加更多详细信息、如果没有其他问题、请将该主题标记为已解决。
谢谢、此致
Pramod