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.
https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1328443/cc1352p-data-flash-could-be-fail-even-damaged-after-multiple-factory-reset
尊敬的先生或女士：
ZNP 中使用了 Simplelink_cc13x2_26x2_SDK_4_40_xx_xx。 当协调器关闭时、器件的数据闪存在数百出厂复位后可能出现故障。 大多数 器件都可以通过重新编程 ZNP 代码来修复。
但在其中一些器件中、数据闪存已损坏。
此致、
大卫
尊敬的 David：
Unknown 说：当协调器关闭时、设备的数据闪存在数百出厂复位后可能发生故障
由于设备必须打开并运行才能执行恢复出厂设置、所以协调器关闭意味着什么？ 需要数百次恢复出厂设置才能重现此问题、以及为什么此非典型操作应用于这些器件？ 在这些测试期间、CC1352P 的电源电压电平是多少？
Unknown 说： 大多数 器件都可以通过重新编程 ZNP 代码来修复。 但在其中一些器件中、数据闪存已损坏。 [/报价] 您是否能够提供默认 ZNP 的闪存内容、可通过重新编程恢复的故障 ZNP 内容以及闪存数据无法修复的故障 ZNP 内容？ 总共有多少个器件发生了故障、其中有多少个可以恢复到工作状态？ 此致、 瑞安
大多数 器件都可以通过重新编程 ZNP 代码来修复。
您是否能够提供默认 ZNP 的闪存内容、可通过重新编程恢复的故障 ZNP 内容以及闪存数据无法修复的故障 ZNP 内容？ 总共有多少个器件发生了故障、其中有多少个可以恢复到工作状态？
此致、 瑞安
协调器电源在现场意外关闭。 35个设备中的2个数据闪存在实验室中通过复制测试在200个设备恢复出厂设置后出现故障, MAC 地址不正确或无法读取,可以通过对整个芯片进行重新编程来修复。 电源电压为3.3V。
可以对故障芯片(应超过400个、未进行复制测试)进行重新编程、并检查 CRC32是否正常、但一个 MAC 地址不正确或 无法再读取另一个 MAC 地址。
执行这些出厂重置的频率如何？ 即、这些测试是在器件上电后立即执行、还是存在延迟以允许器件正确初始化？ 用于实现恢复出厂设置的 API？ 当复位发生时、如果闪存发生有源读取/写入、NV 内存可能被损坏。
如何读取 MAC 地址以及从何处读取(NV、CCFG、FCFG 等)？ MAC 地址是唯一损坏的闪存、还是您认为闪存的其他区域也会受到影响？ 我们或许能够 在闪存中使用 MAC 地址的不同位置、但前提是要确定这是唯一有问题的参数。
感谢您的帮助。
执行这些出厂重置的频率如何？
实验室测试需要10分钟、电源保持开启。 SYS_RESET_REQ 类型：0/1
即、这些测试是在器件上电后立即执行、还是存在延迟以允许器件正确初始化？
上电延迟约5秒、然后初始化 ZNP
如何读取 MAC 地址以及从何处读取(NV、CCFG、FCFG 等)？
CCFG
MAC 地址是唯一损坏的闪存、还是您认为闪存的其他区域也会受到影响？
MAC 读取不正确时芯片无法加入网络。 某些 UART 无响应。
从 Zigbee 协议的意义上讲、SYS_RESET_REQ 不是"恢复出厂设置"、因为该 MT API 不会导致 NV 存储器被清除。 该参数也不应该因为最终会 执行 SysCtrlSystemReset 而受到影响。 因此、每10分钟仅发生一次复位、并且器件会在通过 MT API 命令初始化 ZNP 之前加电5秒？
读取 MAC 地址的流程是什么？ 如果您在 CCFG 之外建立 MAC 地址、是否会出现此问题？ 该调查仍会受益于默认/损坏闪存之间的存储器内容比较。
您好、Ryan、
抱歉、恢复出厂设置步骤：Val = 3；TI_NVWrite (0x3、0、1、&val)；延迟2秒、然后发送 SYS_RESET_REQ 类型：0/1。
器件在通过 MT API 命令初始化 ZNP 之前是否已通电5秒？
是
在器件中、读取 MAC 地址以检查器件的仅 MAC。 我将尝试 在 CCFG 之外建立一个 MAC 地址。
感谢您的澄清。 那 NV API 不由 TI 的 Z-Stack 提供、但我认为其仅以与 osal_NV_write 类似的方式写入 NV 存储器。 您是否可以尝试延迟超过2秒(5到10秒)并确认问题是否仍然存在？ 可能也会针对相同的情况增加 ZNP 初始化。 我不知道所做的 Z-stack 配置更改是什么。
通常、MAC 地址会保存为非易失性存储器中的 IEEE 扩展地址、您是否确定读取的故障信息位于 CCFG 中？
此致、Ryan
感谢您的帮助和时间
当芯片出现故障时、 在大多数时间内通过 UART 发送 MT 命令无响应、 在某个时候使用 UTIL_GET_EXT_ADDR MT 命令读取 MAC 地址错误。
Util_GET_EXT_ADDR 不是标准 MT API、但 UTIL_GET_NV_INFO 或 UTIL_GET_DEVICE_INFO 将 从 NV 存储器返回 ZCD_NV_EXTADDR。 报告的两种行为都可能表示 NV 内存损坏、在低压或断电期间访问 NV 内存则可能发生。 器件工作/故障状态之间的完全闪存比较、或者调试有故障的器件、可以确认这一点。 前一种情况便是 在更新版的 SDK 中实施非易失性存储器低电压检测的原因。 后一种情况就是我建议在初始化或关断器件之前为器件稳定添加更多时间的原因。 但是、损坏的 NV 存储器不能解释您提到的器件状态不可恢复、因为恢复出厂设置应重置 NV 存储器。
感谢您的帮助和时间。
根据您2021年5月的建议、已添加#define NVOCMP_MIN_VDD_FLASH_MV 2500。 3.3V 电源的最佳阀是什么？
超过500 SYS_RESET_REQ type：0/1后、芯片运行良好。
您能否 提供最佳的 出厂重置 MT 命令步骤？
新版本 SDK 上的 NV 写入是否存在任何保护？
我可以对其进行相应的测试。
感谢您提醒我、您已经实现了 NVOCMP_MIN_VDD_FLASH_MV、任何高于2000的值都应该是合适的。 自从 SDK v4.20实现以来、NV 写入保护解决方案一直保持不变。
SYS_OSAL_NV_WRITE (0x0003、0x00、0x01、0x03)后跟 SYS_RESET_REQ (0x00)应该适用。 您可以添加 APP_CNF_BDB_START_JUSTING (0x04)以构成网络。 我会要求每一次之间有五到十秒的延迟、以便为上一条命令提供足够的时间来正确执行。
