Is there a way to programatically turning off the power or killing a USB port on the Mac?
I believe that the USB power typically comes directly from the power supply. It might go through the motherboard or some other hardware to combine it with the data lines, but I don't think the voltage ever goes through any programmable circuitry. If you wanted to deactivate the data transfer, that would probably be possible since that is handled by an extension file (IOUSBMassStorageClass.kext), but short of modifying the port physically, I don't think you will be able to deactivate the power.
If you're refering to USB storage devices, according to the Tiger Security Configuartion Manual (pdf):
6 To remove support for mass storage devices (e.g. USB flash drives, external
USB hard drives, external FireWire Hard Drives), drag the following files to the Trash:
IOUSBMassStorageClass.kext
IOFireWireSerialBusProtocolTransport.kext
7 Open the /System/Library folder.
8 Drag the following files to the Trash:
Extensions.kextcache
Extensions.mkext
9 Choose Finder > Secure Empty Trash to delete the file.
10 Restart the system.
I've seen some other stuff around but it's all much harrier. Leading gluing the ports up to get suggested quite a bit.
Related
so when I connect my development board (NUCLEO-f446re) to my laptop , everything is working normally , but there is only one thing that confuses me , see the next picture
windows recognize my development board as external storage device with 1.52 MB size (partition named NODE_F446RE(E:))
when I open it , the next image show what I see
there is only 2 files there , the .HTM file takes me to this link and the .TXT file has the follow content:
Version: V2J40M27
Build: May 5 2022 13:16:48
so I don't understand what does this mean ?, like what does 1.5MB storage represent in my MCU even though , the flash size of my MCU is only 512 KB which is way less than the shown storage , also what happens if I put any .exe file in that partition ?
From the web page you link (emphasis by me):
USB re-enumeration capability: three different interfaces supported on USB
Virtual Com port
Mass storage (USB Disk drive) for drag'n'drop programming
Debug port
Your board offers the option to program your application. Simply drap and drop the bin (binary) file of the application into this drive.
It is "just" a virtual drive, the software behind it does the flashing for you, if it receives a binary file.
Why the size of the drive is bigger than the available flash memory, is not clear. Perhaps to allow for necessary overhead to mimic a file system, and to have room for the files you see.
If you copy an exe file in it, I'd expect some kind of error message. Or that the file will not be stored. Experiment!
This functionality is perhaps not well documented, but is part of the "Mbed Enabled" functionality. It is a feature of the Mbed bootloader, to allow "drag'n'drop programming" via a "fake" mass storage device in order to avoid the need for special programming tools or protocols.
You can write to the device, but the "file" will not appear in the filesystem, rather the content will be used to program the on-chip flash memory.
The files on the fake drive are read-only - mbed.htm will open in a browser and take you to the Mbed sign-up/login where you can start developing using Mbed. details.txt contains details of the mbed firmware pre-loaded on the board.
At one time the Mbed on-line/in-browser IDE lacked hardware programming and debug capability, so this feature was the primary means of programming Mbed boards, and debugging was painful. I believe all that has changed now and the feature is perhaps less important in development.
https://os.mbed.com/platforms/ST-Nucleo-F446RE/
Some background on my issue, my company sells single-use short life battery powered USB devices that certain customers require a certain 'profile' config programmed into the device before shipping. We currently sell them in batches up to 2000. Each one is plugged into a computer(Windows) with our configuration software running, the device is auto detected and then notified when completed. Takes roughly 10-15 seconds per USB device. No input is required on the computer besides inserting the device.
As you can imagine this is a very slow process that is increasing in frequency. The device shows up as mass storage device with about 100kb of storage. All devices have the same name when showing in My Computer. The issue is the programming software does not detect if multiple devices are plugged in, only loading the profile onto the first device plugged in.
Looking for a possible suggestion/solution to improve the speed of configuring these devices? My scratch pad idea was to buy 10-20 port USB hubs and possibly look at enabling one port in sequence every 20 seconds either with hardware buttons or software setup.
I'm not sure if this will work with your programming software, but since the devices present themselves as USB Mass Storage devices, you might be able to plug a bunch of them in at once, then use a script to dismount them all and mount only one device at at time. A one technique to do that is to use the mountvol command.
To unmount a drive
mountvol [DriveLetter] /p
To mount a drive
mountvol [DriveLetter]
Source:
https://superuser.com/questions/704870/mount-and-dismount-hard-drive-through-a-script-software
Another option would be to bypass the programming software entirely. You could use the programming software once to figure out what it is doing to the device (I would guess it's just copying some config file onto the drive). Once you know what it's doing, write your own script that can handle many devices in parallel.
I have read that USB HDD are hot-pluggable but not removable whereas USB Flash drives are both removable and hot-pluggable.Internally, the windows DEVICE_OBJECT structure has Characteristics flag that can have a value FILE_REMOVABLE_MEDIA for removable media (not the removable device). Also, STORAGE_HOTPLUG_INFO structure has Devicehotplug boolean member that says device is hot pluggable or not. Can you please justify your answer with a little details?
David Zeuthen explains it best:
[...] "removable" means that the media of the device is removable. For
example, CD-ROM drives or Nin1 card readers for flash media. [...]
ATA disks connected via eSATA aren't removable, you can't remove the
platters.
Yet of course, you can intuitively understand that even non-removable devices can be hotpluggable (i.e. you can plug and unplug the entire device as a whole, as opposed to inserting/removing the media it contains).
Now, all (modern) buses in use in current systems are hotpluggable -
most new systems allow you to add/remove SATA disks while the system
is running.
Indeed you shouldn't have to care much about whether something is hotpluggable or not anymore: virtually all storage devices are. (In the past, you had to shutdown the machine to manipulate the storage devices).
So, it should follow that external USB drives (either HDDs or flash sticks) for example should be non-removable and hopefully always hotpluggable.
Unfortunately:
Of course, hardware sucks so virtually all USB keyfobs reports
"removable==1" probably because the maker of the device wanted to be
"helpful" and make things work better on windows.
I have no sources regarding the real reasons, but it turns out that many USB drives report themselves as removable too. David's suggestion that it might be because of certain operating systems which didn't use to support hotplugging but did support removable devices (CD-ROMs, etc) sounds reasonable: the manufacturers reused the same technique to trick the OS into letting the user "eject" USB drives.
Nowadays I would guess all modern operating systems make the distinction clear, and this has many advantages from a management standpoint (e.g. you might have a hotpluggable DVD drive with removable DVDs and you would thus need to be more clear about which you want to interact with). Still, older drives and old habits die hard, so you'll still find some "removable" USB drives even if they're really not.
Note: The bug report linked is about udisks which is more often found in the free software world. But again, I'm sure all systems make the distinction now even if the terminology is not exactly the same. Also note that the terminology is really rather arbitrary, though whichever terms you use for these two concepts best be well understood.
A simple Google search could have answered your question...
Hot plugging is the ability to replace or install a device without shutting down the attached computer. Hot plugging is implemented when
a peripheral device is added or removed; a device or working system
requires reconfiguration; a defective component requires replacement
or a device and computer require data synchronization. Also known as hot swapping. Hot swapping
allows easy accessibility to equipment and the convenience of
uninterrupted systems.
Removable media are data storage devices capable of computer system removal without powering off the system. Removable media devices are
used for backup, storage or transportation of data.
source: techopedia dot com
Is there any way Not to detect USB from windows PC?
The USB device should not mount on windows PC ,It should be handled by my application..
Suggestions please...
As far as I know there is no way of stopping the mount on the windows PC, however, you could set it up to autorun so that when it is plugged it in attempts to launch your application. This answer has some information on how to do this: https://stackoverflow.com/a/255067
There is also the option to hide a drive in windows by removing is drive letter (http://www.howtogeek.com/97203/how-to-hide-a-drive-in-windows-so-that-no-one-will-know-its-there/) however, this is almost certainly going to stop your application from reading it too.
If this is for a specific security reason then perhaps you could look at encrypting the drive and allowing only the application to decrypt the data. Thus, whilst mounted in windows it will be of little use.
Sorry I couldn't be of much more help.
Microsoft provides a utility called devcon for free download.
It's a "Command Line Uility Alternative to Device Manager".
It can actually do many things that I won't get into here, but removing a plug & play device is a simple operation once you know the unique name of the device you want to manipulate.
Refer this to check how to work with it.
It sounds like you don't want your device to show up as a drive in My Computer. In that case, why are you using the Mass Storage Device class at all? You could make a custom, vendor-specific device and talk to it using control/interrupt/bulk transfers with WinUSB. You would need to change the Device's USB descriptors to indicate it is a vendor-specific device and not a mass-storage device.
Do you know a way to use the Windows XP API to reset the USB bus? In other words, I'd like the OS to kick out any USB devices that are currently connected, and then auto-detect everything anew.
I'm aware of devcon, and I suppose I could do system calls out to it, but I'm hoping for a direct call into the API.
From kernel mode: You can force a specific USB device to be re-connected, as if it was unplugged and replugged again, by sending an IOCTL_INTERNAL_USB_CYCLE_PORT to its PDO. (This can only be done from a kernel mode, e.g. through a helper driver.) This 'cycle' operation will cause a USB reset to occur, after which the device would be re-enumerated. For example, if the device comes back with a different USB device descriptor, a different driver may be matched for it.
From user mode: You can do this by ejecting the device through the CfgMgr API. For example, to go over all USB hubs and eject all devices:
Find all devices having device interface GUID_DEVINTERFACE_USB_HUB with SetupDiGetClassDevs(... DIGCF_DEVICEINTERFACE).
Enumerate over the returned device information set (SetupDiEnumDeviceInfo).
For each device, get the DevInst member:
Invoke CM_Get_Child(DevInst) and then CM_Get_Sibling repeatedly to go over all child nodes of the hub (i.e. the USB devices).
For each child node, call CM_Request_Device_Eject.
Well, use can use the Setup API (SetupDiXXX functions) to enumerate the USB devices in the system, and then call WinUsb_ResetPipe on each one, but I'm not sure if that's what you're looking for. It's been a while since I worked with USB devices, but as I recall, there is no standard way to reset a device (i.e. simulate a power off/power on cycle). If it's possible for a particular device, you'd have to send an appropriate IOCTL (using DeviceIOControl) to the driver. The IOCTL would vary from manufacturer to manufacturer.
It's possible to cycle the parent port on the USB hub the device is attached to, as well. This will result in, among other things, apparrent unplug/replug actions, as you will see a balloon popup when this occurs.
Much of this is poorly documented, and honestly, I've gotten the impression there are only a handful of people at Microsoft who really understand it well. The design decision I've made for future devices I design is that I intend to include watchdog functionality on both sides, as well as a device-side full reset function. That way, if the device figures out it is confused, it can just cut its own power for a second and fully reset, if the host can't communicate with it, it could do the same thing, and if the device thinks everything is fine but the host knows better, the host could order it to reset.
There are at least three APIs worth looking into for this problem: the Setup API, the Config Manager API, and various WMI extensions. However, be cautious about diving into WMI if you intend to use an Embedded XP target, as you will have to include a lot of other things in your OS image you might otherwise not need.
As far as I know, there is no way to do this - you can issue a command to have PnP rescan the bus for new devices, but that isn't the same as issuing a bus reset.
Furthermore, just because from a hardware perspective you issued a bus reset doesn't mean that Windows will remove the PDOs that represent the children of the hub and redetect them; the USB bus driver can (and does) do just what I describe (i.e. issue hardware bus resets without disturbing the device tree), and only after the device doesn't respond does it issue the surprise removal and yank it from the tree.