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
Santosh、
我确定 了根本原因(将数据从不安全的存储器复制到安全存储器、当区域安全时不允许这样做)。 但是、如果问题得到解决、则会收到客户的一个消息。
谢谢、此致
Pramod
已确定根本原因。 应用中使用的 memcpy 函数实际上导致了从不安全的存储器到安全存储器的数据传输、当区域是安全的时、不允许这种传输。 这导致 CLA 配置不正确、因此应用程序无法运行。 一旦 memcpy 例程被移动到安全存储器、数据传输就会发生、而没有任何问题、应用程序就能够运行。
Julia、如有必要、请添加更多详细信息、如果没有其他问题、请将该主题标记为已解决。
谢谢、此致
Pramod