[参考译文] TPS6.5982万：通过应用程序自定义工具生成的.bin文件

高桥三

工具中没有更改这些地址的规定-为什么要进行此更改？

文件生成中没有错误。 正如您在'Flash Memory Organization'图片中看到的，地区1和地区2分别位于地址(RPTR-1+AOFF-1)和(RPTR-2+AOFF-2)。 RPTR-2为0x2000 (与RPTR-1相同)，但AOFF-2不同-请参阅4B @地址位置0x1FFC。

谢谢，此致，
Praneet

您好，Kumar-san，

感谢您对此问题的快速响应。

>为什么要进行此更改？

我的客户正在寻找如何修改闪存数据。 他们的.bin数据似乎有问题，他们想要从EC更新固件。

文件生成中没有错误。 正如您在'Flash Memory Organization'图片中看到的，地区1和地区2分别位于地址(RPTR-1+AOFF-1)和(RPTR-2+AOFF-2)。 RPTR-2为0x2000 (与RPTR-1相同)，但AOFF-2不同-请参阅4B @地址位置0x1FFC。

请理解！ AOFF在 下面的文档中始终为"00 00 00 00 00"，所以我几乎忘记了偏移。
RPTR和AOFF之间的数字选择是否有任何方式？ 例如 ，RPTR地址应相同，依此类推。

来自嵌入式控制器的TPS6598x FW更新(基于I 2C)
http://www.tij.co.jp/jp/lit/ug/slvuah7b/slvuah7b.pdf

此外，您能否评论以下问题？

要正确重写Region1，必须修改哪一部分？
我相信只是重写以下两点，让我确认这项理解是否正确，抑或不 是在个别情况下。
1.区域1指针地址和标头+ AOFF(0x0.1万~0x0.2万)
2.应用程序代码及其标题(RPTR + AOFF for Region1 ~ End)

此致，

Takashi Onawa

高桥三

请参阅文档@ www.ti.com/.../slva783a.pdf，其中包含有关闪存更新顺序的所有详细信息。

应更新非活动区域。 FLrr命令以全闪存二进制返回(查询的)区域的地址，主机应用程序应使用生成的'Low Region'二进制文件中的内容更新该地址的内容。

请参阅我上面提到的文档，如果您有任何疑问，请告诉我。

谢谢，此致，
Praneet

您好，Kummar-san，

我对地址有一个简短的问题，尤其是区域1。

如果他们想要将Region1应用程序代码地址设置为0x2万，我们如何选择RPTR和AOFF值？  

文档和我们的应用程序自定义工具中使用了不同的方式。 因此，他们无法判断哪一个更好。

TPS6598x FW更新~文档方式：(RPTR:0x2万，AOFF:0x0万)
在本文档中，AOFF值始终为0x0，并且更改PRTR值。

应用程序自定义工具 方式：(RPTR:0x0.2万, AOFF:0x0001e000)
在GUI上，PRTR值始终为0x2000，并且更改AOFF值。

[背景]
我的客户将使用您随附的文档中指示的示例软件。 在文档中， 0x2000和0x2万被分配给Region0/1应用程序代码。 但是 ，在最新的应用程序自定义工具上，在.bit文件生成工具中，默认的High区域地址已从0x2万更改为0x1.2万，因此他们要修改从最新的应用程序自定义工具生成的.bin文件。

此致，

Takashi Onawa

高桥三

我们将高区域图像的位置从0x1.2万更改为0x2万，以节省sFLASH上的空间。 我不理解这对客户的用例有何影响。

EC应用程序不需要注意全闪存二进制中68KB低区域/高区域内容的位置。 FLrr命令将返回您要更新的区域的地址，EC应用程序只需将68KB数据写入该地址。

谢谢，此致，
Praneet

您好，Kummer-San，

文档中的RegionUpdate82()函数仅允许EC在地址为0x0.2万和0x2万时更新区域数据。 他们在欧盟对其软件进行编码时也提到了这一点。
这就是他们寻求更改.bin文件地址的方法的原因。 由于更改，他们无法更新高区域图像。

如果我们可以说以下两种情况中的任何一种是可以接受的，并且不会因RegionUpdate82()操作中的更改而产生任何副作用，则他们不需要编辑.bin文件。

哪一项对您来说更容易，请对地址更改或RegionUpdate82()审核进行评论？

[案例1]
const UINT32_t rgnPntrVal[2]={0x0.2万, 0x2万);-> const UINT32_t rgnPntrVal[2]={0x0.2万, 0x1.2万}；

[CASE2]
IF (tempdata == rgnPntrVal[rgnNum]){}-> DELETE

此致，
Takashi Onawa