Can't debug hardware without software?

Question

Disclaimer: I am (mostly) hardware ignorant. This is probably my problem. However, it’s hard for me to admit that it’s impossible to debug hardware, so I just wanted a second opinion.

We have a problem. If certain actions (minimizing Usb devices in standby mode and exiting at runtime) can delete either a Usb hub or a chip on our Usb board (this is custom equipment). This is a fuzzy problem (it seems that the degree of “swelling” may vary slightly), and the problem manifests itself in an intermittent mode with various symptoms that are very difficult to reliably reproduce (usually this is accidental packet damage).

This leads to difficulties in figuring out whether a recent problem is related to this hardware error or is actually a software error. Since then, we have implemented protection on these devices, but if an unprotected device is used with a protected device, it can then infect the (now protected) device. One of the ports is also unprotected, which means that someone can “kill” the block, which must be safe by accidentally using the wrong port.

As a result of this, it is impossible to say which of our devices suffers from this problem without completely replacing ALL equipment (we bit the bullet for most of our production equipment, but there are still a lot of dev and QA hardware out there with this problem).

I would suggest that using hardware, you could use some kind of diagnostic hardware to determine if the kit is defective or not. Do I live in a dream world? My hardware department tells me that the only tests that can prove their guilt will be software tests ... but, as I said, the symptoms are very difficult to reproduce. Since I don't understand hardware, I don't know if this is the only answer or not. Therefore, I ask for peace.

Answer 1

Embedded Test Equipment Used to Perform Embedded Test

BITE for BIT

(no bytes involved.)

It is only natural that military / aerospace equipment requires additional testing equipment.

The original IBM PC is very surprising in the amount of built-in test equipment.

In the case of your equipment, the test device and some statistical analysis will do the trick. This can be done in hardware in keys, but frankly, it would be easier with some software. Use two serial USB to RS232 serial converters to create a USB short circuit device. Send a lot of data, checksum packets and measure the error rate.

I assume that your errors occur on the input as well as on the outside.

In fact, your hardware guys should look at some application notes; USB IS hotplug-safe IF made in accordance with the book. In the fiber optic network, there is a chip connection on the board to prevent this. The USB chip is connected to the host, powered by the host, and the interface to the USB chip is SPI, which is optically connected to the rest of the board.

Like you, the chips partially do not work. Damaged devices can work normally for several months, and then die. Electrostatic discharge ("static heading") can do the same thing you are describing. The device may be damaged by sensations that are too small for you.

Wires and features in semiconductors are microscopic and are easily damaged by stray electricity. If the hardware design is mostly right, the cause of the problems you were experiencing is probably the ESD when the devices are being processed to connect / disconnect. Your devi has its own power supply, and its grounding floats relative to the other end of the USB cable until it is connected.

Hope this helps.

Answer 2

No no.

Many equipment manufacturers begin testing equipment. Inputs and outputs (IOs) are simply an estimate of where the flow is. Consider the abstraction that both software and hardware in logical operations.

The equipment is just a little readable for humans!

Answer 3

When it comes to this, the hardware communication line (in its core) is HIGH and LOW through various pins.

I have a brother (in the automotive technology industry) who also used an electrometer to measure the voltage at the contacts to isolate where the problem is (I'm not so smart in this area to talk more about how he does it).

Answer 4

Your problem is that the only known symptom is so hard to detect (packet corruption in the USB stream) that you need software (at some level) to detect it.

If you can decide why the packages are damaged (bad voltages?), Maybe you can detect this with equipment?

Otherwise, do you need some kind of reliable testing kit and software for sending / receiving a large number of packages to search for corruption?

Answer 5

Not. This is what is for oscilloscopes and logic analyzers. There is also more specialized equipment, such as USB testers .

Answer 6

The simpler the hardware and the more access to signals you have, the more likely it is that you can diagnose it in a “purely hardware” form. For example, if you had a simple parallel port card connected to a PCI slot, it would be relatively simple to put the bus analyzer on the PCI bus and the adapter output and see if the outputs were working correctly when the card was addressed, but note that you are all you also need to try to access this card from the PCI bus, which would mean (A) some kind of simulation of the PCI bus, which would be one of the big bunch of test equipment, or (B) a cheap ready-made PC with several lines of test code.

But then at the other end of the spectrum, suppose you are dealing with a large FPGA. You can get one trait of many logic in FPGAs, and you don't necessarily have access to all the test points you want. I personally encountered an error with the serial port built into the FPGA, where the race condition with the shift register preload register sometimes caused a byte corruption. Hypothetically, VHDL could be redone to identify breakpoints, and heaps of sights and analyzers gathered, but from a management point of view it was much more profitable to try to tease the problem using software. Under normal use, the error in question would appear once every blue moon. We repeated the assumptions about the conditions that could cause the error, and clarify the test code, until we had test software that could reproduce the error 2-3 times per minute. At this point, we could provide the keys to the VHDL guys who helped them quickly solve the problem.

In short, after a week, a hardware error was smoked using software, while starting with the same information and “only for equipment” would most likely not be faster and would require expensive test equipment. So, yes, you probably You can do this without software, but as usual, this is a compromise, and you need to find the right balance point between the amount of software and the hardware to work with.