This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] BQ79616-Q1:OTP 编程

Guru**** 2595770 points
Other Parts Discussed in Thread: BQ79616

请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/power-management-group/power-management/f/power-management-forum/1364142/bq79616-q1-otp-programming

器件型号:BQ79616-Q1
主题中讨论的其他器件:BQ79616

我执行了数据表9.3.6.3.2 (OTP 编程)中表9-26中的步骤、但未执行操作"b"。 的位置。 和"C"。 步骤5的内容与数据表中的内容不同。
哪一项是正确的、数据表还是实际行为?


数据表的行为
b.如果对第1页进行了编程、则 OTP_CUST1_STAT[PROGOK]、[TRY]、[OVOK]和[UVOK]位将为1。 其他位为0。
c.如果对第2页进行了编程、则 OTP_CUST2_位为 STAT[LOADED]、[PROGOK]、[TRY]、[OVOK]和[UVOK]位为1。 其他位为0。


实际操作
B.和 C.
OTP_CUST2_STAT:所有位均为0。
但是、执行步骤6后、与数据表中相同的位变为1。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Ben San、

    我们的目标是、如果编程 PAGE 1失败、系统会自动对 PAGE 2进行编程。
    编程第2页可能很少见、但为了确保系统的质量、应该通过能确保成功的程序来完成。
    如果不清楚编程第2页后执行的正确程序是软复位还是唤醒 ping、请调查。

    我们将分享操作确认的当前状态供您参考。

    e2e.ti.com/.../OTP_5F00_Programming.pdf


    此致。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Yoshihiro

    唤醒 ping 和软复位应该对 OTP 寄存器执行相同的操作、并且在 OTP 编程过程中必须可以互换(您必须遵循唤醒 ping 的较慢时序)。  我们从未听说过软复位以这种方式不起作用、因此如果 WAKE ping 可以正常工作、我们可以直接使用它。

    此致、

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Ben San、

    >(您必须遵循 WAKE ping 的较慢计时)。

    感谢您的建议。

    当我在执行软复位后将等待时间从1ms (tRST)更改为10ms (tsu (WAKE_SHUT))时、我可以确认第1页和第2页 OTP 写入工作正常。
    (我已附上日志和确认状态以供参考)

    在数据表中将 CONTROL1[SOFT_RESET]设置为1后、我找不到所需的等待时间、所以在哪里写入了它?

    e2e.ti.com/.../OTP_5F00_Programming_5F00_Page1_5F00_20240719.txte2e.ti.com/.../OTP_5F00_Programming_5F00_Page2_5F00_20240719.txt

    e2e.ti.com/.../OTP_5F00_Programming_5F00_20240719.pdf

    此致。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Yoshihiro

    在第18页的第8.6节"电源状态时序"副标题下。 它 在1ms 时列为 trst。 显然、这并不完全准确、我们正在考虑更新。  

    此致、

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Ben San、

    感谢您的评论。
    查看第9.4.1节中的图9-60和图9-61、可以看到 tRST 是从转换到活动模式到实现通信的时间。
    因此、似乎有必要将从工作模式下执行软复位到再次转换到工作模式的时间添加到等待时间。

    此致。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Yoshihiro

    感谢您的见解。

    此致、

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Ben San、

    现在的情况如何?

    如果您有任何疑问、请发表评论。

    此致。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Yoshihiro

    我以为我们已经解决了这个问题。 如果您对第二页进行编程、则在数字重置后需要额外等待一段时间。 "你在担心我吗?"

    此致、

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Ben San、

    我认为不清楚数字复位后所需的最短等待时间。
    因此、请提供下图所示的"Tsu (ACT2ACT)"建议值。



    此致。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Yoshihiro

    您可以使用标称值为6ms 或最大值为10ms 的 TSU (WAKE_SHUT)作为计时。 我们不能保证更快的时间会起作用。  

    此致、

    本  

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Ben San、

    感谢您的答复。
    既然我没有其他问题、我将结束问答环节
    非常感谢您的长期支持。

    此致。