[参考译文] TPS6.5986万：需要阐明固件更新过程的内存映射

Praneet，

您告诉我的事情 似乎 正是您所说的可能会导致腐败问题。   sFLASH将包含旧工具的全闪二进制文件，并且不能简单地重写sFLASH，我们希望使用FW-Update。   如果我使用新工具生成的二进制文件进行更新，使用FLem w/ 17 4KB块.... 那么，如果先对较低的区域进行编程，它“可能”会重叠区域。  这是我们需要避免的。

我们如何使用Flash-Update应用程序安全地为高区域内容进行此转换，以0x1.3万为起点？？？    我想，我们可以使用闪存更新程序执行以下操作：

1. 使用旧工具生成的旧64KB二进制文件
2. 使用FLem和16个4KB块，但使用新工具(将高区域置于0x1.3万处)，对旧的64KB二进制文件运行Flash-Update过程。

1. 这只会有效地将现有的高层区域"移动"到正确的地址位置

• 然后使用新工具生成新的二进制文件(我假设它可能生成68KB二进制文件)
• 使用新的二进制文件并使用FLem w/ 17 4KB块再次运行闪存更新过程。

现在，我们有了新的二进制文件，新的工具和位于0x1.3万的高区域。

然而...... 但是，问题是运行更新过程的正确方法... ，因为FLrr将返回Region[1]的0x1.2万，并且该指针值将用于后续的“erase”和“address”命令。   FLem应该使用在FLrr命令中返回的相同指针运行... 但应该使用多少个4KB块？   他们是否应该使用17个4KB块，以确保在从新的开始地址0x1.3万写入数据时擦除将成为第16块的内容？
现在， FLAD还应使用地址0x1.3万，而不是从FLrr命令返回的指针值。  这与应用注释过程不同，需要知道我们当前是否正在写入区域[0]或区域[1]，并且需要修改过程以增加指针地址。   

很抱歉，如果我完全错过了一些内容，但我希望看到一个强大的说明，使用Flash-Update过程迁移到新工具和0x1.3万地址位置。  我们不能简单地重写整个sFLASH二进制文件来在所有情况下获得新的起点。   谢谢你。