大家好、请告诉我、如果您有与此案例相关的更多信息、我刚刚了解到旧案例已被锁定。 我之前没有看到关于这一点的消息...
此案例仍处于打开状态。
谢谢
1月
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.
大家好、请告诉我、如果您有与此案例相关的更多信息、我刚刚了解到旧案例已被锁定。 我之前没有看到关于这一点的消息...
此案例仍处于打开状态。
谢谢
1月
这些保留位中没有用于调试问题的有用信息,我们也不会发布保留位的详细信息。
可能是器件意外锁定。 编程期间出现欠压或中断时可能会发生这种情况。 也就是说、即使您的应用程序没有密码、掉电也可能导致向密码位置写入垃圾值、从而意外地保护您的设备。 遗憾的是、无法从这种情况中恢复、因为您不知道在闪存的密码位置中编程了哪些值。 需要确保的事项:(i)在开始编程之前确保闪存被擦除。 即在开始编程之前等待数据表中提到的擦除时间。 (ii)确保器件在擦除/编程操作期间不会"当前无法启动"
这些条件的监控需要在外部完成。 从实际情况来看、这是一款相当成熟的器件(已使用15年以上;基础闪存技术甚至更早)。 闪存编程算法此时相当稳定(请确保您使用的是最新版本的 API;请访问 TI 网站)。 通常、我们能够根本解决编程问题的原因是以下原因之一:(i)某种程度的擦除/编程(E/P)过程中断–这可能会使密码位置保留一些随机值。 ㈡在 E/P 期间使该装置目前处于饥饿状态