I have a SOM module working on AM3352 TI processor. It has 2 USB ports. One of the port is connected to a USB hub on-to which a USB camera is connected.
AM3352 USB <---------- USB HUB <----------- USB Camera
On the system I also have another module which runs on 6.3 V. Since my input is only 5V, I am using a DC-DC converter to boost the voltage to 6.3.
What I observe is that, when I turn on the 6.3V module, there is dip in my input voltage for a short duration. The VBUS goes below 4.4V for this time period and I get a VBUS error. The voltage goes back to the previous state after this time but my device gets dropped. I wont be able to use the camera after this
Is there a way to restart the full usb driver so that the camera will get detected and I can use it for the intended purpose?
Related
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 have Raspberry Pi 3 plate with connected USB to UART (COM) converter.
The power led on the USB stick is ON.
I can not find the converter in Windows Device Portal.
In both: connected and disconnected states I see just two UART related records in Device Manager:
(ID:ACPI\BCM2835\0, Class:System, Manufacturer:Microsoft, StatusCode:25165834)
>BCM283x Mini UART Serial Device
(ID:ACPI\BCM2836\0, Class:Ports, Manufacturer:Microsoft, StatusCode:25182218)
>ARM PL011 UART Device Driver
(ID:ACPI\BCM2837\4, Class:System, Manufacturer:Microsoft, StatusCode:25165834)
Also I use git diff between saved device lists and there is no difference between the case I connect USB stick and disconnect it.
Where can I see the device in the list?
UPDATE
Here I print all found devices:
First you need make sure your USB to UART (COM) converter is supported on Windows IoT Core. Please check the hardware compatibility list. The CP2102 USB 2.0 to TTL Module Serial Converter is supported.
I use CP2102 USB to UART Bridge Converter and it also works. Use the SerialUART sample can list two device: one is on-board PL011 UART Device and the other is mine.
From device portal:
I made a STM32F042k6, battery powered device, that I would to flash vi DFU protocol.
In order to do so I disconnect the battery, I pull BOOT0 to VCC, and then plug the device in USB3 port of PC (no USB2 available). The device is not recognized and showed
VID:0000 PID:0002 (case I)
However, when I first connect battery, and then connect the device to PC it is recognized without a fuss (case II).
The problem I face is that I would like to initiate jump to bootloader program by command in software - but then I reach exactly the same condition as in case I.
Could you help me to identify what conditions for proper boot I am violating?
EDIT:
The way I have discovered the problem was when I implemented software jump to bootloader. It seemed not to work at all (VCP device dissapeared, and erroreous <> device appeard in system PID:0002 VID:0000).
I wanted to enter bootloader by pulling up BOOT0 pin, but I could see that I sucseed only when battery-power cycled. USB power cyccle resulted in the same "failed descriptor" device.
I suspect that when powered on via USB, the booloader has som ecommunication problems and cannot establish proper PID and VID. When powered via battery - this problem is not existing.
Do you have a discovery board?
I read in the STM32F042x4/x6 Reference Manual (DocID025832 Rev 5):
The STM32F042x4/x6 embeds a full-speed USB device peripheral compliant
with the USB specification version 2.0.
(part 3.19, p.27).
In the AN2606 (Rev 33), a table shows the USB configuration which is used by the DFU Bottolader in USB FS (Full-speed):
I assume that the USB in the bootloader is the 2.0, but USB 3.0 must be USB 2.0 compliant. So it is possible to use an USB 3.0 port.
I suggest you use the DfUSe Demo from ST. Its interface consists of a tab where the DFU devices available are displayed when detected. I try it on another STM32x by following these steps:
Open DfuSe Demo software.
Plug BOOT0 to Vdd to put the micro on DFU mode.
Plug the USER USB to your computer port.
The name of your device should appear in “Available DFU Devices” field.
You could try to use directly PA11 and PA12 as well (according to Table 12) instead of the USB port of your board.
EDIT:
Another solution to upgrade your firmware without driving boot0 is to jump directly into the DFU bootloader of ST inside your firmware. Else you could design your own IAP bootloader (In-Application Programming).
I hope that helps.
I faced this same issue with the STM32 Mini F401 and dug into it for several days. Unlike the OP I was unable to find any electrical conditions which reliably got the bootloader to do the right thing. I was able to program my board maybe once every 20 tries, which was really slowing down my process.
In the end I discovered that I can go to the Windows device manager, show hidden devices, and there will be an entry in Universal Serial Bus Devices called STM32 BOOTLOADER. When the issue is happening the board is connected in dfu mode but that device is not marked active in the device manager.
To resolve the issue consistently, you can manually delete the hidden STM32 BOOTLOADER entry, uninstalling the device (no need to delete the driver, just uninstall the device). Then reboot your board in DFU mode and it should connect as expected every time. Unfortunately I need to do this process every time I want to program, but that's far better than the inconsistent/intermittent failures before.
I am working on a project which has a Raspberry Pi 3 Compute Module integrated into a hardware design where the PCB provides access to both Serial Ports on the compute module:
One serial port with TX/RX on GPIO 14/15 (pins 51/53 of module)
One serial port with CTS/RTS/TX/RX on GPIO 31/31/32/33 (pins 34/36/46/48 of the module)
As far as I understand there is one full 16650 compatible UART available in the BCM2835 called the "PL011", and one mini-UART which is normally used to communicate with the internal BlueTooth chip.
When booting Raspbian Jesse, I see the /dev/ttyAMA0 device which seems to communicate on GPIO pins 14/15, and according to what I have read this communication runs through the PL011 full UART chip. I have tried to create a /boot/config.txt file which has the following device tree overlays:
dtoverlay=uart1,txd1_pin=32,rxd1_pin=33
enable_uart=1
This does not seem to provide me with a /dev/ttyAMA1 device. This seems consistent with the description in the /boot/overlays/README file which states:
Name: Uart1
Info: Enable uart1 in place of uart0
I did find a limited driver for the mini-UART which is fixed at 115200 baud, which seems like a driver to use the mini-UART instead of the full UART.
What I'd like to do is: without redesigning the hardware, configure the "PL011" full UART to use the CTS/RTS/TX/RX port, and the mini-UART to use the TX/RX port, so that I can use both serial ports in my application.
After having been studying a USB Packet Sniffer based around the BeagleBoard xM (https://gitorious.org/beagleboard-usbsniffer/), I have been at a loss as to how the driver actually works in a certain area.
I now understand that the BeagleBoard acts as a one port USB hub for the USB host to see, so that it may view and log the packets going through it. The part i'm trying to currently understand is how exactly the BeagleBoard is able to be somewhat transparent, and able to mimic the USB Vendor/Product ID's of the device being sniffed.
There is nothing to mimic. If it behaves as a hub, it can see all the traffic going between the computer and the device under test because all the USB packets would go through the hub. Packets are received by the hub and transmitted along to the other device.