[参考译文] TMS320F28027：在重复引导加载后、器件会被部分欺骗

尊敬的 Kevin：

感谢您的快速响应。  这是否还会导致器件不再能够通过 JTAG 进行连接？

您好 Todd、

是的、锁定的器件可能会导致 JTAG 连接问题。 您可以尝试将器件置于等待引导模式、然后尝试连接、但如果设置了密码且未知、则器件会被永久锁定。

有关更多详细信息、请参阅以下应用报告。

https://www.ti.com/lit/spracf0

最棒的

Kevin

尊敬的 Kevin：

如果这是已知问题、使用此器件的其他客户会如何缓解此问题？  我们的器件通过壁式电源供电、但与其他任何器件一样、用户可以在任何时候将其拔出。

您好 Todd、

您是否经常在终端应用的正常运行期间擦除和编程器件的闪存？ 您能解释一下您是如何使用这些操作的吗？ 即您对闪存进行编程和擦除时的情况。

最好在闪存擦除/编程操作过程中防止器件断电、以防止类似这样的锁定。

最棒的

Kevin

我不打算执行频繁的固件更新。  之所以发现此问题、是因为我在确定是否应由主机处理器上的 Linux 应用程序执行更新的逻辑中有一个错误。  这导致了一个循环、在此循环中、更新重复发生、而测试系统的人员杀死了执行更新的应用程序、这也导致 F28027断电。  将修改此逻辑以使这种循环成为不可能、并将电源控制从该应用中去耦。   

我使用其中一个 SDK 中提供的闪存内核应用。  首先运行 ROM 引导加载程序、然后将闪存内核加载到 RAM 中。  然后闪存内核运行、我的应用程序加载到闪存中。  我对这个特定的引导加载过程并不是非常熟悉、但是观察逻辑分析仪上发生的一切、我可以看到时序。  

从 ROM 引导加载程序初始握手发生到闪存内核响应最后发送的命令、整个过程需要8.5秒。

加载闪存内核需要1秒的串行流量、然后在主机处理器尝试与正在运行的闪存内核握手之前又需要1秒的串行流量。  主机处理器似乎驱动第二个长等待、因为主机在此等待周期结束时首先传输。  

接下来、短暂突发命令后将出现2.5秒的不活动、我认为这是擦除闪存的闪存内核。  

最后、将应用程序写入闪存需要4秒。

我猜在 ROM 引导加载程序运行期间、不会因下电上电而损坏闪存。  危险区从发出擦除闪存命令的2秒一直延伸到更新完成的8.5秒。  这是准确的吗？

您是否说每次使用此设备的客户执行固件更新时都会面临此风险？  唯一的缓解措施是尽可能不频繁地进行更新？

尊敬的 Kevin：

您能不能告诉我闪存编程和擦除的特定时序、以及闪存内核的使用情况、哪些时间段容易受到损坏闪存的功率损耗的影响？

我们需要尽可能减少这一脆弱时期。

您好 Todd、

很抱歉我的答覆有延误。

闪存编程和擦除功能的时序记录在器件数据表中。 请注意、这些是典型的时间、器件的闪存可以经历更长的时间。 有关器件闪存的更多信息、请参阅此链接中的常见问题解答主题： https://e2e.ti.com/support/microcontrollers/c2000/f/171/t/757585

具体来说、闪存擦除操作是在断电时需要注意的操作。 您应该确保在闪存擦除过程中器件的电源稳定、以防止器件被锁定。

如果您安装了 C2000WARE、您可以在以下目录中找到有关闪存 API 函数和用法的更多详细信息：

C：\ti\c2000Ware_3_02_00_00\libraries\flash_api\F2802x\docs\Flash2802x_API_Quickstart.pdf

最棒的

Kevin