USB0 VBUS voltage divider

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

USB0 VBUS voltage divider

985 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by apriori on Thu Aug 13 00:00:43 MST 2015
In my current, self-powered design, the USB0_VBUS pin of a LPC4337JDB144 is connected to the USB connector's VBUS via a voltage divider as recommended in AN11392. With resistor values of R1=1.74 kΩ and R2=3.24 kΩ, I measure 3.25 V at USB0_VBUS when VDD is 0 V and VBUS is 5 V. With the device turned on, P2_7=LOW and booting into USB0 boot mode, I get 2.08 V when VDD is 3.3 V, just below the 0.7 * VDD threshold that is needed for the DFU firmware to recognize the attached USB host. That leads me to believe there's something equivalent to a 1.5 kΩ pull-down resistor at the USB0_VBUS pin instead of the 64 kΩ (+/- 16 kΩ) mentioned in the manual. This also fits the reports on this forum where people have been measuring in excess of 3 mA going through this pin.

Can anyone comment?
Labels (1)
0 Kudos
5 Replies

720 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by username1039r48 on Sat Feb 13 19:38:49 MST 2016
For anyone experiencing the same issue: The 1.5k pulldown is most likely caused by the vbus discharge bit being set (bit OTGSC->VD, see 25.6.16 in the LPC43xx user manual).

The usb library sets this bit by default, which is a bug i think.

If you disable the bit right after calling USB_Init(), a 15k/33k voltage divider should work just fine:



Quote:

USB_Init(corenum, USB_MODE_Device);
LPC_USB0->OTGSC &= ~(1<<0);



The current consumed by the Vbus pin in this case is < 50uA instead of >2mA.
0 Kudos

720 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by apriori on Wed Aug 19 07:21:01 MST 2015
That 74LVC1G66 looks nice too. What is R1 for in the schematic you posted?
0 Kudos

720 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by bavarian on Wed Aug 19 05:36:08 MST 2015
If you don't need discharging (means you don't need to cover the OTG use case) then you could leave the N-MOS out.
Personally I prefer the solution with a small analog switch 74LVC1G66 (see attachment) for non-OTG applications.

Regards,
NXP Support Team.
0 Kudos

720 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by apriori on Tue Aug 18 09:25:52 MST 2015
Thank you for the clarification.
In the next hardware revision, we will implement the solution given for OTG from the datasheet for LPC435x/3x/2x/1x devices (Rev. 4) in fig 49, page 141, using an N-channel and a P-channel MOSFET.
0 Kudos

720 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by bavarian on Tue Aug 18 05:18:00 MST 2015
For more than one reason the protection with the voltage divider is not a good solution. As you have already experienced, the VBUS pin changes its characteristics depending on settings made by the DFU bootcode. This, in addition to other effects like static power consumption,  makes this voltage divider risky to use.
Applying a voltage more than 3.6V to VBUS for a short time will not destroy the pin structure, it only has a long term effect. Over time it impacts the diffusion of the silicon. So don't worry about short periods with more than 3.6V.
A much better solution is the switch in front of the VBUS pin (discrete FET or a small analog switch like 74LVC1G66).

The comparator levels behind the VBUS pin make things also more complicated. For USB OTG there are different levels defined, the lowest level is normally enough to recognize the connection of a cable which provides power (i.e. the 5V). In a self powered device this event is enough, because the processor is in operation and can work on this event.
In a nutshell: if you want to avoid problems with one or the other application use case, take the switch solution instead of the voltage divider. I will discuss with relevant people to get the voltage divider proposal out of the documentation, or at least restrict it to a very specific use case where it is doing a reasonable job.

Note:  the problem with the higher power consumption during DFU bootmode has been solved in the bootcode of the LPC4357A (and the other flash devices). This version is in production since beginning of 2015 and replaced the earlier LPC4357 '-' version.

Regards,
NXP Support Team
0 Kudos