USB port not working

[AndyH76]

What would you like to know?

Recently tried installing the new PortaPack H1 firmware on my HackRF, which recently stopped working with my laptop or PC in both normal and DFU mode.
Here's what I discovered:
The hackrf still powers up fine and Portapack functions as normal
dfu-util does not flash or list any devices when the hackrf is in dfu
lsusb does not show anything related to the hackrf in normal and dfu mode
dmesg does not change when i plug or unplug the hackrf in normal and dfu mode
I have gotten the above results with different micro USB cables, including ones that I know work with HackRF, and on two separate computers. I'm assuming the problem is in the USB port circuitry. There are no visually faulty components. There is no short circuit between ground and the D- D+ pins of the USB port. The current consumption when connecting HackRF to the computer is 180 mA.
What can I do to fix this?

[martinling]

Does this happen with the Portapack removed? We've seen some Portapack variants that prevent the HackRF from entering DFU mode correctly.

[AndyH76]

Does this happen with the Portapack removed? We've seen some Portapack variants that prevent the HackRF from entering DFU mode correctly.

Yes, I've tried plugging it in with and without the Portapack

[martinling]

OK, I think it's clear that there's some kind of hardware failure/damage then.

There is not much in between the USB port and the microcontroller. The D+ and D- lines connect directly to the MCU via R57 and R58 which are just zero-ohm resistors.

There is also an ESD protection diode array U15 attached to those lines which could perhaps have failed. But if that had failed in a way that prevented operation you would expect to see a short from the D+/D- lines to either GND or VBUS. You could try removing U15 anyway - everything should work without it, but will be more vulnerable to ESD until that part is replaced.

The other thing that's necessary for the microcontroller to show up on USB is that it needs to see a ~3.3V voltage at pin 21 (USB0_VBUS) to indicate that the 5V supply is present at the USB port. Check with a voltmeter whether this voltage is present - it's produced by the potential divider formed by R62 and R65.

One failure mode that we've encountered before is where a high voltage has somehow been applied to USB0_VBUS, and has blown that pin of the MCU. This can happen either by a faulty USB charger supplying > 5V to VBUS, or by a misbehaving PortaPack supplying > 5V to VIN, which then gets into VBUS via Q5. In that scenario the only solution is to replace the MCU. A common symptom of this is that the USB0_VBUS pin draws a high current and the MCU gets quite warm when connected to USB.

I'm not sure off the top of my head what the VBUS current should be in DFU mode, I'll check that for you.

[martinling]

Note that which board revision you have is also relevant here. Prior to r7, USB0_VBUS was directly connected to VBUS (R62 is zero ohm, R65 is 10k).

In r7, we changed R62 and R65 to 10k and 18k to form a potential divider that limits the USB0_VBUS voltage to ~3.3V and thereby provide some protection against >5V inputs.

[AndyH76]

OK, I think it's clear that there's some kind of hardware failure/damage then.

There is not much in between the USB port and the microcontroller. The D+ and D- lines connect directly to the MCU via R57 and R58 which are just zero-ohm resistors.

There is also an ESD protection diode array U15 attached to those lines which could perhaps have failed. But if that had failed in a way that prevented operation you would expect to see a short from the D+/D- lines to either GND or VBUS. You could try removing U15 anyway - everything should work without it, but will be more vulnerable to ESD until that part is replaced.

The other thing that's necessary for the microcontroller to show up on USB is that it needs to see a ~3.3V voltage at pin 21 (USB0_VBUS) to indicate that the 5V supply is present at the USB port. Check with a voltmeter whether this voltage is present - it's produced by the potential divider formed by R62 and R65.

One failure mode that we've encountered before is where a high voltage has somehow been applied to USB0_VBUS, and has blown that pin of the MCU. This can happen either by a faulty USB charger supplying > 5V to VBUS, or by a misbehaving PortaPack supplying > 5V to VIN, which then gets into VBUS via Q5. In that scenario the only solution is to replace the MCU. A common symptom of this is that the USB0_VBUS pin draws a high current and the MCU gets quite warm when connected to USB.

I'm not sure off the top of my head what the VBUS current should be in DFU mode, I'll check that for you.

Thank you friend for such a detailed and comprehensive response. I have looked through all the answers to this question and your answer is the best!
I checked everything according to your instructions. I noticed that the voltage on the USB connector is 4.3V and it is constantly changing between 4.3-.4.7V. After I removed the TVS diode U15 the voltage stabilized to 5V.
I measured the voltage on pin 21 and it is 5V.
After all my actions I tried to connect the HackRF to the computer but no changes happened.
Most likely you are right and you need to change the microcontroller U23 or use HackRF and Portapack without using the computer.
But why is my U23 chip not warming up? And why is the voltage on pin 21 5 V and not 3.3 V as you write?

[martinling]

It sounds like in your case both U15 and U23 were damaged then.

But why is my U23 chip not warming up?

This may not always happen - it will depend on exactly what damage happens internally when the chip is overstressed.

And why is the voltage on pin 21 5 V and not 3.3 V as you write?

Which board revision do you have? If it's r6 or earlier this is normal. The USB0_VBUS pin is 5V tolerant and was designed to be connectable directly to VBUS.

In r7 and later revisions though, we changed R62 and R65 to 10k and 18k respectively, to form a potential divider putting ~3.3V into pin 21. This is sufficient for the MCU to see that VBUS is present, but provides some protection against >5V inputs. You could make the same change to a pre-r7 board by replacing those resistors.

However, this only provides some limited protection to the USB0_VBUS pin itself. A faulty USB charger or misdesigned PortaPack will still be able to damage the HackRF.

[AndyH76]

It sounds like in your case both U15 and U23 were damaged then.

Thanks again for your help. Replacing the U23 solved my problem.
What replacement can you suggest for U15 other than VBUS54CV-HSF-G4-08?

[martinling]

VBUS54CV-HSF-G4-08 is what we've tested and used in production, and is readily available. I don't think a failure of the TVS is the source of the problem here - it looks more like both U15 and U23 failed as a result of overvoltage from an external source. A TVS is only there to guard against very short transient spikes due to static discharge etc, it cannot protect against a more prolonged overvoltage condition.

If you'd still prefer to try a different part then from some brief searching it looks like Diodes Inc DRTR5V0U4LP16-7 or Semtech RCLAMP0504P might be pin-compatible replacements with similar specifications, but check closely - I haven't verified.