TI中文支持网Part Number:TMS320F28069
我们的产品在运行的时候dsp会无端地重启（重新进二次bootloader，并，重启时间不定，有可能是进入工作状态后10s就重启，也有可能10min，也有可能半小时甚至更长时间再重启。
目前我们排除了：
1. 中断溢出触发看门狗复位，中断频率是50us，重启前运行时地中断时间大约是35-40us。
程序中还有可能导致dsp重新进二次bootloader的逻辑有：1. 收到 升级指令；2. 收到 重启指令
这两项基本上也可以排除，我们之前抓过这个io信号，逻辑是对的。
现在我们怀疑的方向是干扰问题，因为目前这个机器的电磁干扰等是比较差的。硬件上有电源复位芯片接到dsp的复位引脚，有可能是这个电源被干扰改变了电平状态导致复位。
我想问下还有没有什么可能的原因导致dsp复位的？
Green Deng：
一般能引起复位的就是外部复位信号和看门狗复位，我觉得可以将复位引脚的外部电路断开之后单独测试看门狗复位。如果这种情况下还是会复位，则是看门狗引起的，毕竟引起看门狗复位的不光是中断溢出。任何程序进入死循环或者非法中断等等都会引起看门狗复位。
如果能排除看门狗复位，那么基本就可以判断是外部干扰了。
,
Serenity_pjb：
你好，最近找到了复位的原因，单独测试了单门狗复位，确实是单门狗复位引起的。
原因在于写的函数中的SCI模块，在通信超时后会重新配置sci模块，这个模块中包含三个内容：
1. 初始化sci模块结构体
2. 配置波特率，通信协议等配置
3. 硬件sci模块配置（其中包含一个delay_us函数）
测试发现1占用了8ms左右的时间，确定问题原因是里面有几个大数组，那么使用memset初始化时占用太多时间，改变数组大小可解决这个问题；
2占用时间是us级别；
3占用约4.5ms时间，而实际delay_us设置的是延时1000us也就是1ms。
现在比较困惑的有2点：
1. 如何确定delay_us这个函数确实已经搬运到ram运行，之前有看到这个函数在ram和flash运行时间是不一样的。
2. 如何计算看门狗的中断溢出时间。看datasheet我得出的计算方式是：
（ 1/ （oscclk/512/1））* 256 = 6.5ms 但实际貌似是13ms左右才复位，而且ti程序中注释的也是13ms。
