7

免责声明:我(大部分)对硬件一无所知。这可能是我的问题。但是我发现很难接受无法调试硬件,因此我只是想获得一些第二意见。

我们有一个问题。某些操作(在运行时交换 USB 设备)可能会损坏 USB 集线器或 USB 板上的芯片(它是定制硬件)。这是一个模糊的问题(看起来“膨胀”的程度可能会有所不同),并且问题以间歇性方式表现出来,具有各种难以可靠重现的症状通常是数据包的随机损坏)。

这导致难以确定新报告的问题是由于此硬件故障还是实际上是软件中的错误。我们已经在这些设备上实施了保护,但如果未受保护的设备与受保护的设备一起使用,则有可能污染(现在受保护的)设备。其中一个端口也没有受到保护,这意味着有人仍然可以通过意外使用错误的端口“杀死”一个应该是安全的单元。

这样做的结果是,如果不完全更换所有硬件,就不可能知道我们的哪些设备遇到了这个问题(我们已经为大多数生产硬件咬住了子弹,但仍然有很多开发和 QA 硬件在那里与这个问题)。

我想这是可能的,给定一个硬件,人们可以使用某种硬件诊断工具来确定套件是否有故障。我生活在一个梦幻世界吗?我的硬件部门告诉我,唯一可以证明故障的测试是软件测试……但正如我所说,这些症状很难重现。由于我对硬件没有那么丰富的经验,我不知道这是否是唯一的答案。因此,我问世界。

4

6 回答 6

6

内置测试设备用于执行内置测试

以牙还牙

(不涉及字节。)

军事/航空航天设备有额外的硬件来测试自己是完全、完全正常的。

最初的 IBM PC 内置了数量惊人的测试硬件。

对于您的设备,测试设备和一些统计分析就可以解决问题。这可以在加密狗的硬件中完成,但坦率地说,使用一些软件会更容易。使用两个背靠背的 USB 到 RS232 串行转换器来制作 USB 环回设备。发送大量数据、校验和数据包并测量错误率。

我假设您的错误发生在 in->out 和 out-<in 方面。

确实,您的硬件人员需要查看一些应用说明;如果按照本书完成,USB是热插拔安全的。网上有一个很酷的例子,将 USB 芯片的连接光耦合到它所在的板上,以防止这种事情发生。USB 芯片连接到主机,由主机供电,USB 芯片的接口是 SPI,它通过光耦合回电路板的其余部分。

至于你,芯片部分失败了。受伤的设备可能会正常工作数月然后死亡。静电放电(“静电放电”)可以做与您描述的相同的事情。设备可能会因您感觉不到的震动而受伤。

半导体中的导线和特征是微观的,很容易被杂散电损坏。如果硬件设计大部分是正确的,那么您遇到的问题的潜在原因可能是在处理设备以插入/拔出时的 ESD。你的设备有自己的电源,它的地电压相对于 USB 电缆的另一端浮动,直到它被连接。

希望这可以帮助。

于 2010-03-11T02:03:43.993 回答
4

不,这不对。

许多硬件制造商从硬件测试开始。输入和输出 (IO) 只是评估电路流向的问题。考虑软件和硬件都处理布尔运算的抽象。

硬件的可读性差一点!

于 2010-03-10T13:23:59.073 回答
1

归根结底,硬件的通信线路(最基本的)是通过各种引脚的高和低。

我有一个兄弟(在汽车技术行业),他使用静电计来测量引脚上的电压以找出问题所在(我在该领域还不够聪明,无法更详细地了解他是如何做到的)。

于 2010-03-10T13:24:07.310 回答
1

您的问题是唯一已知的症状很难检测(USB 流中的数据包损坏),您将需要软件(在某种程度上)来检测它。

如果您能找出数据包损坏的原因(电压不好?),那么也许您可以用硬件检测到它?

否则,您需要某种强大的测试套件,以及发送/接收大量数据包以查找损坏的软件?

于 2010-03-10T13:26:43.130 回答
1

不,这就是示波器和逻辑分析仪的用途。还有更专业的设备,如USB 测试仪

于 2010-03-10T15:08:28.137 回答
1

硬件越简单,您对信号的访问越多,您就越有可能以“纯硬件”的方式对其进行诊断。例如,如果您有一个简单的并行端口卡插入 PCI 插槽,那么在 PCI 总线和适配器的输出上放置一个总线分析器会相对简单,并查看当卡被寻址时输出是否正确. 但请注意,您仍然需要尝试从 PCI 总线访问该卡,这意味着(A)某种 PCI 总线模拟,这将是一大堆测试硬件,或者(B)带有几行测试代码的廉价现成 PC。

但另一方面,假设您正在处理大型 FPGA。您可以将大量逻辑放入 FPGA 中,但您不一定可以访问您想要的所有测试点。我个人遇到了一个嵌入在 FPGA 中的串行端口的错误,其中移位寄存器预加载寄存器的竞争条件偶尔会损坏一个字节。假设 VHDL 可以重新设计以显示测试点,并且收集了一堆示波器和分析仪,但从管理的角度来看,尝试用软件解决问题更具成本效益。在正常使用情况下,有问题的错误会在每个蓝月亮出现一次。我们反复猜测会引发错误的条件,并改进测试代码,直到我们有可以每分钟重现错误 2-3 次的测试软件。那时,我们实际上可以向 VHDL 人员提供线索,帮助他们快速解决问题。

Long story short, inside of a week a hardware bug was smoked out via software, whereas starting with the same information and going 'hardware only' would likely have not been any faster, and would have required a lot of expensive test equipment. So, yeah, you probably can do it without software, but as usual it's a trade-off, and you have to find the right balance point between the amount of software vs hardware for the job.

于 2010-03-11T03:14:19.410 回答