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 进行编程-步骤5

Guru**** 2492385 points


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

https://e2e.ti.com/support/power-management-group/power-management/f/power-management-forum/1480322/bq79616-q1-program-the-otp---step-5

器件型号:BQ79616-Q1

工具/软件:

您好:

我们对 OTP 编程行为有一些疑问、希望得到澄清。


#主问题-对 OTP 进行编程-第5步

我们在 TI E2E 论坛上找到了相关讨论:

e2e.ti.com/.../bq79616-q1-otp-programming

从讨论中得出的一个结论是:

"OTP_CUSTx_STAT 寄存器仅在加载 OTP 页面时更新、因此仅在复位后更新。
您需要先执行数字复位并成功重新建立通信、然后才能从它们中获取数据。
但是、OTP_PROG_STAT 中的数据在复位后将丢失、因此您必须在发送复位之前读取它们。"

请您确认此信息正确无误、并与下面的迹线相对应、
从而确认我们正在正确执行该程序、同时还表明文档不正确?

这似乎是完美的工作,但我们希望确认这确实是正确的和预期的行为。

如果这是重复性的、则表示歉意、但这可能会帮助其他人遇到相同问题。

如下所示、预期的 OTP_CUST1_STAT 值(0F)与观察到的结果(00)不匹配、这与文档相矛盾。


- 1)解锁 OTP 编程
[重要说明] OTP 解锁序列完成!!!

--2)读取 OTP_PROG_STAT 以验证解锁状态
[成功] OTP_PROG_STAT 应为80、IS 为80

--3)写入 OTP_PROG_CTRL 以开始编程
[重要说明] OTP 编程已开始!!!

--4)等待 OTP 编程完成
[重要说明] OTP 编程已完成!!!

--5)读出当前状态
[SUCCESS] OTP_PROG_STAT 应为01、为:01
[失败] OTP_CUST1_STAT 应为0F、为:00
[SUCCESS] OTP_CUST2_STAT 应为00、且为:00

-6)发出数字复位并等待10=0x02软复位
[重要说明]发出数字复位并等待开始
[重要说明]发出数字复位和等待结束

--增加1)数字复位后自动寻址
自动寻址完成

——加2)读出当前状态
[SUCCESS] OTP_PROG_STAT 应为00、为:00
[成功] OTP_CUST1_STAT 应为8F、且为:8F
[SUCCESS] OTP_CUST2_STAT 应为00、且为:00

--附加3)故障摘要
故障摘要0--
寄存器故障汇总(0x052D)响应(十六进制):02
寄存器故障汇总(0x052D)响应(二进制):00000010
寄存器故障 SYS (0x0536)响应(十六进制):10.
寄存器故障 SYS (0x0536)响应(二进制):00010000
寄存器故障 COMM1 (0x0530)响应(十六进制):00
寄存器故障 COMM1 (0x0530)响应(二进制):00000000
寄存器故障 COMM2 (0x0531)响应(十六进制):00
寄存器故障 COMM2 (0x0531)响应(二进制):00000000
寄存器故障 COMM3 (0x0532)响应(十六进制):00
寄存器故障 COMM3 (0x0532)响应(二进制):00000000
寄存器故障 OTP (0x0535)响应(十六进制):00
寄存器故障 OTP (0x0535)响应(二进制):00000000
寄存器故障 PWR1 (0x0552)响应(十六进制):00
寄存器故障 PWR1 (0x0552)响应(二进制):00000000
寄存器故障 PWR2 (0x0553)响应(十六进制):00
寄存器故障 PWR2 (0x0553)响应(二进制):00000000
寄存器故障 PWR3 (0x0554)响应(十六进制):00
寄存器故障 PWR3 (0x0554)响应(二进制):00000000


#第一个附加问题–OTP_SPARE 与 CUST_MISC

文档指出:

'OTP_SPARE:这些是器件中实现的备用 OTP 和影子寄存器位。
这些位包含在 CRC 计算中、但不执行任何功能或影响器件行为。'

"Cust_MISC:客户暂存区。"

从我们的测试来看、使用 OTP_SPARE 和 CUST_MISC 存储用户定义的数据之间似乎没有功能差异。

OTP_SPARE 和 CUST_MISC 之间是否有任何功能区别?


#第二个附加问题–出厂配置加载失败

这些文件指出:

'如果 OTP (出厂配置默认值或客户 OTP 空间中编程的值)
器件复位后无法加载、影子寄存器将改为加载硬件复位默认值。'

出厂配置默认值在什么情况下无法加载?
是否存在可能导致此行为的特定故障情况?


此致、
Stefan

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

    您好、Stefan:

    Unknown 说:
    '只有在加载 OTP 页面时才会更新 OTP_CUSTx_STAT 寄存器、因此仅在复位后才会更新。
    您需要先执行数字复位并成功重新建立通信、然后才能从它们中获取数据。
    但是、OTP_PROG_STAT 中的数据在复位后将丢失、因此您必须在发送复位之前读取它们。'

    这是正确的、这就是 OTP_CUST1_STAT 在第5步中读取0x00的原因、因为必须先复位并自动寻址器件。  

    Unknown 说:
    在什么情况下出厂配置默认值无法加载?
    是否存在可能导致此行为的特定故障情况?

    如果两个页面都未正确编程、则将改为加载出厂配置默认值。

    此致、

    David Ray

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

    您好、David、

    感谢您确认此行为!

    --

    关于*OTP_SPARE*与[CUST_MISC*、我们是否可以假设它们在功能上相同且可互换?

    --

    关于*出厂配置默认*、文档描述了两种情况:

    第一种情况-*如果已对页面进行编程*:
    -尝试加载*Page 2*
    -如果不成功,请尝试加载*Page 1*
    -如果不成功,请尝试*出厂配置默认值*-不确定是否发生这种情况或是否直接加载*硬件重置默认值*?
    -如果两者都不起作用,加载*硬件重置默认值*

    第二种情况-*如果没有编程页面*:
    -尝试加载*出厂配置默认值*
    -如果不成功,加载*硬件重置默认值*

    我的问题涉及在什么情况下加载*出厂配置默认值*会失败?
    还是我们可以合理地忽略这种情况、因为这种情况永远不会发生?

    --

    此致、
    Stefan

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

    尊敬的 David:

    我只是跟进我之前提到的其中一个问题、因为我在文档中找不到任何内容来对其进行澄清:

    关于 OTP_SPARE 与 CUST_MISC、我们是否可以假设这些都在功能上相同且可互换?

    如果您能确认或向我指出正确的方向、这将非常有帮助。

    再次感谢!

    此致、
    Stefan

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

    您好、Stefan。

    对延迟回复表示歉意。 无法加载页面可能是内部 IC 损坏的结果。 OTP_SPARE 和 CUST_MISC 在功能上完全相同且可互换。

    此致、

    David Ray

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

    嗨、大卫、

    非常感谢您的澄清—非常感谢!
    完全不用担心延迟。

    此致、
    Stefan