In this video you're going to see just how little has to go right in order for a USB device to list in some way in [Windows] Device Manager and in Linux dmesg and hopefully find something useful to use in your thinking when troubleshooting USB problems. Recently, I made a video explaining that it's a waste of time to worry about device drivers for USB devices that aren't listing at all, for any length of time, in the Windows Device Manager and Linux dmesg or Mac System Information. I'll link it somewhere appropriate if you want to see that first. In that video, in an screen comment, I mentioned that in some cases a device doesn't even need to work well enough to return a device descriptor in order to list in these utilities. So that you can see that for yourself I've put together this little demo board. Although somewhat less conventional, I've soldered everything to the copper side of this single-sided board, and put that side facing up, you can see everything there is to see. There's nothing to speak of on the back side of this board. As you can see there's not a lot here. There's a header that a USB cable is going to be attached to, voltage regulator, a capacitor, a pair of DIP switches, and a pair of resistors. That's it. The copper strips are cut underneath the switches and resistors so those parts aren't being rendered useless by copper running underneath them. Rather than try to solder a USB jack onto the board I've crimped a 0.1 inch header to an ordinary USB 1.0/2.0 cable. On the outer pins we have ground on the left and USB bus voltage on the right, which is roughly five volt. The center two pins on the header are the D+ and D- USB data pins. The regulator is here to step 5 volt down to 3.3 volt because USB data signals are nominally 3.3 volt. There's an output capacitor on the regulator. And I've left space on the input and output sides of the regulator in case I needed more capacitors. As it turns out they weren't needed. So really, all that's happening on this little board is that the data signals are being individually pulled to three point three volt through 1.5 kOhm resistors if the switch is closed (or on). Otherwise, the wire just goes onto a copper trace for a few centimeters and is otherwise disconnected from anything. USB devices are detected when they attempt to electrically connect. Not merely because they've been physically inserted or attached. Though, most devices do electrically connect the moment they're physically connected. But, not everything does. The electronics behind a USB port will pull down on both data lines with 15 kOhm resistors or something equivalent. Note when the switches are open on our test board these pull downs in the USB port are the only things influencing the data lines. A USB device notifies the computer that it wants to be electrically connected to the USB bus by pulling up one of its data lines to a high level. Naturally, for that to happen it has to be physically connected. The USB standard says that when you pull one of the data lines high you're to do it through 1.5 kOhms. That's why I'm using those values. This 2 in the case code is the number of zeros after the first two digits. So, this is a 1 digit and a 5 digit followed by two 0s. Or one thousand five hundred ohms. That's 1.5 kOhms. If you do the math on a voltage divider with 15 kOhm on the bottom and 1.5 kOhm on the top You'll see the divided voltage is close enough to 3.3 volts to be considered a logic level high. But you can also just observe that the pull-down is an order of magnitude higher resistance than the pull-up. When nothing is connected the pull-down is all there is. So it dominates the situation and the signal is low. When the device pulls up with 1.5 kOhms, it's pulling up with an order of magnitude higher strength And so the signal comes to a logic level high. A device pull-up on D- indicates the connection of a low-speed (or 1.5 megabit) device. A device pull-up on D+ indicates connection of something faster than low-speed. Something at least 12 megabit. So, the 12 megabit full-speed, 480 megabit high-speed, and gigabit super speeds all pull up on the D+ signal to initiate a bus connection. Once the device pulls one of it's data lines high the host computer sends a series of standard USB messages to assign the device a bus address and to identify the device and its capabilities through little chunks of information called descriptors. The speeds higher than 12 megabit are negotiated partly through some combination of extra signalling and USB messages. But there's nothing on this board to do that negotiation. As you can see. There are no integrated circuits on this board apart from the voltage regulator. That is, there are no microcontrollers, no microprocessors, no USB transceivers. There's nothing on this board to fully communicate a USB message. It's just switchable pull-up resistors. Nothing that can send a device descriptor. And nothing for a driver to talk to. So, let's see what happens in Windows if we enable the pull-up on the D+ signal. [Windows 10 USB insertion tone
followed immediately by an error notification tone.] So you get the usual USB insertion tone, [for] Windows 10 in my case, followed by an error. In Device Manager there's now an entry with a diagnostic message attached to it that says "Device Descriptor Request Failed". And that makes sense, because there's no electronics here to do any proper USB communication and return a device descriptor. It's just a pull up. If I turn off the D+ pull up you'll see the entry disappears and you'll hear the USB removal tone. [Windows 10 USB device removal tone] Now, if I repeat the same process with the D- signal instead you'll see I get the exact same results. [Windows 10 USB insertion tone
followed immediately by an error notification tone.]
There's our insertion tone. And here's our entry. Showing "USB Device"... "Unknown USB Device", rather. "Descriptor Descriptor Request Failed". But notice that it it does at least show up in Device Manager in a limited way. If you list devices by connection, rather than by type, you'll see that the entry moves around depending on where in USB device tree you've inserted it . So, it knows which hub you've attached it to but not much more than that. There's no "Hardware Ids" [property] or anything like that listed in properties because there's nothing for it to talk to. It's literally just resistors that seeing here. In Linux the dmesg utility is a little more informative. But, the story is essentially the same. Here I'm running dmesg with options to wait for new messages and just to show the time delta between messages. Here's what happens if I turn on the D+ pull-up. As you can see, it says I've attached a full-speed device. The system thinks it's a full-speed (or 12 megabit) USB 1.1 connection
[Really USB 1.x] because of the pull-up on D+, but also because it was unable to negotiate up to a faster USB 2 or USB 3. That would require a chip to be paying attention to the data signals. You'll see the same failure to get a device descriptor, which makes sense. The dmesg utility is also more explicit about the device not responding to being assigned its USB bus address with the Set_Address USB request. You'll also see the system is trying to power cycle the port in an attempt to get a response. If I try this same test to the D- pull up you'll see the same behaviour, only it's detected as a low-speed device, since that's D- pull-up signifies. In neither case will the lsusb tool show an entry for the device. This is just dmesg. I expect windows can also provide some of the extra diagnostic information that Linux dmesg does, but that information is not front and center in the Windows Device Manager. So what can you do with this understanding? In short, it can inform your troubleshooting of USB problems. I can't give an exhaustive list of all the implications. But, I can give you four examples so that you can see how the thinking goes. And then no doubt think of scenarios that I didn't mention. Physical connections. If your Device shows up in Windows Device Manager or Linux dmesg in this way you can be certain that you have connections, of some quality, between your USB port and your board (or microcontroller) for data signals. Without those connections there would be no way for your board (or the chip on it) to pull the data line up to get the USB attachment process started. Therefore, your cable and the jack that it's connected to are probably fine. In particular, you can be reasonably certain that you haven't found yourself using one of those charge only USB cables that have no data connections in them. Enable/RESET signals. Most chips that handle USB signaling in hardware don't need to have external 1.5k pull-up resistors.
[It sounds like I said "or have", but I mean "to have"]. Instead the pull-up is implemented inside the chip. That's true for controllers and USB serial transceiver chips like the FT232, CP2102, CH340, etc. Fro microconrollers and USB transceivers if the chip is in reset, not enabled, or shut-down, etc, it will not be trying to electrically connect to the USB bus. So, if the chip has internal pull-ups and it is showing in Windows Device Manager or Linux dmesg with a failure to read device descriptor message you can at least know that the chip is not being continuously held in reset or otherwise lacking an enable. A microcontroller seems to be trying to connect. When microcontrollers initially start up they generally do so without attempting a USB connection. So, if you're using microcontroller with built in pull-ups for USB and it shows up in Windows Device Manager or Linux dmesg with a failure to read the device descriptor you know that he chip had to have at least run some code to either enabled USB peripheral, or (at a minimum) cause one of its USB data pins to go high. That code could be your code or USB aware bootloader. That also gives indication that the chip is being clocked, because it had to at least run some code. Maybe not at the right frequency. But, a wide range of frequencies will allow microcontroller to run code to signal a USB connection attempt because that part isn't particularly timing sensitive. Some designs try to connect by default. A Digispark bit-bangs USB and pulls its USB data lines to 3.3 volt with an external pull up. This means that signalling USB connection attempt is a default behaviour for these boards as soon as they are attached. This is true for a number of other boards that use the same or similar circuits on the USB data lines for bit-banging USB. With the chip held in reset, for those that have a working reset pin, or with the chip outright removed from the board, the circuit will still pull the USB data signals to 3.3 volt and because of that will show in Windows Device Manager or Linux dmesg with the failed to read device descriptor message. Under normal circumstances these boards are running code that will respond to USB requests by the time the host issues them. In order to not list in Device Manager of the chip has to be working well enough to be running code that explicitly drives the data signals low. Anyway. There are too many scenarios to address all of them. But the basic thing is that if the USB data signals are allowed to be pulled high, that's all it takes to show up in Windows Device Manager or Linux dmesg with this message that says it failed to read a device descriptor. I hope you found something in this useful or entertaining.
