[参考译文] TMS320F2800157：TMS320F2800157

尊敬的 Samuel：

1.

我认为安全引导应用手册中的以下要求仅适用于使用安全闪存引导模式的情况：

"使用 LOCATION pragma 为 CMAC 黄金标签指定预期身份验证范围内的地址。 对于 CPU1/CPU2、此地址必须为入口地址+ 2、对于 CM、此地址必须为入口地址+ 4。"

由于您 直接调用 calculateCMAC API、您可以指定标签的位置：

ApplicationCMACStatus = CPU1BROM_calculateCMAC (CMAC_AUTH_START_ADDRESS、CMAC_AUTH_END_ADDRESS、CMAC_AUTH_TAG_ADDRESS)；

bootROM 的安全闪存引导函数通过不可修改的硬编码参数调用此 API、因此它不知道您将标签放置在何处、因此应用手册会指示您使用 LOCATION pragma 根据所选的安全闪存引导模式将其放置在预定义的地址。

2.

您是否因为中断而出现超时错误：

3.

由于这是一个安全 ROM 函数、我无法访问代码来创建有关该函数如何工作的成熟流程图、但应用手册提供了以下流程图：

此流程图旨在反映 calculateCMAC 函数。 它适用于安全闪存启动功能和 calculateCMAC API。

如果您有其他问题、请告诉我。

谢谢！

Luke

您好 Luke：

感谢您的答复。

1.我们知道、 如果未使用安全闪存引导模式、我们可以指定标签的位置。 如果 CMAC 位于身份验证区域内、如何计算 CMAC；如果 CMAC 位于身份验证区域外、如何计算 CMAC？

2.当我们调用 CPU1BROM_calculateCMAC BootROM API 时、返回值为0xFFFFFFFF、我认为在 CPU1BROM_calculateCMAC 执行期间没有闪存擦除/写入操作、为何需要禁用中断？

3.我们根据指南生成.hex 文件,但.hex 文件不是英特尔标准的十六进制格式,见下文,所以你能解释如何分析.hex 文件吗?

%4E62F800080000004848E8FFFFFFFFFFFFFFFFFFFFFFFF0043003A002F0057006F0072006B002F
%4E6D780008001000300031005F00500072006F006A006500630074002F00300032005F00450047
%4E6E08000800200053004D002F00300034005F0054006F0075006300680020005300420057002F
%4E60380008003000560065006E00750073002F0042006F006F0074006C006F0061006400650072
%4E606800080040002F00530065006300750072006900740079005F0042006F006F0074002F004A
%4E6C68000800500044005F00500042004C005F0046003200380030003000310035005F00560030
%4E6ED8000800600033002F00530044004B002F006400650076006900630065002F006400720069
%4E6E0800080070007600650072006C00690062002F00630061006E002E0068000000000043003A
%4E6FA800080080002F0057006F0072006B002F00300031005F00500072006F006A006500630074

尊敬的 Samuel：

1.我已经请我们的一位引导 ROM 专家来澄清一下

2.根据我对安全 ROM 函数规范的解读、如果在安全 ROM 函数执行过程中发生中断、则会发生复位。 您是否可以探测 XRSn 引脚以验证是否未发生复位？ 返回值是否始终为0xFFFFFFFF、或者禁用中断后您是否会得到不同结果？

3.我将与我们的十六进制实用程序专家讨论此问题、看看是否有其他方法来查看.hex 文件。

谢谢！

Luke

Luke、您好：

我还有一个关于安全启动的问题、该 MCU 需要大约400ms 来在安全启动模式下对前16K 区域进行身份验证、我认为时间很长、可能对于汽车要求来说不可行、因为客户要求我们在上电后150ms 内首先发送 CAN 数据、那么除了更改 MCU 之外、您是否有其他解决方案或解决方案？

谢谢你。

/BR

塞缪尔

尊敬的 Samuel：

您使用的不是安全闪存启动模式。 只使用 calculateCMAC API？ 如果是这样、我认为计时将更接近20ms、因为算法将关闭 PLL。 客户的 SYSCLK 频率是多少？

谢谢！

Luke

Luke、您好：

回复如下：

根据我对安全 ROM 函数规范的理解、如果在执行安全 ROM 函数期间发生中断、则会发生复位。 您是否可以探测 XRSn 引脚以验证是否未发生复位？ 返回值是否始终为0xFFFFFFFF、或者禁用中断后您是否会得到不同结果？

我探测 XRSn 引脚、它保持高电平。 但通过发送特殊的 CAN 帧、软件似乎异常地重新启动；  

您使用的不是安全闪存启动模式。 只使用 calculateCMAC API？ 如果是这样、我认为计时将更接近20ms、因为算法将关闭 PLL。 客户的 SYSCLK 频率是多少？

我们使用 SYSCLK 频率为120MHz (TMS320F2800157)、 我们不使用安全闪存引导模式、并使用 API 接口计算前16k 数据(0x80000~0x8004000)、时间约为57ms、计算第二个16k 数据(0x800000~0x88000)、时间约为63.2ms。 根据您的说法、这与20ms 是不一致的。

还有许多问题仍然如下:

1. 我们知道、 如果未使用安全闪存引导模式、我们可以指定标签的位置。 如果 CMAC 位于身份验证区域内、如何计算 CMAC；如果 CMAC 位于身份验证区域外、如何计算 CMAC？

2. 我们根据指南生成.hex 文件,但.hex 文件不是英特尔标准的十六进制格式,见下文,所以你能解释如何分析.hex 文件吗?

3. 是否使用 API 接口( CPU1BROM_calculateCMAC )可以被多次调用？ 如果我们想多次使用该接口、该如何实现？

4. 在非安全闪存启动模式下、我们是否只定义 CMAC_ALL？ 如果我们未定义 cmac_sb_1、编译器可以报告警告。

谢谢你。

/BR

塞缪尔

尊敬的 Samuel：

我今天不会上班、明天我会回复。

谢谢！

Luke

尊敬的 Samuel：

复位问题-

[报价 userid="556635" url="~/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1337026/tms320f2800157-tms320f2800157/5100072 #5100072"]根据我对安全 ROM 函数的规范的阅读、如果在安全 ROM 函数执行过程中发生中断、将发生复位。 您是否可以探测 XRSn 引脚以验证是否未发生复位？ 返回值是始终为0xFFFFFFFF 还是在禁用中断时您会得到不同结果？[/QUOT]

这是安全违例复位、不会在 XRSn 引脚上传播。 用户可以检查 RESC 寄存器中 SCCRESETn 位的状态 (表4-71。 RESC 寄存器字段说明)以了解该复位是否有效。  

[报价 userid="556635" url="~/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1337026/tms320f2800157-tms320f2800157/5100072 #5100072"]我们使用 SYSCLK 频率为120MHz (TMS320F2800157)、 我们不使用安全闪存启动模式并使用 API 接口计算第一个16k 数据(0x80000~0x84000)、时间约为57ms、计算第二个16k 数据(0x800000~0x88000)、时间约为63.2ms。 这与您所说的20ms 不一致。

根据您在表中提到的、20ms 时间是 CPU 以200MHz 的频率运行的时间。 这是为最佳情况和不同 CPU 帧提供的通用表、需要相应地进行缩放。 影响此时间的另一个因素将是闪存等待状态和代码执行位置。 您是否从闪存运行它？  

Unknown 说：

1.  如我们所知、 如果我们未使用安全闪存引导模式、我们可以指定标签的位置。 如何计算 CMAC (如果 CMAC 位于身份验证区域内)以及如何计算 CMAC (如果 CMAC 超出身份验证区域)？

我们需要咨询我们的软件团队专家、我们会尽快与您联系。  

Unknown 说：

2.  我们根据指南生成.hex 文件,但.hex 文件不是英特尔标准的十六进制格式,请参阅以下内容,所以您能解释如何分析.hex 文件吗?[/QUOT]

您是否打算在这里附加一些东西？ 还有什么意思是"分析十六进制文件"?

Unknown 说：

3.  是否使用 API 接口( CPU1BROM_calculateCMAC )可以被多次调用？ 如果我们想多次使用此接口、如何实现？

应该可以多次调用它。 第二次调用时、您是否遇到了任何问题？ 如果您能提供有关所面临问题的更多详细信息、将会有所帮助。  

Unknown 说：

4.  在非安全闪存启动模式下、我们是否仅定义 CMAC_ALL？ 如果我们未定义 cmac_sb_1、编译器可以报告警告。[/QUOT]

对此查询不是很清楚。 为什么非安全闪存启动需要 CMAC？  

此致、

Vivek Singh

[/quote]

Vivek 您好：

感谢您的答复。

[报价 userid="19481" url="~/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1337026/tms320f2800157-tms320f2800157/5103700 #5103700"]

复位问题-

塞缪尔·李说:

根据我对安全 ROM 函数规范的理解、如果在执行安全 ROM 函数期间发生中断、则会发生复位。 您是否可以探测 XRSn 引脚以验证是否未发生复位？ 返回值是否始终为0xFFFFFFFF、或者禁用中断后您是否会得到不同结果？

这是安全违例复位、不会在 XRSn 引脚上传播。 用户可以检查 RESC 寄存器中 SCCRESETn 位的状态 (表4-71。 RESC 寄存器字段说明)以了解该复位是否有效。  

[报价]

我们将检查 SCCRESERn 位的状态。

[报价 userid="19481" url="~/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1337026/tms320f2800157-tms320f2800157/5103700 #5103700"]

塞缪尔·李说:

我们使用 SYSCLK 频率为120MHz (TMS320F2800157)、 我们不使用安全闪存引导模式、并使用 API 接口计算前16k 数据(0x80000~0x8004000)、时间约为57ms、计算第二个16k 数据(0x800000~0x88000)、时间约为63.2ms。 根据您的说法、这与20ms 是不一致的。

根据您在表中提到的、20ms 时间是 CPU 以200MHz 的频率运行的时间。 这是为最佳情况和不同 CPU 帧提供的通用表、需要相应地进行缩放。 影响此时间的另一个因素将是闪存等待状态和代码执行位置。 您是否从闪存运行它？  

[报价]

是的、我们的软件从闪存运行。 如您所说、我们首先在120MHz 中对16K 进行身份验证是正常的。

 

[报价 userid="19481" url="~/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1337026/tms320f2800157-tms320f2800157/5103700 #5103700"]

塞缪尔·李说:

1. 我们知道、 如果未使用安全闪存引导模式、我们可以指定标签的位置。 如果 CMAC 位于身份验证区域内、如何计算 CMAC；如果 CMAC 位于身份验证区域外、如何计算 CMAC？

我们需要咨询我们的软件团队专家、我们会尽快与您联系。  

[报价]

确定、正在等待您的响应。

[报价 userid="19481" url="~/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1337026/tms320f2800157-tms320f2800157/5103700 #5103700"]

塞缪尔·李说:

2. 我们根据指南生成.hex 文件,但.hex 文件不是英特尔标准的十六进制格式,见下文,所以你能解释如何分析.hex 文件吗?

您是否打算在这里附加一些东西？ 还有什么意思是"分析十六进制文件"?

[报价]

我们需要实施测试仪来解析生成的.hex 文件、因此我们需要有关文件的详细格式信息。

[报价 userid="19481" url="~/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1337026/tms320f2800157-tms320f2800157/5103700 #5103700"]

塞缪尔·李说:

3. 是否使用 API 接口( CPU1BROM_calculateCMAC )可以被多次调用？ 如果我们想多次使用该接口、该如何实现？

应该可以多次调用它。 第二次调用时、您是否遇到了任何问题？ 如果您能提供有关所面临问题的更多详细信息、将会有所帮助。  

[报价]

根据指南、我们只需要定义 cmac_all 符号、然后我们可以使用 hex2000生成 cmac、因此如果我们要多次调用、我们不能使用 hex2000生成 cAMC。

[报价 userid="19481" url="~/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1337026/tms320f2800157-tms320f2800157/5103700 #5103700"]

塞缪尔·李说:

4. 在非安全闪存启动模式下、我们是否只定义 CMAC_ALL？ 如果我们未定义 cmac_sb_1、编译器可以报告警告。

对此查询不是很清楚。 为什么非安全闪存启动需要 CMAC？  

[报价]

我们想要使用安全闪存启动模式、但首先进行16K 身份验证需要400ms、时间非常长、因此我们决定使用非安全启动模式对16K 数据进行身份验证。

嗨、Samuel、

是的、我们的软件从闪存运行。 如您所说、我们首先在120MHz 中对16K 进行身份验证是正常的。

57ms 和63.2ms 计时对于您的应用来说足够快吗？ 如果不是、是否可以从 RAM 调用 calculateCMAC API？

确定、正在等待您的响应。

我们软件团队的回应：

"当他们使用十六进制工具生成其代码的 CMAC 签名时、需要遵循以下说明：

• 如果 CMAC 签名在要进行身份验证的区域内、则应在运行 HEX 工具之前填充0xFFFFFFFF。 CMAC 算法在计算前使用0xFFFFFFFF 屏蔽签名区域。 十六进制工具不知道这一点、并使用任何签名位置来计算签名。
• 如果签名超出范围、则没有问题。"

我们需要实施测试仪来解析生成的.hex 文件、因此我们需要有关文件的详细格式信息。

您可以根据 HEX 实用程序指南以 Intel 标准格式生成输出：

根据指南、我们只需要定义 cmac_all 符号、然后我们可以使用 hex2000生成 cmac、因此如果我们要多次调用、我们不能使用 hex2000生成 cAMC。

我们将与 SW 团队核实并就此与您联系。

我们想要使用安全闪存启动模式、但首先进行16K 身份验证需要400ms、时间非常长、因此我们决定使用非安全启动模式对16K 数据进行身份验证。

您是否测试过安全闪存启动模式需要多长时间？ 400ms 值基于 F2838x。

根据我们的软件专家、如果未使用安全闪存启动、您的代码将变得不安全、因为您将失去信任根。 您是使用安全闪存引导模式来防止代码被篡改还是仅为了确保闪存已正确编程？

Luke、您好：

[报价 userid="529193" url="~/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1337026/tms320f2800157-tms320f2800157/5106871 #5106871"]

您是否测试过安全闪存启动模式需要多长时间？ 400ms 值基于 F2838x。

根据我们的软件专家、如果未使用安全闪存启动、您的代码将变得不安全、因为您将失去信任根。 您是使用安全闪存引导模式来防止代码被篡改还是仅为了确保闪存已正确编程？

[报价]

如 也就是说、在安全启动模式下、CPU1 在 INTOSC 10MHz 上首先对16KB 数据进行身份验证、并且需要大约400ms。对于 F2800157、INTOSC 也是10MHz、所以我认为时间是相似的。

‘s 必须使用非安全引导模式、因为400ms 不符合客户的要求(它们要求我们在150ms 后首先发送 CAN 帧)、即使我们的代码可能已被篡改。

对于这一点,我们的概念是以下的,你有建议或更好的解决方案?

Unknown 说：

57ms 和63.2ms 计时对于您的应用而言是否足够快？ 如果不是、是否可以从 RAM 调用 calculateCMAC API？[/QUOT]

是的、如果我们将 calculateCMAC API 放置到 RAM 中并进行调用、时间可能会更短、但我认为这不是关键的关键块点。 应用程序大小超过60KB、需要更多时间来验证应用程序。

/BR

塞缪尔

尊敬的 Samuel：

对于您所看到的速度(大约60ms 来验证16KB 的闪存)、无法在150ms 内验证所有60KB 的应用程序代码。 为了满足此要求、您需要在39.6ms 内验证16KB 的闪存。 理想情况下、根据 F280015x 时钟频率(120MHz)和安全启动应用手册中提供的数据、只需33ms 即可验证16 BK。

您是否通过 DCSM 保护内存？ 安全 ROM 函数的目的是在不取消保护代码的情况下计算安全存储器上的 CMAC 标签。 如果这不是必需要求、那么您是否可以在应用程序代码上代替计算 CRC？ 这可能比调用 calculateCMAC API 更快。

我将尝试在我这边复制这一点、以查看我是否可以满足39.6ms 的要求。  

谢谢！

Luke

Luke、您好：

Unknown 说：

我将尝试在我这边复制这个问题、看看我是否能满足39.6ms 的要求。  [报价]

您有更新吗？

此外、您是否有更多有关安全启动和安全更新的文档、我们可以参考。

谢谢你。

/BR

塞缪尔

尊敬的 Samuel：

遗憾的是、我一直忙于处理其他客户问题。 我会在本周结束前回复您。

谢谢！

Luke

尊敬的 Samuel：

很抱歉、本周我会用我的测试结果与您联系。

谢谢！

Luke

尊敬的 Samuel：

我仍在调查此问题、一旦能够成功测试此问题、我将作出回应。

谢谢！

Luke

期待您的答复。

/BR

塞缪尔

尊敬的 Samuel：

我将离开办公室到六月底,我将在我回来后测试这个.

谢谢！

Luke