请教DSP调试方法

时间:2021-02-06 19:29:27
调试嵌入式设备(DSP)最常见的手段是PC通过开发器连接目标版,然后进行调试.但是当开发完成投入生产后也可能出现问题.我经常碰见的情况是现场的设备出现问题了,客户反馈不正常工作了,此时如果没有任何调试手段,只能是开发人员再次测试,希望重现现场问题.
问题重现是很困难的,也是很耗时的.

想看看各位有没有什么好的办法,增加一种手段,当现场出问题的时候,
1.最起码能大致定位问题所在
2.最好允许现场调试

小弟不才,没什么好的方法,仅仅想到了记日志,希望不吝赐教.

9 个解决方案

#1


1、开发者看到现象,根据代码的实现过程和个人的经验大概就能定位问题了。
2、现场调试,也可以带着笔记本和下载工具调试,如果不方便,先在板子上调试好现场升级。
   如果你做了IAP,那么升级方法就很多了可以脱离笔记本,可能一个串口接口、一张SD卡,一个无线模块都可以实现升级代码的功能。

#2


嵌入式的调试是麻烦些。

#3


 调试代码保留, 现场运行稳定了再去掉

#4


开发者能看见当时的现象,或者在现场会好很多,毕竟程序的运行自己最清楚.不过开发的一般都不出差,而是由专门人员出差,然后在现场反馈问题.
升级倒是很方便,有专门的升级工具通过网络升级.

设备就是交通路口的抓拍机,调试代码保留的作用不大,因为即使有打印函数,也没有显示输出设备,一般情况下也不允许通过网络上报.

遇到的问题都是测试部测不出来,到现场出现了,机器拆回来后又很难出现,想一个方法能在整机运行的情况下查看到机器内部的运行状态,如果能允许简单的调试最好了.

将设备调入网络日志模式,控制哪些模块的日志允许上报,日志的详细程度可能起点作用

有没有更好点的方法,GDB远程调试是太复杂了,嵌入的代码都超过设备的正常代码了(个人瞎猜的,不是很懂)
简化点的GDB也许可行  

谢谢大家回复

#5


是不是各种设备整机情况下都很难调试?

#6


期待好的想法

#7


大致确定范围,在可能处插入一些未用 pin 的输出 或平时不肯能出现的动作 可否

#8


可行 不过老大不会同意任何涉及到硬件的部分 我们几乎是纯软

#9


希望能想到好点子

#1


1、开发者看到现象,根据代码的实现过程和个人的经验大概就能定位问题了。
2、现场调试,也可以带着笔记本和下载工具调试,如果不方便,先在板子上调试好现场升级。
   如果你做了IAP,那么升级方法就很多了可以脱离笔记本,可能一个串口接口、一张SD卡,一个无线模块都可以实现升级代码的功能。

#2


嵌入式的调试是麻烦些。

#3


 调试代码保留, 现场运行稳定了再去掉

#4


开发者能看见当时的现象,或者在现场会好很多,毕竟程序的运行自己最清楚.不过开发的一般都不出差,而是由专门人员出差,然后在现场反馈问题.
升级倒是很方便,有专门的升级工具通过网络升级.

设备就是交通路口的抓拍机,调试代码保留的作用不大,因为即使有打印函数,也没有显示输出设备,一般情况下也不允许通过网络上报.

遇到的问题都是测试部测不出来,到现场出现了,机器拆回来后又很难出现,想一个方法能在整机运行的情况下查看到机器内部的运行状态,如果能允许简单的调试最好了.

将设备调入网络日志模式,控制哪些模块的日志允许上报,日志的详细程度可能起点作用

有没有更好点的方法,GDB远程调试是太复杂了,嵌入的代码都超过设备的正常代码了(个人瞎猜的,不是很懂)
简化点的GDB也许可行  

谢谢大家回复

#5


是不是各种设备整机情况下都很难调试?

#6


期待好的想法

#7


大致确定范围,在可能处插入一些未用 pin 的输出 或平时不肯能出现的动作 可否

#8


可行 不过老大不会同意任何涉及到硬件的部分 我们几乎是纯软

#9


希望能想到好点子