[参考译文] TMS320F28377S：固件更新闪存写入观测-空十六进制文件地址错误509，连续0x0000不写入空十六进制文件地址

Yogesh、  

对于引导加载程序、您是否使用 C2000Ware 中提供的闪存内核？ 您的应用是否符合128位边界？ 如果不是这种情况、写入闪存可能不会按预期发生。  

我将向十六进制实用程序专家询问您的第二个问题、然后返回给您。  

谢谢、  

Anu

感谢 Anu 的回复。

我在查询中提到的引导加载程序是位于扇区 A 中的单独代码。在执行引导加载程序代码后、它会跳转到主应用程序所在的 K 扇区的起始地址。

我们的闪存写入操作是128位对齐的。

我们的十六进制文件具有从 0xB8000到0xBD7A8 (扇区 K、L、M)的非空地址空间。  十六进制文件具有从 0xBD7A8 到0xBDFFA (扇区 M)的空地址空间。  在固件更新期间、控制器用于接收具有 K、L、M 扇区地址的十六进制文件数据。 控制 器、用于通过偏移0x36000来计算扇区 B、C、D 的地址并将其写入闪存。  

如我们的查询中所述、对于非空地址空间、所有写入操作都能正常工作。 对于地址0x87EA8 (十六进制文件中为0xBDEA8且属于空地址空间)上的8字写入、我们遇到509个错误。  0x87EA8 mod 8 = 0、因此它是128位对齐地址。 我们可以在该地址写入8个字。

我们 在 TMS320F28377S 和 TMS320F28379D 上多次观察到相同的行为。

正如我在查询中提到的、在将十六进制文件写入 B、C、D 扇区时、 对于十六进制文件地址0xBD966和更高的 地址为空 地址空间、 0x000数据不会写入到存储 器、而是保留到0xFFFF。 我们在"Memory"窗口中观察到了相同的情况。 API 未给出任何错误。  对于空地址空间 0xBD7A8至 0xBD966、0x0000字写入工作正常。

因此、看起来将连续0x0000写入闪存是上述观察结果的路由原因。  

请提供您对相同和可能的观察方法的看法。

此致...

Yogesh

Yogesh、  

我将与一名员工一起回顾您的问题、并在下周之前回复您。  

有几个问题-您遇到的509个错误是否有枚举值？ 遇到此错误时、您能否共享正在使用的闪存 API 函数？  

十六进制实用程序使用的命令是什么？ 您可以共享吗？

谢谢、  

Anu

谢谢 Anu、

与509关联的枚举为 Fapi_Error_AppelincorrectDataBufferLength。

我们在 Fapi_DataOnly 模式下使用'Fapi_issueProgrammingCommand'

为了生成十六进制文件、我们使用具有 以下配置的 hex.cmd 文件

-image
-memwidth 16.

ROM
｛
FW_IMAGE：
origin = 0x0B8000、length = 0x00584D、romwidth = 16
文件=｛fwImage.hex｝
｝

如上所述、我们将调整'length'以避免十六进制文件中出现空地址空间。 寻找克服十六进制文件中空地址空间的简单选项

此致...

Yogesh

谢谢 Yogesh、下周再见。

Yogesh、

添加几条注释。

当程序命令的"给定起始地址+给定长度"从128位对齐的段中退出时、会发生 Fapi_Error_OccasIncorrectDataBufferLength。  这意味着起始地址+长度不在具有起始地址的128位段中。  当您从闪存 API 中获得此错误时、请检查您为实例传递的长度。

API 不会阻止地址 0xBD966及更高版本的程序。  您可以向我们发送一个特定的测试用例以进行复制。  从我们的角度来看、我们看不到任何问题。  请检查此处的起始地址和长度。

我将让 Anu 继续与您进行进一步的讨论。

谢谢、此致、
Vamsi

您好、Vamsi、

感谢您的反馈。

我们正在创建测试用例、我们可以将其与您分享。 此外、我们还将重复我们多次面临的问题、以了解问题的确切模式或根本原因。

此致...

Yogesh

我想了解与该空空间对应的是什么。  为了让我能够做到这一点、请提交链接器映射文件。  它通常与 CCS 工程具有相同的名称、但文件扩展名为.map。  请将其放入 zip 文件中。  然后将该 zip 文件附加到您的下一个帖子。

谢谢、此致、

乔治

你(们)好  

感谢您的回复。  

很抱歉我的回复很晚。

如前所述、我们使用 hex.cmd 实用程序 来生成 hex 文件、如下所示。

－－图像
-memwidth 16.

ROM
｛
FW_IMAGE：
origin = 0x0B8000、length = 0x006000、romwidth = 16
文件=｛fwImage.hex｝
｝

我们配置为为为为 K、L、M 扇区生成代码的链接器文件。

因此 ，对于 hex.cmd 实用程序，我们将 K 扇区的起始地址和 K、L、M 的长度一起传递为0x6000。

生成的用于为非空间地址区域填充0x00的十六进制文件。

为了避免0x00填充、我们使用调整长度= 0x006000。

我们正在寻找在不 更改 hex.cmd 实用程序中的字段长度或使用其他一些选项的情况下生成不带0x00填充的十六进制文件的选项。

您仍然需要地图文件、请告诉我。 明天我将与大家分享同样的内容

谢谢。。。

Yogesh。

是的、我仍然需要映射文件。  谢谢！

乔治

尊敬的乔治：

查找以下地图文件供您参考。

e2e.ti.com/.../Machine_5F00_F28377S.zip

请为我们提供可能的解决方案、

• 以避免在十六进制文件的末尾填充0x00数据
•  在十六进制文件末尾填充0xff、而不是0x00数据

正如我们在本帖子开始时提到的那样、我们仍然面临着这个问题。 简称为以下问题。

• 十六进制文件具有活动地址的非零数据、 以及位于十六进制文件末尾的非活动地址的零填充数据
• 作为固件更新的一部分、通过串行方式接收每行十六进制文件、并在保留扇区中写入相同的十六进制文件。
• 写入 活动地址的数据工作正常
• 为非活动地址结果写入数据(0x00)闪存内容保持0xFF、没有任何闪存 API 错误。 几次写入后、闪存 API 返回无效长度错误。

我们尝试使用所编写的附加函数来模拟错误   

• 活动地址的非零数据
• 非活动地址为零数据

e2e.ti.com/.../TestWrtiteToFlash.c

该函数正常工作、不会像我们在上面提到的那样提供错误。

我们的应用程序代码会在函数基础上更新通过串行方式接收到的命令参数。 这是唯一的区别。

noOfWordsToWrite
 lflashWriteAddress；
flashWRDataBuf

因此，为什么“非活动地址的零数据”失败，我们仍在进行同样的工作。

请向我们提供错误的可能原因以及诊断问题的可能方法。

谢谢。。。

Yogesh

尊敬的乔治：

感谢您的回复。 它解决了生成具有0xFFFF 填充和不填充的十六进制文件的要求。

对于与闪存相关的查询、我将在我们一侧经过几次实验后重新打开新 TT。

此致...

Yogesh