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.
工具与软件:
大家好!
对于我们来说、USB 引导加载程序至关重要、因为它无需外部组件(如 SIC 或其他引导加载程序)并且易于与 PC 连接、这对用户界面非常重要。因此、我们正在 F28388D 上使用 USB 引导加载程序、但现在我们希望在器件上使用现有的引导加载程序并确保其安全、对我们而言、安全如下:
从而避免客户从闪存中读取我们的代码 、但是、对于上一代 DSP、我们曾使用 CSM、而对于 F28338D 上的本机 USB 启动加载程序、我们似乎不能使用 CSM、因为启动加载程序是硬编码的。 (这是正确的吗?)
为了实现这一目标、我们计划执行以下操作、请检查并告知我们是否合理、我们应该怎么做?
步骤:
这是可行的吗? BTW、目前我们只需要 CPU1即可使用该方法。
John
John、
以上流程将起作用、对于#3、我们需要获得二进制格式、并另存为.dat 下面是我们需要调用的十六进制实用程序指令:
"hex2000.exe -boot -b F28x7x_flash.out Loader_Test -o Loader_Test_Converted c2000.dat" (来自 C:\ti\c2000\C2000Ware_5_02_00_00\utilities\flash_programmers\usb_flash_programmer\中的 example.txt)
在安全闪存示例中、您需要做的只是将输出模式设置为二进制并启用-boot 开关、其余的应该是正确的。
如果右键单击工程并选择"properties"、将打开以下对话框、导航至 C2000 Hex 实用程序、然后按以下屏幕获得-boot
然后在此处将输出模式设置为二进制- b
您可以选择将文件扩展名从.bin 重命名为.dat、我不确定这是否重要
此文件可以传递到上述目录中提到的 USB 引导加载程序。
最后一点、在您的文章前面提到、但对于 F28338D 上的本机 USB 引导加载程序、我们似乎无法使用 CSM、因为引导加载程序已经硬编码。
这种说法是正确的、但我很好奇您对以前 C2000器件的体验是否有所不同、或者这是否来自不同的 MCU。
此致!
Matthew
您好、 MatthewPate、
感谢您的确认、我现在正在研究这个想法、我相信在1到2周内、我应该能够测试它并在此确认它是否有效或是否存在任何问题。
关于 CSM、是的、我们以前经常将 F28069与 CSM 一起使用、但是对于那个 DSP、USB 引导加载程序是不同的、且提供了源代码、但在 F28388中则更复杂。
谢谢
John
您好、 MatthewPate 、
在我们之前的讨论之后,我开始使用代码"boot_ex1_cpu1_cpu2_cm_secure_flash_cpu1"作为第一步,我对与 CPU2和 CM 相关的部分进行了注释,因为我希望它仅对 CPU1有效,但是,无论我做什么,代码都停留在永久循环中(在控制卡上 D1保持开启),显然 CPUBAC_calculate:
在此之后、D1保持完全亮起、不会闪烁。
我的其他观察:
-一次运气,代码通过身份验证和 LED 开始闪烁,但我不能重新创建的情况
请告知如何继续以及是否必须更改上述任何步骤。
John
您好、 MatthewPate 、
看看这个问题、您能看一下这个问题吗? 我们在执行这项任务的时间上比较紧。
感谢你能抽出时间。
John
John、
抱歉我的延迟、我将更频繁地查看该主题。 当您使用 CCS/JTAG 构建上述运行的示例时、您是否保留了示例中的 hex2000设置、因为我们从 CCS vs USB 加载映像、因此很需要执行此操作。 我只是想确认我们尚未进行这些更改。
只与 DCSM/EXE 相关;闪存区域中是否存储了任何常量、或者您代码其他部分会试图访问该区域内容的任何原因? 只有对于只有代码的段、我们才希望启用只执行保护、所有数据读取将被阻止从这些区域读取。
我们可以做的一件事是增加链接指针、这会将所有 DCSM 功能重置为其原生擦除状态、从而关闭 EXE、以查看是否是问题所在。
此致!
Matthew
您好、W ü@MatthewRate、
很抱歉、这周我一直在为顾客旅行...
抱歉我延迟了、我将更频繁地查看此主题。 当您使用 CCS/JTAG 构建上述运行的示例时、您是否保留了示例中的 hex2000设置、因为我们从 CCS vs USB 加载映像、因此很需要执行此操作。 只是想确认我们尚未进行这些更改。
我纯粹运行的是 TI 示例代码、因此根本不做任何更改、如前所述、只对代码的一小部分进行了注释、编译器中没有其他更改。
仅关于 DCSM/EXE;闪存区域中是否存储了任何常量、或者您代码的其他部分出于任何原因会尝试访问该区域的内容? 仅对于只有代码的段、我们才希望启用只执行保护、从这些区域中将阻止所有数据读取。
当我运行 TI 的示例代码时、我认为应该没有问题。
我们可以做的一件事是增加链接指针、这将把所有 DCSM 功能重置为其本机擦除状态、这将只关闭 EXE 以查看是否是问题所在。
您能解释一下如何做到这一点吗? --这是否也有必要在示例代码上完成? 我在这里有点儿困惑。
提前感谢您的帮助。
John
尊敬的 John:
您能否确认您未修改 USER OTP 中的 CMACKEY 值? 可以在 SysConfig 中启用 EXEONLY 时执行此操作。
谢谢!
Luke
Luke、您好!
绝对不是、示例中的任何设置没有变化、CMACKEY 保持不变、如前所述唯一的更改是在 CPU2和 CM 的代码上添加注释。
运行示例时的行为与未更改 SysConfig 中的 EXEONLY 时的行为完全相同。 (这如何会成为问题?)
只有一个区别,我把我的控制卡上的时钟更改为20MHz (通过更换相应的电阻器),所以我必须添加下面的宏,这是否会影响任何东西?
John
您是否有可能在您结束时查看此内容? 只是为了确保一旦把时钟设置为20Mhz、代码是否有任何错误、或者如果这完全是一个不同的问题--我们没有时间来了解原因。
谢谢您的回答。
John
尊敬的 John:
我明天会下班、但周二又回来了。 我对这一问题的原因有另一个想法。
您是否编程了自定义 CSM 密码并启用了 EXEONLY? 如果是、这将导致 EXEONLY 段阻止数据读取和写入、除非在每个器件复位后解锁 DCSM。 这可能导致 USB 编程器在具有 EXEONLY 保护的代码区域中不对任何内容进行编程、从而导致 CMAC 身份验证失败。
通过更新链接指针、您是否能够在没有 exeonly 保护的情况下进行测试? 该操作会将区域选择块中的设置恢复为默认值并禁用 EXEONLY。
谢谢!
Luke
Luke Jones 、您好!
您是否编程了自定义 CSM 密码并启用了 EXEONLY?
我正在使用默认 CSM 密码、因此还未进行任何更改。
您是否能够通过更新链接指针在没有外部保护的情况下对此进行测试? 这会将区域选择块中的设置恢复为默认值并禁用 EXEONLY。
您能告诉我该怎么做吗?
John
尊敬的 John:
由于您使用的是默认 CSM 密码、因此 EXEONLY 设置不适用、因此无需更改此设置。
您能否确认 boot_ex1_flash_hex_lnk_cpu1.cmd 与的值是否匹配
#define CMAC_AUTH_START_ADDRESS
#define CMAC_AUTH_END_ADDRESS
#define CMAC_AUTH_TAG_ADDRESS
main.c 文件中呢?
您能在不加载 USB 的情况下尝试测试吗? 换句话说、您可以进行测试、只是通过 JTAG 将应用程序代码上传到器件中、然后执行 EMU 引导配置来尝试安全启动吗? USB 引导加载程序可能会在对闪存进行编程时修改应用程序、而在直接通过 JTAG 上传时闪存与应用程序代码不同。 如果仅使用 JTAG 上传应用代码、则应能够成功执行安全启动。 我也可以在我的终端尝试此操作以进行确认。
谢谢!
Luke