[参考译文] TMS320F28377D：TI driverlib 驱动程序文件固件完整性检查的校验和

器件型号：TMS320F28377D

工具/软件：

尊敬的先生：

当我在 TI 的驱动程序文件中添加注释时、我的校验和会发生变化、因此我们可以采取任何措施来避免这种情况

请帮帮我

此致

J.Muniniteesh

器件型号：TMS320F28377D

工具/软件：

嗨、我不熟悉在计算校验和时使用 TI 微控制器。如果我在应用层和驱动程序层中添加任何注释而我开发的这些注释不会影响校验和、但如果我添加或删除 TI 开发的 HAL 层(在 driverlib 中)中的任何校验和都会影响校验和、请告诉我有办法可以避免该问题

通常、在 HAL 层中添加注释不应影响其影响的校验和(固件完整性检查)、

我正在使用 CCS 以及 Uniflash 工具进行计算

此致

J.Muniniteesh

您好、

对延误表示歉意、今天是假期。 请允许我直至星期一查看该主题的详细信息并提供帮助。

此致、

马特

您好：

您是否使用了该线程中提到的校验和方法？  (19) TMS320F28377D：使用命令行计算校验和- C2000微控制器论坛- C2000μ︎ 微控制器- TI E2E 支持论坛

此致、

Delaney

您好、

我不是使用命令行方法在将十六进制文件刷写到微控制器后计算校验和、而是使用下图所示的计算校验和   

我的主要问题是、如果我在 driverlib 的 HAL 层(在下图中的器件文件夹下)中添加或删除任何注释 、那么校验和为什么会改变？

但是、当我在源文件夹下开发代码时、如果我添加或删除注释、校验和没有更改、结果保持不变是正确的 。请问 Uniflash /CCS 计算校验和的机制是什么

注意：-在上面器件下的屏幕截图文件中、是 TI 的 HAL 层、而源代码下的文件是我的应用层和驱动程序层   

此致

J.Muniniteesh

尊敬的  J.Muniniteesh、

完成 C2000校验和计算的方法是将闪存存储器中的所有16位数据相加、然后返回总和的低16位值。 为了使校验和不同、这意味着在添加注释时编程到闪存中的数据是不同的、这似乎有点奇怪、但也许这就是编译器/链接器的实现/优化方式。 不幸的是,我在这方面没有太多的知识,但我可以找到一些专家提供更多的背景,说明为什么数据会在添加注释行时发生变化。

此外、确认程序不同的一种方法是编译这两个程序、将其中一个程序加载到器件上、然后使用另一个程序执行独立的验证操作(即、点击 Verify Image 按钮)。 这将告诉您更改了哪个地址。

谢谢、

Ricky

尊敬的刘瑞基：

感谢您的答复、您是否请您的专家提供更多信息、说明在 TI 的 HAL 层添加行时数据会发生变化的原因

期待您的答复  

此致

J.Muniniteesh

我不知道你说什么...

Unknown 说：

如果我在代码的下一行中添加任何注释、则校验和正在更改

确切地更改了哪个文件？  请显示此更改之前和之后的代码。  每次复制并粘贴代码的文本。  请勿使用屏幕截图。

谢谢。此致、

-乔治

您好、George、

我想分享关于不同测试场景中的校验和行为的一些观察结果。 下面是我用于评估注释对 HAL 层中校验和值的影响的三个测试用例(特别是 TI 的 HAL 层文件driverlib)

例如、我将使用 cputimer_clearOverflowFlag 函数进行演示

测试案例1：-

void CPUTimer_clearOverflowFlag (UI_32 loc_base)
｛
断言(CPUTimer_isBaseValid (loc_base))；

/*设置 TCR 寄存器*/的 TIF 位

HWREGH (loc_base + CPUTIMER_O_TCR)|= CPUTIMER_TCR_TIF；
}

这个函数是从cputimer.c HAL 层(driverlib)中获取的,它是在没有任何附加注释的情况下编译的,  因此观察到校验和：0xF413

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

测试案例2：-

void CPUTimer_clearOverflowFlag (UI_32 loc_base)
｛
断言(CPUTimer_isBaseValid (loc_base))；

/*设置 TCR 寄存器*/的 TIF 位  /*below 语句用于清除溢出标志*/

HWREGH (loc_base + CPUTIMER_O_TCR)|= CPUTIMER_TCR_TIF；
}

--在现有注释后添加了一条内联注释, 校验和保持不变：0xF413与测试用例1相同

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

测试案例3：-

void CPUTimer_clearOverflowFlag (UI_32 loc_base)
｛
断言(CPUTimer_isBaseValid (loc_base))；

/*设置 TCR 寄存器*/的 TIF 位

/*below 语句用于清除溢出标志*/

HWREGH (loc_base + CPUTIMER_O_TCR)|= CPUTIMER_TCR_TIF；
}

-- 在新的一行上添加了新的评论 、校验和已更改：0xF41D、 与测试用例1和测试用例2不同。

为什么校验和发生变化？ 这仅发生在 driverlib 文件中、我指的是 TI 的 HAL 层、但不发生在由我开发的应用程序代码中？

此致

J.Muniniteesh

源文件的返回路径  CPUTimer_clearOverflowFlag 、 请按照 如何提交编译器测试用例一文中的说明进行操作。

谢谢。此致、

-乔治

尊敬的 George、请在下面找到 cputimer 文件.pp 文件、编译器和编译器版本的构建日志

器件系列：C2000、编译器版本为 TI v22.6.0.LTS

e2e.ti.com/.../cputimer.pp.txt

e2e.ti.com/.../software_5F00_build_5F00_logs.txt

感谢您的测试用例。  使用它、我创建了这个 diff。

它比较了编译器为函数生成的汇编代码  CPUTimer_clearOverflowFlag 。 在您提交源文件时、将从源文件生成左侧。  右侧从同一源代码生成、但添加了一行注释。   说明中没有任何区别。  所有差异都是注释或调试指令中的行号。  因此、校验和的差异不能与该函数的指令有所不同。  校验和是否可能会考虑调试段的内容？   

谢谢。此致、

-乔治

您好、George、  

那么、 编译器是否会考虑行号、这是我正确校验和被更改的原因？

此致、

J.Muniniteesh

编译器与计算校验和无关。  我怀疑计算校验和时会考虑行号。  但这是我看到的唯一变化,所以我指出了。

我没有 Uniflash、计算校验和等方面的专业知识  Lau Ricky 的最后一篇文章介绍了如何计算校验和、以及如何找到不同的地址。  你已经做到了吗？

谢谢。此致、

-乔治

J.Muniniteesh、

您手头上有2个编译程序吗？ 如果在 UniFlash 中加载一个、请选择另一个、然后点击"Verify Image"。 它应返回任何不同的数据/地址。 这可能有助于隔离在重新编译之间更改的代码。

谢谢、

Ricky

尊敬的 Lau Ricky：

我确实验证我收到了如下所示 pic 的错误...这是否意味着0x80000中的数据不同？  

此致

J.Muniniteesh

我认为"重叠段"消息意味着您选择的2个图像具有重叠段。  

在我描述的前一个过程中、您一次应该只在 GUI 中选择1个图像。 因此、您应该选择 Image1、加载它、然后在 GUI 中将其替换为 Image2、然后点击"Verify images"。

谢谢。

是的、我得到了如下响应

因此、 在0x82D49处存储器位置数据发生更改  

谢谢

J.Muniniteesh