TMS320F280039C: TMS320F280039C异常复位

已经收到了您的案例，调查需要些时间，感谢您的耐心等待。

您好，

      您链接的帖子中客户并没有回复测试结果。

       但芯片周期性复位的原因就是代码没有及时喂狗，导致的看门狗复位。

      在c2000ware中提供了固件升级的示例代码，请参考 Live Firmware Update Without Device Reset on C2000 MCUs (Rev. C) 文档“6 Example Implementations”里面的资源。

并非是没有喂狗引起的。是芯片自身复位导致。具体问题和分析情况描述如下：
一、问题说明
    ​我们MFCU在客户整车上面做OTA时候，有两个件出现了不停重启的问题，其中一台的重启周期为80ms左右（通过看报文和量芯片复位引脚发现），两个件略有差异。
    ​其中：1.MFCU使用芯片是TMS320F280039C；2. 两个故障件MCU芯片为同一个生产批次。
二、排查分析
    ​我们做了一些列排查，其中：
    ​1.硬件测了外围电路，正常；
    ​2.故障件中的软件用调试器读出，刷入新的MFCU，运行正常；
    ​3.用调试器对故障件重刷了软件，问题依然存在，但是搁置一晚上后，第二天早上恢复了通讯；
    ​4.对硬件板子和芯片AB互换测试，发现问题跟着MCU芯片走。
    ​另外进一步分析有以下发现：
    ​1.问题基本上发生在Flash擦除和读flash。
    ​2.擦除flash（大小为0xF000半字，对应0x1E000字节），正常这个时间为210ms左右，故障件擦消耗时间不稳定，有出现大于1.6s的，有4.2s左右的，有出现过大于5s的。
    ​3.二个故障件在读flash时，有时会报错（ECC错误），其中两个故障件出现错误的对应的读flash地址不同。
    ​ECC错误说明：查看底层底层寄存器｛ bit0 (SINGLE_ERR_INTFLG) + bit1 (UNC_ERR_INTFLG) 都置位，表示有单比特和不可纠正错误标志｝，之后触发 NMI → NMI ISR（ 未及时喂 NMIWD），NMIWD 就是 NMI Watchdog（Non-Maskable Interrupt Watchdog，非可屏蔽中断看门狗），它是 TI C2000 系列实时微控制器（MCU）中一种专用的、独立的系统级看门狗定时器。
    ​4.通过uniflash去擦除或者刷写软件，有时候执行到一半会报错。

您好，

      当你说问题主要出现在闪存擦除/读取操作时，还有哪些其他场景会出现这个问题？

      该设备是否仍在数据手册中规定的写/擦除周期规范范围内？你可以在第6.12.4.1节找到一个表格。

      另外，当触发ECC错误时，闪存内容是正确的还是已经损坏了？

，

故障件是新的芯片，（烧录次数<25次）理论时间15ms*15个扇区=225ms<4.2s，不在擦除周期规范范围内。

而且我们自己测试的正常件，已经测试来3-5万次，时间也差不多230ms左右。

ECC错误时，flash已经被破坏了，但是也是因为flash擦除时时间异常（擦除APP区），触发看门狗复位引起的，但是从故障件里面读取出来的程序，通UniFlash烧录到正常芯片中，还是可以恢复过来的，（因为我们用恢复机制，APP校验（就是从APP代码区域地址先读取数据出来做crc校验）不过，可以从APP备份区中恢复），但是做APP校验时，因为ecc问题，跳转到不可屏蔽中断中，不断重新启动，没有办法恢复，但是正常件，烧录故障件读取出来的flash程序，是可以恢复的，也没有报ecc错误。

故障件报ecc错误，那是flash已经被损坏了，但是也是因为flash擦护时异常>软狗时间，这个时候软件复位。

MCU重启之后，我们会做APP校验（就是APP代码区域读取，做crc校验），异常时，可以从APP备份区里面代码拷贝。

故障件一直卡在Ecc报错，跳转到不可屏蔽中断__interrupt void Interrupt_nmiHandler(void)，不断重新启动。

故障件里面程序（flash）通过UniFlash读取出来，烧录正常件，是可以恢复正常的.

那应该正常件里面烧录故障件flash程序，也应该报ecc错误才对

您好，

Jianfeng Chen 说：

但是正常件，烧录故障件读取出来的flash程序，是可以恢复的，也没有报ecc错误。

     我想确保自己正确理解了这一部分。是闪存被损坏了（即主区域或ECC区域中有错误数据），还是即使闪存完整性正常，也出现了ECC错误？为了测试这个，你是从有故障的部件中获取内存转储，然后将其烧录到正常的部件上吗？

Jianfeng Chen 说：

故障件报ecc错误，那是flash已经被损坏了，但是也是因为flash擦护时异常>软狗时间，这个时候软件复位。

   这是否意味着应用程序已启用看门狗定时器？

另外，客户是否在发出编程和擦除命令之前，使用 Fapi_initializeAPI 和 Fapi_setActiveFlashBank 根据其设备时钟速度正确初始化了 Flash API？

客户发出编程和擦除命令之前,都是使用Fapi_initializeAPI(F021_CPU0_BASE_ADDRESS,DEVICE_SYSCLK_FREQ/1000000U)Fapi_setActiveFlashBank(Fapi_FlashBank1);

应该是被破坏了（正在擦除flash时复位），也通过对比软件比较了,APP代码区与正常APP代码区有不同之处。

因为当时在对比测试，查是程序问题还是硬件问题。

把故障件里里面程序读取出来，烧录正常芯片中，发现是可以正常恢复过来的，因为如果报Ecc错误机制，就跳转到不可屏蔽中断__interrupt void Interrupt_nmiHandler(void)，不断重新启动，来不到从备份区里面回复APP区代码，但是正常件，可以正常使用。

Boot里面也是启动看门狗的

报Ecc 错误，是下面这样的流程

故障件，先烧录正常的程序，程序可以正常的运行，这是接收升级指令（跳转到Boot）里面，之后初始化，打开看门狗(定时1.67s)-->>这个时候Boot还能正常运行。

接收到擦除flash指令-->经过测试发现flash擦除消化时候（>4.2s）,远远大于手册里面正常时间（大于看门狗时间）->这个时候软狗复位-->之后MCU一直程序启动（在Boot）里面，这个时候通过ccs用导入模式查看-->发现报ecc错误。

之后通过通过UniFlash读取程序，通过与正常程序进行对比（Beyond Compare ）boot 相同，APP代码有些地方不同，APP备份相同。

最后我们把故障件里面ALL.out（Boot+APP+APP备份区）烧录正常件里面，是可以正常运行的，没有和故障件一样卡在Boot里面一段重新启动（报ecc错误），是可以自己回复APP备份区代码的。