DSP调试方法

1万 · 2018-3-12 17:44

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

1万 · 2018-3-12 17:48

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

1万 · 2018-3-12 17:52

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

1万 · 2018-3-12 17:54

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

1万 · 2018-3-12 17:57

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

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

1万 · 2018-3-12 18:01

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

1万 · 2018-3-12 18:06

请教一下 AET是什么东东以前没听过话说我们调试竞争代码都是仔细阅读分析代码,打印信息,还没有什么好工具

1万 · 2018-3-12 18:13

对于你说的那种情况,现场的调试手段只要能告诉我程序哪一部分或哪一模块(范围越小越好)的竞争代码或数据没处理好就行,拆回家分析也有个目标.

1万 · 2018-3-12 18:16

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

1万 · 2018-3-12 18:18

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

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

2万 · 2018-3-12 18:23

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

1万 · 2018-3-12 18:26

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

2万 · 2018-3-12 18:28

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

1万 · 2018-3-12 18:33

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

1万 · 2018-3-12 18:36

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

1万 · 2018-3-12 18:38

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

1万 · 2018-3-12 18:43

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

1万 · 2018-3-12 18:46

先结贴了哈

DSP调试方法

相关下载

相关帖子