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.

TMS320F28069: DSP运行过程中不定时重启

Part Number: TMS320F28069

我们的产品在运行的时候dsp会无端地重启(重新进二次bootloader,并,重启时间不定,有可能是进入工作状态后10s就重启,也有可能10min,也有可能半小时甚至更长时间再重启。

目前我们排除了:

1. 中断溢出触发看门狗复位,中断频率是50us,重启前运行时地中断时间大约是35-40us。

程序中还有可能导致dsp重新进二次bootloader的逻辑有:1. 收到 升级指令;2. 收到 重启指令

这两项基本上也可以排除,我们之前抓过这个io信号,逻辑是对的。

现在我们怀疑的方向是干扰问题,因为目前这个机器的电磁干扰等是比较差的。硬件上有电源复位芯片接到dsp的复位引脚,有可能是这个电源被干扰改变了电平状态导致复位。

我想问下还有没有什么可能的原因导致dsp复位的?

  • 一般能引起复位的就是外部复位信号和看门狗复位,我觉得可以将复位引脚的外部电路断开之后单独测试看门狗复位。如果这种情况下还是会复位,则是看门狗引起的,毕竟引起看门狗复位的不光是中断溢出。任何程序进入死循环或者非法中断等等都会引起看门狗复位。

    如果能排除看门狗复位,那么基本就可以判断是外部干扰了。

  • 你好,最近找到了复位的原因,单独测试了单门狗复位,确实是单门狗复位引起的。

    原因在于写的函数中的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。