[参考译文] BQ40Z60：SREC 编程

让我检查一下我们的软件、看看我们是否可以为您提供一些帮助。

我期待着答复。

此致

Patrick

下面是我从我们的软件团队获得的一些反馈。

bqStudio 可能与任何文档不完全匹配、因为它不是一种生产工具。

bqStudio 每隔几秒查询一次总线、以确定器件是否已连接或已更改、并且有时会根据响应发送额外的命令。 因此、客户可能无法通过嗅探总线来看到完美匹配。

 你好，Patwit！

您是否正确发布了字节序列？

通常、"SREC 完成"事务应包含32字节有效载荷、不包括 PEC 字节。 在您的行中、它只有15个字节。

此致。

您好 Igor、

您所讨论的封装是正常有效载荷。

它们被分成几个部分：

编程 DataFlash ->结构：0x16 0x0F 0x22有效载荷 PEC (0x16 = ADR、0x0F = ROM CMD、用于编程 DataFlash (SLUU225))

编程指令闪存->结构：0x16 0x05 0x22 Paload PEC (0x05 = ROM CMD、用于编程指令闪存(SLUU225))

我在监听过程中获得了这些软件包、这很容易解释、即使并非所有数据(具有0xFF 的行)都不会发送。

问题是有一些起始序列和结束序列：

例如、开始：

处于 Rom 模式的器件(MAC CMD 0x0F00)

检查是否处于 Rom 模式

然后、ROM 中的 CMD：

0x16 0x09 0x00 0x00 0x29 (ADR、ROM CMD (设置地址 SLUU225)、我认为地址在 ROM、PEC 中)

0x16 0x0A 0x00 0x00 0x94 (ADR、ROM CMD (从 SLUU225衍生出的写入字节)、值、PEC)

…

有很多步骤、例如、最后是写入字节序列发送。

问题在于、SLUU225来自2005年和其他器件、并非所有 CMD 都与测量值匹配。

有些 CMD 甚至没有在此处提及(例如：0x16 0x12；0x16 0x13；0x16 0x14；0x16 0x1A 0xDE 0x83 0xDA)

我认为这些 CMD 正在删除闪存、0x1A 用于激活/停用区域。

但没有记录，所以这只是建议:-)

此致、

Patrick

尊敬的 Andy：

感谢您的回复。

bqStudio 在正常模式下查询总线是正确的。 但在固件更新期间、应停用此功能。

正如我已经提到的：我认为这是在 BQ40Z60芯片上必须完成的操作、例如解锁芯片、擦除、编程、验证。

我的意思是、该芯片基于某种逻辑和指令、并在 SREC 下载期间进行编程。

有关这方面的任何信息都很好。

此致、

Patrick

我对 CMD 的0x12 0x13 0x14有另一个假设：

SREC 文件包含 S3的数据块这意味着 adresspart 为32位。  

例如、最后一个数据块从地址0x00140000开始。 该部件仅接收最后16位、要在闪存的不同区域之间切换、在 ROM 模式下需要 CMD。

TI 能否就这些想法提供任何确认/提示？

此致

Patrick

尊敬的 Andy：

您能否提供有关我提供的信息的一些信息？

或者、您能告诉我一些关于我的假设的信息吗？

此致、

Patrick

我需要再次咨询软件团队、看看他们是否可以提供一些信息。

尊敬的 Andy：

请提供任何资料。

尊敬的 Andy：

感谢您提供的信息。 因此、我位于右侧迹线上。  

但是、我仍然对这些 CMD 有疑问->回答示例 CMD 0x14是0x50 0xC9 0x8F (对数据闪存进行编程后)、是否可以计算该值？

此外、我还不知道如何计算"最终"校验和(0x16 0x03 0x0B 0x2A 0x2A 0x7F 0x01 0x00 0x0A 0x0A 0x05 0x00 0x7F 0x00 0x48)。

此致、

Patrick

您好 Igor、

感谢您的回答。

我注意到、CMD 0x13之后的响应字节在数据的有效载荷方面发生变化。

例如、如果我发送32次0xFF (删除地址上的值)、响应值为0x26 0xEB 0xDF (闪存中的地址可以更改、但应答值保持不变)

如果发送数据(不仅是0xFF)、则响应的值例如更改为0x5B 0x3 0x02。

此值是否可以计算、或者是否是地址的固定值？

此致

Patrick

 尊敬的 Patrick！

CMD 0x13返回每个 IFIB 块的完整性签名、而不是空洞段的完整性签名、因此每次 IFIB 块更改时返回值都会更改。

正如您在0xFFFFFF...FFFFFF 32字节付款方签名为0xEB26时正确注明的那样。

IFIB 数据很重要、因此在块基础上验证签名、而不是像指令闪存那样针对完整段验证签名。

是的、可以计算它、但算法很复杂。

您可以通过回读已写入的块并将其与已发送的块进行比较来绕过工具中的此步骤。

这是一个很好的折衷方案、因为 IFIB 段很小、使用该方法几乎不会占用编程时间。

此致

您好 Igor、

感谢您的回复。 有关这些 IFIB 块的另外两个问题。

我注意到它们是按照特殊顺序编程的：

0x0020数据=0xFF *32

0x0040数据=0xFF *32

0x0060数据=0xFF *32

0x0000数据(但前两个字节设置为0xFF、稍后进行编程)

0x0080数据

0x00A0数据= 0xFF*32

0x00C0数据= 0xFF*32

0x00E0数据= 0xFF*32

在此序列之后：

对地址0x0000上的前两个字节进行编程

此订单有特殊原因吗？ 因为只要读取顺序为0x0000 0x0020 0x0040.....的 srec 和 programm 就会容易得多

为什么地址0x0000的前两个字节被0xFF 替换并稍后编程？ (我假设这可能是固件的起始地址、等等)

此致、

Patrick

您好 Igor、

非常感谢。 我得到了很多有用的答案。

还有一个问题：你从哪里得到所有这些信息？ :-)

此致

Patrick