请教DSP调试方法

发表于 2012-11-25 17:38

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

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

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

发表于 2012-11-25 19:50

这个问题可不是你一个人遇到的啊，现场环境不好模拟的

发表于 2012-11-25 20:54

是啊每次整机出现问题,都被产品部人问为什么,对于程序员来说,看不见程序运行中变量的值就相当于瞎子,根本无从解决问题.应该想一种方式能让产品反馈更多的信息.

发表于 2012-11-26 08:56

1# xueqi_147
只能尽量让现场操作人员回想当时的情景，尽量复现！

但这有一个问题，即使问题复现了，用传统的手段也不定调试得了！
举例说明：
某种罕见的情况下，在你读一组数据时，你已经读了一部分了，但另一线程这时改写了数据。如果是在你读完全部数据它再写，或是它写完全部数据你再读，都不会出错！而你读过程中的数据改写显然会造成出错！　　事实上这两个线程作为异步线程，本来可能刚好能遇上这样的问题的，但由于以传统手段调试时，你已经将其中一个线程用断点中断下来了，两个线程的执行上肯定与正常不一样了！你的调试也不再有太大的意义！

因此这种不频繁发生的出错，最好的方法是使用AET，根据现场出现的问题的描述，来设置要监视的错误事件，这样错误事件发生时转储出全部线程状态和环境变量来进行分析　

发表于 2012-11-26 20:41

请教一下 AET是什么东东以前没听过话说我们调试竞争代码都是仔细阅读分析代码,打印信息,还没有什么好工具
对于你说的那种情况,现场的调试手段只要能告诉我程序哪一部分或哪一模块(范围越小越好)的竞争代码或数据没处理好就行,拆回家分析也有个目标.

发表于 2012-11-26 21:18

这是一个很纠结的问题啊

发表于 2012-11-26 21:22

经常遇到这种问题，也是无从下手啊

发表于 2012-11-26 21:25

主要是新产品刚上市的时候有这种问题,公司内部测试的又不完整,现场环境又复杂,才希望有这么一个手段,跑多半年就基本上修复个差不多了

广开思路啊,或者借鉴现成的模型

发表于 2012-11-27 10:40

我觉得测试人员应该对缺陷的定位负责，尽量在报告缺陷时将自己对于缺陷的理解(或缺陷产生的原因)写入到缺陷的备注信息(或缺陷主体)中。在个人能力、资源许可的情况下，尽我们所能的去提升我们的工作质量，做到100%的自我负责

发表于 2012-11-27 14:36

这问题目前挺常见的，但是一般根据现场出现的问题可以推断出哪里出问题了

发表于 2012-11-27 16:17

环境不好模拟

发表于 2012-11-27 23:15

测试人员都是窝在家里测试,想想也是,没有愿意上大街或到鸟不拉死的地方测试去呵呵

发表于 2012-11-28 13:15

跟周围的环境也要沾点边的吧，不然做出东西了一到实际环境就over了啊

发表于 2012-11-28 15:47

这现场环境有许因素是不确定的，感觉不是那么好模拟出来等

发表于 2012-11-29 20:16

看来是没有什么好办法了期待意料之外的想法

发表于 2012-12-5 14:13

记录一些些log也许有一些帮助吧，

发表于 2012-12-5 21:40

一般测试时间为编程时间的1.5倍啊，实属不易啊

请教DSP调试方法

相关帖子

浏览过的版块

技术新星奖章

希望之星奖章

TI

精华达人奖章

湍急之河流

常驻人口

技术奇才奖章

无冕之王奖章

奔腾之江水

伴坛终老

欢快之小溪

技术高手奖章

社区建设奖章

经常做客

突出贡献奖章

沉静之湖泊

核心会员奖章

坚毅之洋流

七世轮回