1

So we have a product that has the below connectivity in relation to USB and power supplies. The device is a K66 MCU from Kinetis. Its datahseet is here:

https://www.mouser.com/datasheet/2/813/K66P144M180SF5RMV2-1074869.pdf

While we have 2000+ of these devices in use, there is a weird case which we cannot replicate where some users have the device fails when connecting the USB to their laptop. The MCU physically overheats and dies. This only happens on USB connection.

It is very rare, but there must be something in the design allowing this to happen. No I/O etc burden is placed because of USB, so it is purely USB related only. Stated though, incredibly rare - normally it works perfectly without issue.

Anyone any ideas as to perhaps misues of connectivity? We need the diode in place such that the MCUs USB works (apparently according to SW engineer it requires this "wake up" 5V from the USB port - but we do not want the device to become alive when just the USB is connected. Perhaps this is where the issue lies?

Over DSs https://mikrokontroler.pl/wp-content/uploads/pliki/KQRUG.pdf https://www.nxp.com/downloads/en/schematics/FRDM-K66F-SCH.pdf enter image description here

MattyT2017
  • 341
  • 2
  • 11
  • How do you know it overheats? Why do you have variable resistors in the data lines? You should have TVS diodes. – Ron Beyer Apr 02 '20 at 12:49
  • 2
    If your CPU is heating up then it could be that one of the inputs on the K66 is latching up due to the voltage going more than the input diode drop above the power rail. The most likely candidate would be the USB1 VBUS input. There can sometimes be a transient when the cable is plugged in. If you just need to sense if VBUS is present then run it through a series resistor. That would limit the current and avoid latchup. – crj11 Apr 02 '20 at 13:07
  • 2
    If your circuit is a 'USB device' (as opposed to being a 'USB host'), you should *not* be driving the USB5V line. This is unlikely to be the cause of your micro overheating, but it's 'illegal' for USB devices to do this. It's also not clear why you'd need the micro's USB peripheral to power up before it's connected to a host (PC). – brhans Apr 02 '20 at 13:53
  • 1
    I would check the relationship between grounds. Disconnected laptops (and some laptop power supplies) can float with respect to earth ground, and can make the potential between the laptop power and your circuit negative or greater than the processor can handle. – John Birckhead Apr 02 '20 at 22:32

2 Answers2

1

A few years ago I had a similar effect with this MCU. Sometimes I saw a high current (>1A) on the VBUS line into the controller.

Here is the answer which NXP gave to me:

The problem is, that the rising edge on USB1_VBUS is too fast, which can damage the pin. If the USB1_VBUS signal is not supplied from a common voltage source with the VREG_INx, the USB1_VBUS input should experience at least 100nF. NXP uses 10KOhm in parallel with 100nF to delay the USB1_VBUS edges.

Another problem is the 5V supply on the VREG_INx pins. If the voltage is applied very quickly, this rising edge should also be delayed with 100K ohms in parallel with a few 0.1µF.

schematic diagram

I added 10K parallel with 100n on USB1_VBUS and 100K parallel with 4u7 on VREG_IN. With these changes, I no longer saw the error.

SamGibson
  • 17,231
  • 5
  • 37
  • 58
Thomas
  • 11
  • 1
0

Per application schematics, the internal 3.3V regulator (for USB functional block) should be bypassed with 2.2uF cap, while you have only 0.1uF (C43). The regulator might become unstable on some "corner" IC samples, and HF oscillations might kill the IC.

Ale..chenski
  • 38,845
  • 3
  • 38
  • 103