Function of UD_VBUS signal on EMX

I wonder if someone in the know could enlighten me as to the function of the UD_VBUS signal?

In an effort to track down sporadic start-up problems, we started wondering if having the USB 5V connected to the EMX when the device was powered down could possibly cause damage. In a battery powered device with USB charging, it is common to have the device powered off, while the USB is still connected and charging the battery. All the EMX schematics and the example USB circuits on the LPC2478 data sheets show a direct connection between the USB 5V and UD_VBUS (EMX) , or P1.30 Vusb(LPC2478).
Gus tells me the EMX pin and MCU pin are directly connected, possibly with a 10k series protection resistor.
LPC2478 data sheet says “This signal must be HIGH for USB reset to occur”, whatever that means. EMX says “Connect to power on USB device”

Anyway, I cut the track to the pin (26) on the EMX, which promptly jumped to the 3.3V level.
I have now tested it in both USB debug mode, and COM port debug mode running our USB transport, with the pin connected to USB power, 0V, and floating, and connected to a host PC, a USB plug-pack, and USB disconnected, I have found no difference at all. USB debugging works (when USB is connected), our transport sees the USB device and talks to it, the PC recognizes it correctly. Debug messages in our code show it detects when plugged in to the PC and is able to communicate, and when it is unplugged.

Given this, does UD_VBUS actually do anything, or can I just cut the track to it? Perhaps it is only used in other modes, providing an interrupt on insertion - our application appears to run a dedicated polling thread? I had intended to insert a high-value protection resistor or a FET to disable the line when the 3.3V rail was down, but now I’m wondering if this it even necessary.

Thanks, David

If I remember correctly, this pin is no longer used and I doubt it is the cause to your problem.

Ok, I’ve asked them to cut the track on one at the plant and test it. If it still works the same there it will help eliminate another possible problem.

BTW They told me they have reduced the code demonstrating the lock-up to only a couple of lines in USB startup, and should have a test project to me within the hour, so hopefully we can pin this down then.

We are ready to test once we revieve it.