[参考译文] TMS570LS1114：使用 TI FEE 01.19.03时 FEE 数据丢失

Matthias、您好！

我已将您的帖子转发给我们的软件团队、以便他们能够解决您就收费运营所提出的问题。

[引用 user="Matthias "[/quot]

当块的大小发生变化时-例如、在软件更新过程中、块大小未被正确检测到。

例如、在旧软件版本中、我们有一个40字节的块、而在较新软件版本中、该块的大小增加到了48字节。 在 TI_FeeInternal_UpdateBlockOffsetArray 期间、使用配置中的大小(48字节)、而闪存中的块实际上更小(40字节)。 这会导致下一个块偏移计算错误、进而导致块大小被误解。 这意味着它是"随机"的、搜索之后的块-可能会跳过块。 这些块的数据仍在闪存中、但不会被解释。

如果我知道 FEE 配置文件中的块大小发生了变化吗？ 我不确定 FEE 驱动器是否支持更改块大小。 我需要再次检查。

[引用 user="Matthias "[/quot]

我们看到的第二个问题与写入块期间的电源切断有关。

当块处于启动程序块(0xFFFFFFFFFF0000)状态时、下一个块的偏移量计算似乎不正确。 我附加了一个转储费。

在偏移量0x8B0处、您可以找到处于编程状态的块(块 ID 0x607)。 块大小(0x38)已经被写入-然而在下一个块的正确偏移(0x900)处、其它块不是新的块。 似乎下一个块从0x8D0开始-在处于编程状态的块开始之后是32字节。 这似乎不是正确的行为-因为无法知道是否已在该地址写入从0x8B0开始的块的数据-因此可能已经跳过了。

/cfs-file/__key/communityserver-discussions-components-files/312/6165.iccpd4_5F00_1115.zip

我们需要 ti_fee_cfg.c / ti_fee_cfg.h 文件信息来解码该二进制文件。 请将其发送给我们。 如果您无法在此处发布、请将其作为私人邮件发送给我。   

您好、Prathap、

我已向您发送了一个附带配置的 PM。

此致、Matthias

我们已确定 TI_FeeInternal_PollFlashStatus 可能存在的问题。 在当前实现中、函数在旧版本中的更多位置被调用。 该函数具有一个上限为0xFFFFFF0000U 的循环。

在最坏的情况下、这可能无法及时返回。

您能给我们提供一些更多信息、说明为什么需要进行轮询-这是否应该由 FEE 状态机处理、以便不需要轮询？ 闪存过程中是否存在需要对 TI_FeeInternal_PollFlashStatus 进行新调用的问题？

您好、Matthias、

在特定闪存组(此处为组7)上的任何活动闪存模块操作(如擦除、编程、验证等活动命令)期间、对该组的任何读取或写入操作最终都会使您的系统停止。 在这里、STALL 意味着 CPU 暂停、中断被冻结...
因此，我们必须避免陷入这种情况，因为这比定期轮询延迟更重要。

调用 TI_FeeInternal_PollFlashStatus 只是为了避免这种情况。 在较旧版本的驱动程序中、我们错过了一些允许出现在上述情况下的小窗口的位置。 在最新版本1.19.03中、我们解决了这一差距。

我不认为这是问题、因为除非闪存硬件存在实际问题、否则我们永远不会达到上限。 通常、对于这些类型的问题、通过窗口式看门狗或 RTOS 任务优先级进行监控。

回到原始问题  

问题1：FEE 块数据长度变化....

不建议在块写入闪存组后更改块长度、FEE 驱动器自然不支持它(有权变措施、但它相当麻烦。 我稍后会讨论这个问题。 如果您真的需要)。

正如您已经指出的那样，在 FEE Init 期间，在解析有效块时，块偏移地址信息从配置文件(48字节-新)中被操作。 如果 FEE 扇区数据已采用旧配置(40字节)、自然会跳过下一个块标头、最终跳过该块。

权变措施1：

现在：如何更改块大小(TI 强烈建议不要更改、请提前修复所有大小、一旦写入、就不应更改)

1) 使用旧软件(FEE 配置)时、请确保您阅读 特定块(例如块10)、必须更改数据长度。

2) 2)旧软件无效块10。

3) 3)启动虚拟扇区复制、以便仅有效块移动到另一个虚拟扇区、并将该虚拟扇区设置为活动。  

  如何启动虚拟扇区副本？ 是否有单独的 API？

  a)没有单独的 API、但继续写入除10个块以外的任何块、以便到达当前活动虚拟扇区的末尾、进一步写入将启动复制操作。

4) 4)新的活动虚拟扇区将具有除块10以外的其他块。

5) 5)使用新的 FEE 配置(块10数据长度已更改)更新您的软件、

6) 6)执行 FEE Init、然后写入块10。

7) 7)从这里一切都很顺利...

同样、TI 建议提前冻结块配置、不要在产品过程中更改它。 添加新块更容易、但按照上述步骤更改块配置很困难...  

权变措施2.

1) 1)备份所有块数据、将其存储在闪存中

2)擦除/格式化 FEE

3) 3)放置新软件初始化并恢复块数据...

 

问题2：写入块期间断电。

正如我提到过的 、块大小是从配置文件中解释的。

问题是写入块时使用的 FEE 配置文件和执行的当前 FEE 初始化操作是相同的。 如果答案是不同的配置文件、则可能会出现这种类型的问题、如果相同的配置文件、但问题如上所述、则我们必须深入探讨。

可以确认吗？  

问题1 -块大小)

为什么在闪存中存在不同信息时使用配置大小-我们通过始终使用闪存中的大小为问题准备了一个修复方法。 以前未配置的块也是如此、因此不会造成问题。 唯一的问题是、当我们读取一个块并且应该读取的大小与当前配置的大小不同时、我们应该怎么办？ 当前、如果在更新后所有数据(48字节)或仅部分数据(40字节)被读取、我们将不会获取信息。 这意味着我们无法在上层软件中做出相应的反应。 定义的大多数块都是静态大小的-问题仅限于少量块、这些块中包含的数据结构可能会在软件版本之间更改大小。

问题2 -在闪存操作期间复位)

这里的问题是、闪存驱动程序不会完成块写入-在某些情况下甚至不会在标头内完成8字节写入。 目前没有信息显示报头是否有效-只有一个状态"启动程序块"、当报头和数据都被写入时、该状态会保留。 这意味着在这种情况下、我们无法使用标头的大小-实际上、我们甚至无法使用块 ID、因为它可能是错误的。 在我看来、需要有另一个状态-类似于"已写入标头"、以确保标头中的数据有效且可用。 我们针对这种情况的权变措施是将到目前为止发现的所有数据复制到新扇区并擦除损坏的扇区。

问题3 - TI_FeeInternal_PollFlashStatus)

幸运的是、我们正在使用看门狗、但仍然使用看门狗、这种行为并不理想。 是否不能在必要时仅轮询闪存状态几次并离开 TI_FEE 主功能？ TiFee 状态机应处理在下一次调用 TiFeeMainFunction 时继续执行当前作业。 我们针对此问题的解决方法是将 TiFee 与自己的任务分开。

问题4 -初始化期间无错误处理

初始化期间有一些情况不会作为错误处理、但闪存驱动程序会尝试继续正常运行。 当在闪存扇区中找不到更多块时(找到空标头)-如果稍后该扇区中实际上有更多数据、则会进行检查、并在那里继续解析。 这不是预期的情况、应进行一些错误处理。 可能可以在找到的地址解析、但在解析驱动程序后、我认为应将信息复制到新的扇区、并擦除损坏的扇区。 如果发现损坏的块(全零标头)、情况也是如此。 这不是预期行为。

[引用用户="Matthias Weyh"]

问题1 -块大小)

为什么在闪存中存在不同信息时使用配置大小-我们通过始终使用闪存中的大小为问题准备了一个修复方法。 以前未配置的块也是如此、因此不会造成问题。 唯一的问题是、当我们读取一个块并且应该读取的大小与当前配置的大小不同时、我们应该怎么办？ 当前、如果在更新后所有数据(48字节)或仅部分数据(40字节)被读取、我们将不会获取信息。 这意味着我们无法在上层软件中做出相应的反应。 定义的大多数块都是静态大小的-问题仅限于少量块、这些块中包含的数据结构可能会在软件版本之间更改大小。

[/报价]

- Hercules FEE 驱动器的设计方式是这样读取大小信息。 当然、有优缺点。 我不知道这个执行背后的历史、FEE 只从 EEP 块头读取大小 如果一些块之前被写入、但是从配置中被删除的话。 同样，在使用引导加载程序(不同配置)和应用程序(不同配置)时，这种情况也有不同的用例。 不同版本的应用软件不支持具有不同块长度的相同块。

- TI_fee_read (uint16 BlockNumber、uint16 BlockOffset、uint8* DataBufferPtr、uint16 Length)

在读取 API 中、有块偏移量和长度参数、可用于从块中读取数据子集。

-目前 TI FEE 仅支持静态块大小配置。 我想我们不会马上支持动态/可变块大小功能。 因为它从来不是一项要求。

[引用用户="Matthias Weyh"]

问题2 -在闪存操作期间复位)

这里的问题是、闪存驱动程序不会完成块写入-在某些情况下甚至不会在标头内完成8字节写入。 目前没有信息显示报头是否有效-只有一个状态"启动程序块"、当报头和数据都被写入时、该状态会保留。 这意味着在这种情况下、我们无法使用标头的大小-实际上、我们甚至无法使用块 ID、因为它可能是错误的。 在我看来、需要有另一个状态-类似于"已写入标头"、以确保标头中的数据有效且可用。 我们针对这种情况的权变措施是将到目前为止发现的所有数据复制到新扇区并擦除损坏的扇区。

[/报价]

-如果您查看1.19.03版本，我们已在 FEE Init 期间取消了“启动程序块”的检查。 因此、我们不使用此不完整块的大小。

[引用用户="Matthias Weyh"]

问题3 - TI_FeeInternal_PollFlashStatus)

幸运的是、我们正在使用看门狗、但仍然使用看门狗、这种行为并不理想。 是否不能在必要时仅轮询闪存状态几次并离开 TI_FEE 主功能？ TiFee 状态机应处理在下一次调用 TiFeeMainFunction 时继续执行当前作业。 我们针对此问题的解决方法是将 TiFee 与自己的任务分开。

[/报价]

我理解这一挑战，你的解决办法是好的。 如前所述、在我们的实施中、我们避免了更严重的情况、即在活动闪存操作期间进行组访问(进一步收费操作)、这将使系统停止运行。  

-除了擦除所有其他命令所需的时间非常少。 TI_FEE 主函数是通常执行擦除的函数、我们建议在低优先级任务/空闲任务中调用此特定函数。  

[引用用户="Matthias Weyh"]

问题4 -初始化期间无错误处理

初始化期间有一些情况不会作为错误处理、但闪存驱动程序会尝试继续正常运行。 当在闪存扇区中找不到更多块时(找到空标头)-如果稍后该扇区中实际上有更多数据、则会进行检查、并在那里继续解析。 这不是预期的情况、应进行一些错误处理。 可能可以在找到的地址解析、但在解析驱动程序后、我认为应将信息复制到新的扇区、并擦除损坏的扇区。 如果发现损坏的块(全零标头)、情况也是如此。 这不是预期行为。