I have configured a USB CDC peripheral on the STM32F4 which starts automatically. I have also enabled the STOP power mode but the USB device disconnects when it enters STOP and does not reconnect when the device wakes up. What do I need to do in order for the device to successfully restart when it wakes up?
I can restart the USB device by calling the USB_LL_Start / HAL_PCD_Start functions but I want to prevent it from disconnecting and I am not sure how to do this.
Related
I'm using atmega168 with AVRUSB. (yeah, old version of V-USB. already integrated and seems to work otherwise, so no hurry to change)
My hardware can be powered by USB or via other source. How can I detect if the host is actually connected? It would be also nice to init USB whenever it's connected, but not necessary. Most important is that I need to skip the blocking USB polling if there's no host.
The hardware I'm using doesn't have USB VBUS connected to any GPIO, so a software-based method is required. Maybe I could add some timeout to the USB init routine or something similar?
I have a device connected to a USB and it periodically sends data to my PC. During the time it is not sending data, the USB cable needs to be removed, else, the device won't work (a fail-safe feature, if the USB cable is connected and attached to pc, the device is in communication mode, if the USB cable is disconnected from pc, it is in stand-alone operation mode).
I was thinking to use the Devcon so I font has to use another hardware, I'll just disable the USB port during an operation mode, then enable it during communication mode. However, the periodic transfer of data can be set to every 5,10,15,30 minutes depending on the settings.
My question is, will it be okay to disable/enable the USB port periodically? Say every 5 minutes? Won't it cause any problem in the long run? Or would it be more efficient for me to use external hardware, a switch to connect/disconnect the USB? Appreciate any advice or thoughts.
If devcon works for you, I don't see why it would cause any problems in the long run. There is no inherent reason why the hardware should get damaged when you run some commands in your software to disable a USB port.
Using external hardware to accomplish the same thing would not be more efficient because you'd have to pay for the hardware and maintain it.
I'm working on a USB MIDI device that will function as the receiver for a wireless system. This device will communicate bi-directionally though a radio module with the transmitter, a separate piece of hardware that runs in USB host mode.
The receiver will be plugged into a PC. MIDI devices plugged into the transmitter need to show up on the PC as MIDI ports. Since the transmitter supports a USB hub, there can be multiple devices plugged in.
There are two requirements that I'm not 100% how to meet:
1.) The MIDI port names on the PC end need to reflect the name supplied by the USB device plugged into the transmitter so that it's clear which device the port is for.
2.) The set of MIDI ports on the PC needs to update when devices are plugged/unplugged from the transmitter. This is the crux of the question: is there a way to update the available USB interfaces/MIDI jacks initiated by the device?
The brute force way of doing this would be to completely reset the receiver any time it receives a message from the transmitter that there's been a change (on reset,the receiver would then poll the transmitter for current devices and supply the updated info when the host PC re-enumerates).
The transmitter/receiver hardware are both based on PIC32MZ MCUs (no RTOS). I'm good with writing the USB code to get the host/receiver end to do whatever. The question is about how, at the level of the USB protocol, to do this.
Also, just to be clear: The transmitter/receiver communication will be an ad-hoc protocol and the receiver will set up all its USB configuration data itself; the idea isn't to attempt to seamlessly enumerate devices over the wireless link.
To show the port names on the PC, just copy the USB descriptor strings over to the transmitter.
The only way for a USB device to change its configuration is to reset itself, as if it had been unplugged, and to let the host re-enumerate it. So the only way to prevent multiple devices from interfering with each other is to have multiple (virtual) USB devices on the receiver. If your hardware does not support this, then you cannot avoid the reset.
I configured a 3G modem (Novatel Wireless U679 (Ovation MC679)) on a Raspberry Pi running Raspian OS. To switch the modem from storage mode (1410:5059) to modem mode (1410:7031), I use the following command:
sudo eject /dev/sr0
I then use Sakis3G script to establish the connection with:
sudo /usr/local/bin/sakis3g/sakis3g connect OTHER="USBMODEM"
USBMODEM="1410:7031" USBINTERFACE="0" APN="crstat.bell.ca" APN_USER="0"
APN_PASS="0" USBDRIVER="option"
I also use UMTSkeeper to keep the connection alive if this one drops.
The 3G connection lasted 2 days before dropping for the first time and then never reconnected. When I tried to reconnect manually by reissuing the above sakis3g command, I got the following answer:
Already selected value USBMODEM="1410:7031". Is not valid.
So I typed 'lsusb' at the command line, I saw that the modem product ID was back to storage mode (1410:5059). If I try to switch it again to modem mode using the command 'eject', this time the modem disappear from the 'lsusb' list.
Here are my questions:
1 - Why the product ID switches back to storage mode after a connection drop?
2 - How can I switch it again to modem mode after a connection drop?
3 - How does these steps integrates with UMTSkeeper so that it reconnects automatically?
i am not sure what exactly is the problem.. but i too had this issue. In my case the raspberry pi doesn't switch automatically so i had to use a command to switch it. the command i used was :
" sudo ./sakis3g swithonly "
it switches the dongle from storage mode to modem mode and i don't face any problem like that of yours. my dongle remains in modem mode even if disconnect the connection. it goes back to storage mode only if i unplug and then re-plug.
Hope this helpful!
If there is a possible, both HOST and slave are in sleep status, but USB physical connection is permanently (USB bus is sleep as well) and then, slave can wake up HOST via USB bus?
There is a wakeup signal on USB bus. A host can suspend the bus; a device can react to some external event, send remote wakeup and activate the host.
For example, a USB hub with no devices attached will get suspended by the OS right after enumeration. However, when a device gets connected to a hub it will send a wakeup to have the host activate the bus and enumerate the device.