Click here to Skip to main content
15,867,568 members
Please Sign up or sign in to vote.
5.00/5 (1 vote)
See more:
Hi All,

The title says it really I want to drop the USB serial port via the application rather than the hard ware method I came up with (a switch). The issue is I am trying to run an auto test rig that needs to measure the quiescent current, but this is being upset due to the USB connection supplying extra current. My switch solution gets around this however the customer wants it all incorporated into the application, and has found an application to do it. All I am given is a Program file from a C# project:
RecoverSerialPortTool
and told to work with it. I believe it is an application from MSDN. It sounds possible but fraught with danger could I get others opinions please?
To disconnect the a USB device will it stop it dead, stopping all connection (not only Tx & Rx) but all power to the item connected (in this case an ICD)

Glenn

Looking around I have found:
How to Prepare a USB Drive for Safe Removal[^] Sadly the item I am trying to disconnect is not a drive...
Posted
Updated 12-Jun-14 23:43pm
v2
Comments
[no name] 13-Jun-14 6:11am    
Are you trying to interrupt the 5v supply to the port (and hence any plugged in device) using software on the PC side? That's hard wired. You can only interrupt it by unplugging device or using switch or some other method implemented in the hardware of the device.
Preparation for safe removal just ensures that all activity on the device has ceased.
What do you mean by serial port in this context?
glennPattonWork3 13-Jun-14 6:29am    
That's what I thought, but the client thinks there software guy has found this miraculous tool to do it! I think my method of a switch is the easiest way to but...
I wanted some one else to back me (harder to say you don't know...)
Thanks7872 13-Jun-14 6:28am    
Please post this comment using reply button at pwasser's post. It will notify him about your comment.
glennPattonWork3 13-Jun-14 6:30am    
Dang! Friday too tired!

1 solution

What the code is doing is dismounting the USB driver WHICH WILL DE-POWER THE USB if it formally meets the USB 1.1 specification. You can do it manually yourself to see the effect thru device manager in control panel or down on the task bar select to eject the device.
 
Share this answer
 
v3
Comments
[no name] 15-Jun-14 23:54pm    
Could you provide a reference in USB 1.1 spec which states this? What do you mean by "de-power" a term which is not mentioned in the spec? The USB spec refers to the device. It may go to a low power state on suspend but it always has the capacity to draw current from the bus. What you see in device manager has nothing to do with voltage you may measure on the bus.
leon de boer 17-Jun-14 20:07pm    
Perhaps read the basics in wikipedia (http://en.wikipedia.org/wiki/USB)

There are current resistors needed to detect the draw of the device and protect against over draw which was the problem with the old 1.0 USB ports is they would be physically killed if you shorted them because the 5V rail was raw.

Wikipedia covers the main changes to the USB physical interface and you will note 1.1 got actually overlooked in 2.0 and back in to spec in 3.0 although I have never seen a 2.0 device chipset without it.

Quote = "Battery Charging Specification 1.1: Released in March 2007 (Updated 15 Apr 2009).
Adds support for dedicated chargers (power supplies with USB connectors), host chargers (USB hosts that can act as chargers) and the No Dead Battery provision, which allows devices to temporarily draw 100 mA current after they have been attached. If a USB device is connected to dedicated charger, maximum current drawn by the device may be as high as 1.8 A. (Note that this document is not distributed with USB 2.0 specification package only USB 3.0 and USB On-The-Go.)"

Quote = "Link Power Management Addendum ECN: Released in July 2007.
This adds "sleep", a new power state between enabled and suspended states. Device in this state is not required to reduce its power consumption. However, switching between enabled and sleep states is much faster than switching between enabled and suspended states, which allows devices to sleep while idle."

If you go forward from that to USB 3.0 spec you will find the voltage and power draw are even now negotiated at device startup.

So the power supply to the port of a modern USB is nothing like a raw +5V rail it is front ended thru detection and protection circuitry in the USB chipset so it could detect what it calls a "standard load".

So on any of the major chipsets used for USB the power supply comes out of the chipset so I will randomly take one lets say cypress (http://www.cypress.com/?docID=33237). No initialize the chipset = No power to USB.

Anyhow the bottom line here is you can test it easily this get a dumb USB peripheral like a coffee warmer or lights or one of the millions of stupid USB toys that actually isn't actually a device but just using the power rail and then simply go to control panel in windows and remove the USB driver and watch what happens.

There is most definitely power to the USB like you describe IF AND ONLY IF the USB chipset is up and running normally because they need to make sure the protection circuits are in place which is usually monitored from within the chipset and the power rails to the USB come from the chipset itself. Every USB chipset I know of on the market will only power the USB port rails to a USB port if the chipset is initialized and enabled it would not be safe to do it any other way.

So you are correct when everything is up and running normally and the USB chipset is initialized and enabled.

Now if you read the response from the poster the clients machine clearly does exactly the above because the code the client found fixed his problem and the client was asking the poster to implement the function in his code. The posters problem was simply he couldn't understand how the clients code worked which I think we have covered now the how and why the clients code works.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900