I'm trying to test a flutter app on iOS using my macOS virtual machine, but I can't get my old iPhone 6 to connect. I was able to get it to connect once last week, but since then it will immediately disconnect from the guest and back to the host whenever I plug it in. Here's some info about my setup:
Host OS: Ubuntu 20.04
Guest OS: macOS Big Sur 11.2
Phone: iPhone 6, iOS 12.5.1
Virtualization: VMWare player 16.1.0
I have the vm stored in a 2TB external USB drive
I added the line usb.quirks.device0 = "0x05ac:0x12a8 skip-reset, skip-refresh, skip-setconfig" to my vmx file which at least stops an infinite loop of connecting and disconnecting.
I have the vm settings to USB 2 and have all the options checked
If I plug the phone into a USB 3 port, I get a driver error, and if I plug it into a USB 2 port I sometimes get a message saying the device is busy.
I also get similar messages in the vmware log
2021-02-15T20:41:21.288-07:00| vmx| I005: USBGA: device 1000001d05ac12a8 arrived
2021-02-15T20:41:21.291-07:00| vmx| I005: MsgHint: msg.usb.disconnectHostProcess
2021-02-15T20:41:21.291-07:00| vmx| I005+ The specified device is in use by process:3922 /usr/libexec/gvfs-gphoto2-volume-monitor on the host operating system. Continuing will detach the device from the host operating system.
2021-02-15T20:41:21.291-07:00| vmx| I005+ ---------------------------------------
2021-02-15T20:41:21.297-07:00| vmx| W003: USBGL: failed to claim device (fd=19), interface 0. Retrying
2021-02-15T20:41:21.297-07:00| vmx| I005: USBGL: disconnect driver 'usbfs' from device 19, interface 0
2021-02-15T20:41:21.297-07:00| vmx| I005: USBGL: claimed device 19, interface 0 successfully
2021-02-15T20:41:21.297-07:00| vmx| I005: USBGL: Connected device 0x1000001d05ac12a8 successfully
2021-02-15T20:41:21.297-07:00| vmx| I005: USBG: Quirks for device 05ac:12a8 (user-defined,skip-setconfig,skip-reset,skip-refresh,slow-reconnect)
...
2021-02-15T20:41:21.617-07:00| vcpu-1| I005: USBGL: Disable port is not supported.
2021-02-15T20:41:21.719-07:00| vcpu-0| I005: USBG: Skipping device reset for 0x1000001d05ac12a8
2021-02-15T20:41:21.874-07:00| vmx| I005: USBG: Skipping SetConfiguration(1) for 0x1000001d05ac12a8
2021-02-15T20:41:21.879-07:00| vmx| W003: USBGL: failed to set device 19 to config 5: Device or resource busy
2021-02-15T20:41:21.879-07:00| vmx| I005: USBGL: claimed device 19, interface 0 successfully
2021-02-15T20:41:26.578-07:00| vmx| W003: USBGL: failed to submit urb to device 19: Device or resource busy
...
2021-02-15T20:41:26.579-07:00| vmx| W003: USBGL: failed to submit urb to device 19: Device or resource busy
2021-02-15T20:41:53.340-07:00| vmx| I005: USB: Disconnecting device 0x1000001e05ac12a8
2021-02-15T20:41:53.340-07:00| vmx| I005: USBG: Disconnecting 1000001e05ac12a8, port:0 reservedPort:5574C8CD9D20
2021-02-15T20:41:53.340-07:00| vmx| I005: USBGA: device 1000001e05ac12a8 already disconnected from host
The iPhone shows up under USB in system information. Manually connecting or disconnecting the device in the removable devices section of vmware doesn't seem to do anything.
Is there any other setting I can change or something I can try to get the iPhone to stay connected to the guest macOS?
Thanks so much!
Had the same problem. Need disable gvfs-gphoto2-volume-monitor and usbmuxd services in host OS (Ubuntu). Detail solution found here: https://www.insanelymac.com/forum/topic/326555-vmware-cant-connect-iphone/
Is the usbmuxd daemon that you need to disable but also to mask in order to prevent it from auto start again.
When you need to attach your iPhone to the VMWare Guest you need to execute the following commands:
sudo systemctl mask usbmuxd
sudo systemctl stop usbmuxd
When you finished and need to enable again the usbmuxd daemon you need to execute the following commands:
sudo systemctl unmask usbmuxd
sudo systemctl start usbmuxd
Also you may need to kill gvfs-gphoto2-volume-monitor by executing:
sudo killall gvfs-afc-volume-monitor
Tested and working on Fedora 36 with WMWare Workstation 16.2.3 and OSX guest 12.4
in the vmx file.... change the following line
usb_xhci:7.speed = "4"
like this
usb_xhci:7.speed = "2"
but it resets.Change the line after you open vmware...before starting the virtual machine....
you can check the port that iphone connects to from log....
in my case ... usb_xhci:7
Related
I've recently updated Ubuntu to 22.04, and it seemed to work perfectly fine for about 2 weeks. Yesterday while launching Rstudio I got a message about an internal error with title "esm_cache.py crashed with apt.cache.FetchFailedException" relating to package ubuntu-advantage-tools 27.13.2-22.04.1.
Afterwards I completely lost network connection and can't restore it in any way. This is a dual boot system, and the same ethernet cable still works on Windows 11.
I am very new to Ubuntu and am not able to think of any solution short of re-installing the system from scratch. After a search for similar issues, I tried to do some diagnostics:
sudo lshw -C network
*-network UNCLAIMED
description: Ethernet controller
product: RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
vendor: Realtek Semiconductor Co., Ltd.
physical id: 0
bus info: pci#0000:04:00.0
version: 15
width: 64 bits
clock: 33MHz
capabilities: pm msi pciexpress msix bus_master cap_list
configuration: latency=0
resources: ioport:f000(size=256) memory:fc604000-fc604fff memory:fc600000-fc603fff
nmcli device
DEVICE TYPE STATE CONNECTION
lo loopback unmanaged --
Any help would be very appreciated!
On one of my raspberry pis (Raspbian OS) with a USB serial device connected, there is periodic disconnection of the serial device while still being registered as a USB device.
lsusb returns a valid Bus Device entry, but there is no corresponding /dev/serial/ entry.
The only way to fix this issue is rebooting the pi, which I'd like to avoid.
I'd love some ideas on how I can debug USB serial connections on a Raspberry Pi Linux platform, or methods to reset the serial connection without requiring a reboot.
We tried:
Tracking udevadm monitor to see USB related events. This is what is seen where we catch a serial disconnection / reconnection happening:
KERNEL[65879.184887] remove /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0/tty/ttyACM1 (tty)
KERNEL[65879.185179] remove /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0 (usb)
KERNEL[65879.185389] remove /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.1 (usb)
KERNEL[65879.185728] remove /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.2 (usb)
KERNEL[65879.186275] remove /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3 (usb)
UDEV [65879.193792] remove /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.1 (usb)
UDEV [65879.197016] remove /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0/tty/ttyACM1 (tty)
UDEV [65879.197414] remove /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.2 (usb)
UDEV [65879.203665] remove /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0 (usb)
UDEV [65879.205795] remove /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3 (usb)
==> /var/log/messages <==
Jan 20 18:36:42 rpi4161a-172-101 kernel: [65879.307684] usb 1-1.3: USB disconnect, device number 12
==> /var/log/syslog <==
Jan 20 18:36:42 rpi4161a-172-101 kernel: [65879.307684] usb 1-1.3: USB disconnect, device number 12
KERNEL[65880.121912] add /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3 (usb)
KERNEL[65880.122424] add /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0 (usb)
KERNEL[65880.125157] add /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0/tty/ttyACM0 (tty)
KERNEL[65880.125702] add /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.1 (usb)
KERNEL[65880.126324] add /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.2 (usb)
UDEV [65880.158159] add /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3 (usb)
UDEV [65880.167588] add /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0 (usb)
UDEV [65880.168004] add /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.1 (usb)
UDEV [65880.169128] add /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.2 (usb)
UDEV [65880.177534] add /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0/tty/ttyACM0 (tty)
==> /var/log/messages <==
Jan 20 18:36:43 rpi4161a-172-101 kernel: [65880.244987] usb 1-1.3: New USB device found, idVendor=****, idProduct=****, bcdDevice= 1.00
Jan 20 18:36:43 rpi4161a-172-101 kernel: [65880.245001] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jan 20 18:36:43 rpi4161a-172-101 kernel: [65880.245010] usb 1-1.3: Product: J-Link Pro OB
Jan 20 18:36:43 rpi4161a-172-101 kernel: [65880.245020] usb 1-1.3: Manufacturer: ****
Jan 20 18:36:43 rpi4161a-172-101 kernel: [65880.245028] usb 1-1.3: SerialNumber: ****
Jan 20 18:36:43 rpi4161a-172-101 kernel: [65880.248227] cdc_acm 1-1.3:1.0: ttyACM0: USB ACM device
Jan 20 18:36:43 rpi4161a-172-101 mtp-probe: checking bus 1, device 13: "/sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3"
Jan 20 18:36:43 rpi4161a-172-101 mtp-probe: bus: 1, device: 13 was not an MTP device
Checking if the raspberry pi was overheating, using vcgencmd. It returns 8000 Soft temperature limit has occurred flag sometimes, but not always.
Tried the following method to "reset" the serial connection, which had no effect
echo -n '1-1.3:1.0' | sudo tee -a unbind
echo -n '1-1.3:1.0' | sudo tee -a bind
Followed some of the solutions here: https://raspberrypi.stackexchange.com/questions/9264/how-do-i-reset-a-usb-device-using-a-script, including the solution to reset the USB bus, with no luck.
USB Serial malfunctioning may be caused by many different factors, including software, hardware or noisy environment.
The following diagram roughly describes the related components,
-------------------- ----------------
| Userspace (Apps) | | Power Supply |
-------------------- ----------------
^
|
-------------------- ------------- ----------
| Kernel (Drivers) | <-- | USB Cable | <-- | Device |
-------------------- ------------- ----------
Narrow down to the faulty part
As first step, elimination method can help us to narrow down to the faulty part, basically you replace the suspect part with another good component, and observe if it changes result. for example,
use the latest official raspbian image to eliminate userspace issue
choose a different kernel/firmware image to eliminate kernel/driver issue
change usb cable
change usb device
use a decent power supply
Troubleshooting on software issue
Assume we could narrow down the scope to software, I would use the following procedures to do further check,
Make sure the usb device is recognized by kernel, check with lsusb, dmsg, udevadm.
Have a correct name (dev path), check udev rules;
Run udevadm monitor to observe any unexpected disconnection events, make sure it works (stable connection) on a fresh OS image, and install only necessary packages step by step.
Other tips
Check if your usb device is a "smart" device? meaning the device may have its own logic to disconnect or change mode, so that affect your host side connection.
To see what happened on the USB bus it is better to use usbmon (see https://wiki.wireshark.org/CaptureSetup/USB).
I think you should carefully check usb descriptors: lsusb -v and check how much current it attempts to take (check configuration descriptor: https://learn.microsoft.com/en-us/windows-hardware/drivers/usbcon/usb-configuration-descriptors).
I think reconnects could occur due to insufficient current to you usb device especially if device supplied only from bus. If current > than usb host controller can provide, usb host-controller limits current this could lead to device reset. To check this hypothesis connect your device to Raspberry using active hub with external power supply.
I have a Segger J-Link which I am trying to use on a Macbook running MacOS Catalina 10.15.4, with openocd and GDB against an ESP32 board. The problem is that I can not seen the device:
$ ls /dev/cu.*
/dev/cu.Bluetooth-Incoming-Port /dev/cu.JimsiPhone-WirelessiAP /dev/cu.SLAB_USBtoUART /dev/cu.usbserial-0001
None of these is the J-Link. If I run lsusb I can see it:
$ lsusb
Bus 020 Device 002: ID 10c4:ea60 Cygnal Integrated Products, Inc. CP210x UART Bridge / myAVR mySmartUSB light
Bus 020 Device 003: ID 1366:0101 SEGGER J-Link ARM
I have installed the "J-Link Software and Documentation Pack" downloaded from Segger. I have checked the Mac "Security and privacy" settings and it does not report that it blocked any drivers or programs from being installed or run.
On the J-Link, the green LED is on, with a very brief flash about twice per second.
I'm sure I have a piece missing, and would appreciate some help.
UPDATE: I have been following instructions here:
OpenOCD Instructions
It all works until I get to step 6, and I follow these instructions:
Serial driver instructions
The problem is, a path for the driver never shows up, as I described above. I don't think I can run OpenOCD if I can't make it talk to my J-link.
When I run openocd-esp32, I get (full paste from openocd-esp32 output is below):
Error: No J-Link device found.
The contents of esp32-wroom-32.cfg is:
echo "WARNING: boards/esp-wroom-32.cfg is deprecated, and may be removed in a future release."
set ESP32_FLASH_VOLTAGE 3.3
source [find target/esp32.cfg]
Here is the full paste:
Jims-MacBook-Pro-486:~ jim$ openocd -f interface/jlink.cfg -f board/esp-wroom-32.cfg -c "program_esp32 build/hello-world.bin 0x10000 verify exit"
Open On-Chip Debugger v0.10.0-esp32-20200420 (2020-04-20-16:15)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
WARNING: boards/esp-wroom-32.cfg is deprecated, and may be removed in a future release.
Info : Configured 2 cores
Error: No J-Link device found.
** OpenOCD init failed **
shutdown command invoked
Assertion failed: (jtag_trst == 0), function jtag_checks, file src/jtag/core.c, line 343.
Abort trap: 6
Running JLinkExe does find the J-Link:
Jims-MacBook-Pro-486:~ jim$ JLinkExe
SEGGER J-Link Commander V6.80b (Compiled Jun 5 2020 17:42:04)
DLL version V6.80b, compiled Jun 5 2020 17:41:46
Connecting to J-Link via USB...Updating firmware: J-Link V11 compiled Apr 23 2020 16:49:23
Replacing firmware: J-Link V11 compiled Aug 14 2019 16:21:09
Waiting for new firmware to boot
New firmware booted successfully
O.K.
Firmware: J-Link V11 compiled Apr 23 2020 16:49:23
Hardware version: V11.00
S/N: 51000936
License(s): GDB
VTref=0.000V
Type "connect" to establish a target connection, '?' for help
J-Link>
After doing the above I now get a different error message when running openocd-esp32 (perhaps because of the J-Link FW upgrade?). Initially it complained that there was not an adapter speed set, so I modified interface/jlink.cfg and added:
adapter_khz 3000
I now get a different error:
Error: JTAG scan chain interrogation failed: all ones
Which I have been Googling, and which could mean a bad board or still another configuration issue. There is no SD card in the SD card socket and no other SPI devices on the board, although the ESP32-WROVER-32U has SPI flash on it.
Here is the complete output from openocd-esp32:
Jims-MacBook-Pro-486:~ jim$ openocd -f interface/jlink.cfg -f board/esp-wroom-32.cfg -c "program_esp32 build/hello-world.bin 0x10000 verify exit"
Open On-Chip Debugger v0.10.0-esp32-20200420 (2020-04-20-16:15)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
adapter speed: 3000 kHz
WARNING: boards/esp-wroom-32.cfg is deprecated, and may be removed in a future release.
Info : Configured 2 cores
Info : J-Link V11 compiled Apr 23 2020 16:49:23
Info : Hardware version: 11.00
Info : VTarget = 0.000 V
Info : clock speed 3000 kHz
Error: JTAG scan chain interrogation failed: all ones
Error: Check JTAG interface, timings, target power, etc.
Error: Trying to use configured scan chain anyway...
Error: esp32.cpu0: IR capture error; saw 0x1f not 0x01
Warn : Bypassing JTAG setup events due to errors
Info : Listening on port 3333 for gdb connections
Error: JTAG scan chain interrogation failed: all ones
Error: Check JTAG interface, timings, target power, etc.
Error: Trying to use configured scan chain anyway...
Error: esp32.cpu0: IR capture error; saw 0x1f not 0x01
Warn : Bypassing JTAG setup events due to errors
Info : cpu0: Debug controller 0 was reset.
Info : cpu0: Core 0 was reset.
Error: esp32_soc_reset: Couldn't halt target before SoC reset
embedded:startup.tcl:449: Error: ** Unable to reset target **
in procedure 'program_esp32'
in procedure 'program_esp' called at file "/Users/jim/.espressif/tools/openocd-esp32/v0.10.0-esp32-20200420/openocd-esp32/share/openocd/scripts/target/esp32.cfg", line 64
in procedure 'program_error' called at file "/Users/jim/.espressif/tools/openocd-esp32/v0.10.0-esp32-20200420/openocd-esp32/share/openocd/scripts/target/esp_common.cfg", line 75
at file "embedded:startup.tcl", line 449
Warn : Flash driver of esp32.flash does not support free_driver_priv()
Warn : Flash driver of esp32.irom does not support free_driver_priv()
Warn : Flash driver of esp32.drom does not support free_driver_priv()
Success! This circuit used the Segger 10 pin needle connector. On that connector pin 1 is VTREF and on my board it was left floating, when it should have been connected to V3.3. I connected it and:
Jims-MacBook-Pro-486:~ jim$ openocd -f interface/jlink.cfg -f board/esp32-wrover.cfg
Open On-Chip Debugger v0.10.0-esp32-20200420 (2020-04-20-16:15)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
adapter speed: 1000 kHz
WARNING: boards/esp32-wrover.cfg is deprecated, and may be removed in a future release.
If your board is ESP32-WROVER-KIT, use board/esp32-wrover-kit-1.8v.cfg instead.
Info : Configured 2 cores
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : J-Link V11 compiled Apr 23 2020 16:49:23
Info : Hardware version: 11.00
Info : VTarget = 3.290 V
Info : clock speed 1000 kHz
Info : JTAG tap: esp32.cpu0 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1)
Info : JTAG tap: esp32.cpu1 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1)
Info : esp32: Debug controller 0 was reset.
Info : esp32: Core 0 was reset.
Info : esp32: Debug controller 1 was reset.
Info : esp32: Core 1 was reset.
Info : Listening on port 3333 for gdb connections
I would suggest to validate your setup step by step - I personally do not like big bang integrations.
Verify that your the Segger software can see your JLink probe - the good thing is that lsusb can see it. JLink Commander should provide some useful information.
Launch openocd without any executable-related arguments: openocd -f interface/jlink.cfg -f board/esp-wroom-32.cfg
Verify that basic commands are working, i.e. resetting the CPU, displaying registers, reading/writing memory.
If you you are still experimenting issues, double-check your wiring - see here for more information.
I have fresh STM32 L1 discovery board, and it seems to be broken.
But I am not completely sure.
When connecting board via USB to the Linux machine, board starts
perfectly fine, and the demo works just as described by vendor.
But I am unable to actually connect to this board.
➜ lsusb -s 002:074
Bus 002 Device 074: ID 0483:3748 STMicroelectronics ST-LINK/V2
Board seems to be connected, big jumper (CN3) to switch between ST-LINK and DISCOVERY is set to DISCOVERY. But when I try to use st-link utility
I am receiving.
➜ stlink git:(master) ./st-flash --reset erase
libusb_handle_events() timeout
[!] send_recv
libusb_submit_transfer(-6)
[!] send_recv
libusb_submit_transfer(-6)
[!] send_recv
libusb_submit_transfer(-6)
[!] send_recv
libusb_submit_transfer(-6)
[!] send_recv
2015-12-25T19:24:57 INFO src/stlink-common.c: Loading device parameters....
libusb_submit_transfer(-6)
[!] send_recv
libusb_submit_transfer(-6)
[!] send_recv
libusb_submit_transfer(-6)
[!] send_recv
2015-12-25T19:24:57 WARN src/stlink-common.c: unknown chip id! 0
fish: Job 1, './st-flash --reset erase' terminated by signal SIGSEGV (Address boundary error)
Also OpenOCD is unable to talk to the board.
openocd -f board/stm32ldiscovery.cfg
Open On-Chip Debugger 0.9.0 (2015-12-25-18:43)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
adapter speed: 300 kHz
adapter_nsrst_delay: 100
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
none separate
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Info : Unable to match requested speed 300 kHz, using 240 kHz
Info : Unable to match requested speed 300 kHz, using 240 kHz
Info : clock speed 240 kHz
Error: reset device failed
in procedure 'init'
in procedure 'ocd_bouncer'
The chip on board is STM32L152RCT6. I worked with STM32F0..4 before and had never such problems, but I did not worked with L series before, so I am not sure if this is board problem or I am skipping something important here.
EDIT: Using OpenOCD i found out not expected behaviour. At first run I am receiving error:
Error: init mode failed (unable to connect to the target)
At second run:
Error: reset device failed
Then device dissapears from the system, dmesg leaves messages:
[ 1336.080239] usb 2-1.1: reset full-speed USB device number 4 using ehci-pci
[ 1336.154250] usb 2-1.1: device descriptor read/64, error -32
[ 1336.329341] usb 2-1.1: device descriptor read/64, error -32
[ 1336.503334] usb 2-1.1: reset full-speed USB device number 4 using ehci-pci
[ 1336.566330] usb 2-1.1: device descriptor read/64, error -32
[ 1336.741385] usb 2-1.1: device descriptor read/64, error -32
[ 1336.915427] usb 2-1.1: reset full-speed USB device number 4 using ehci-pci
[ 1337.317517] usb 2-1.1: device not accepting address 4, error -32
[ 1337.390532] usb 2-1.1: reset full-speed USB device number 4 using ehci-pci
[ 1337.792623] usb 2-1.1: device not accepting address 4, error -32
[ 1337.793110] usb 2-1.1: USB disconnect, device number 4
[ 1337.855642] usb 2-1.1: new full-speed USB device number 5 using ehci-pci
[ 1337.918651] usb 2-1.1: device descriptor read/64, error -32
[ 1338.093691] usb 2-1.1: device descriptor read/64, error -32
[ 1338.267730] usb 2-1.1: new full-speed USB device number 6 using ehci-pci
[ 1338.330727] usb 2-1.1: device descriptor read/64, error -32
[ 1338.505783] usb 2-1.1: device descriptor read/64, error -32
[ 1338.679823] usb 2-1.1: new full-speed USB device number 7 using ehci-pci
[ 1339.081921] usb 2-1.1: device not accepting address 7, error -32
[ 1339.154935] usb 2-1.1: new full-speed USB device number 8 using ehci-pci
[ 1339.557024] usb 2-1.1: device not accepting address 8, error -32
[ 1339.557168] usb 2-1-port1: unable to enumerate USB device
I think there might be a problem with adapter speed, but I am not sure for now.
EDIT2: I tried with Windows ST Link Utility and I am not able to connect to the board, board causing "Detection Error" or "Connection Error", software suggests changing SWD frequency or mode. I tired with literally every combination but none works.
EDIT3: If this helps somebody, board was sent back, I have got information that it is actually broken and I have got new one. New one works flawlessly as expected.
Sometimes I work with the same L1 Discovery board on GNU/Linux. Both texane/stlink and OpenOCD detect it flawlessly without any modification. You can see the outputs:
$ st-util
2016-01-08T21:55:59 INFO src/stlink-common.c: Loading device parameters....
2016-01-08T21:55:59 INFO src/stlink-common.c: Device connected is: L1 Med-density device, id 0x10186416
2016-01-08T21:55:59 INFO src/stlink-common.c: SRAM size: 0x4000 bytes (16 KiB), Flash: 0x20000 bytes (128 KiB) in pages of 256 bytes
2016-01-08T21:55:59 INFO gdbserver/gdb-server.c: Chip ID is 00000416, Core ID is 2ba01477.
2016-01-08T21:55:59 INFO gdbserver/gdb-server.c: Target voltage is 2917 mV.
2016-01-08T21:55:59 INFO gdbserver/gdb-server.c: Listening at *:4242...
$ openocd -f board/stm32ldiscovery.cfg
GNU ARM Eclipse 64-bits Open On-Chip Debugger 0.10.0-dev-00141-g09aeb96-dirty (2015-10-28-11:56)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
adapter speed: 300 kHz
adapter_nsrst_delay: 100
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
none separate
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Info : Unable to match requested speed 300 kHz, using 240 kHz
Info : Unable to match requested speed 300 kHz, using 240 kHz
Info : clock speed 240 kHz
Info : STLINK v2 JTAG v25 API v2 SWIM v0 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 2.913980
Info : stm32l1.cpu: hardware has 6 breakpoints, 4 watchpoints
Maybe your board is really broken but before recycle it I suggest you two different trials. (a) I think after your question you have another ST (as you mentioned STM32F0..4) board perhaps with ST-LINK adaptor. You can use it as an external ST-LINK (follow eg. this). (b) Try to upgrade your embedded ST-LINK firmware with the STSW-LINK005 which java version works also in GNU/Linux environment. The board performs well for me both before and after upgrade.
I am running a RaspberryPi with raspbian-wheezy:
uname -a
Linux raspberrypi 3.18.5+ #744 PREEMPT Fri Jan 30 18:19:07 GMT 2015 armv6l GNU/Linux
How i want to use a NetGear N150 Wireless USB stick as a wlan interface:
dmesg
[ 3.401856] usb 1-1.2: new high-speed USB device number 4 using dwc_otg
[ 3.523552] usb 1-1.2: New USB device found, idVendor=0846, idProduct=9043
[ 3.532493] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 3.541771] usb 1-1.2: Product: WNA1000Mv2
[ 3.547744] usb 1-1.2: Manufacturer: Realtek
[ 3.553858] usb 1-1.2: SerialNumber: 00e04c000001
The device is not automatically detected. After plugging in the stick into a windows machine, it seems as the stick uses a Realtek rtl8192cu chip. Loading the 8192cu kernel module does not seem to work, there is still no wlan0 device.
Any ideas?
Never mind, I found a solution:
The usb id is not detected by the 8192cu kernel module as a supported device. After tweaking a bit and adding the following code to the rc.local file, everything works as expected:
modprobe 8192cu
echo "0846 9043" > /sys/bus/usb/drivers/rtl8192cu/new_id
ifdown wlan0
ifup wlan0
To have this handled automatically on module insertion, put the following line in /etc/modprobe.d/netgear_n150.conf:
install 8192cu /sbin/modprobe --ignore-install 8192cu; echo "0846 9043" > /sys/bus/usb/drivers/rtl8192cu/new_id
Going the extra mile: having it load automatically is more system specific, but on Arch Linux, adding a file in /etc/modules.load.d containing the module name is sufficient.