Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Moto M4 Soundcard USB Disconnect Issue #4116

Closed
DrCWO opened this issue Feb 3, 2021 · 19 comments
Closed

Moto M4 Soundcard USB Disconnect Issue #4116

DrCWO opened this issue Feb 3, 2021 · 19 comments

Comments

@DrCWO
Copy link

DrCWO commented Feb 3, 2021

Describe the bug
Wenn switching Motu M4 USB Audiointerface ON I get USB connected, disconnected, reconnected, disconnected and so on for ever.
The time of disconnection is random.
Once I made it to see the device in aplay -l and even amixer -c contents. Looked good until disconnection.
USB got disconnected with USB3 and USB2 interfaces.

To reproduce

  • Powerswitch of Motu M4 Audiointerface: Off
  • Connect Motu M4 via USB to Raspberry Pi 4
  • Power on Raspberry Pi4
  • Wait until booted
  • Turn Powerswitch of Motu M4 Audiointerface to: ON

Expected behaviour

  • Motu M4 got found and connected
  • No USB disconnects

Actual behaviour

  • dmesg will show that the interface was found and then disconneted and reconnected and so on.

System

Logs
[ 25.582988] Bluetooth: HCI UART driver ver 2.3
[ 25.583000] Bluetooth: HCI UART protocol H4 registered
[ 25.583052] Bluetooth: HCI UART protocol Three-wire (H5) registered
[ 25.583251] Bluetooth: HCI UART protocol Broadcom registered
[ 25.958291] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 25.958298] Bluetooth: BNEP filters: protocol multicast
[ 25.958310] Bluetooth: BNEP socket layer initialized
[ 95.546761] usb 1-1.4: new high-speed USB device number 3 using xhci_hcd
[ 95.677485] usb 1-1.4: New USB device found, idVendor=07fd, idProduct=0008, bcdDevice= 1.02
[ 95.677504] usb 1-1.4: New USB device strings: Mfr=1, Product=3, SerialNumber=2
[ 95.677521] usb 1-1.4: Product: M4
[ 95.677536] usb 1-1.4: Manufacturer: MOTU
[ 95.677551] usb 1-1.4: SerialNumber: M40000067238
[ 98.297013] usbcore: registered new interface driver snd-usb-audio
[ 113.883669] usb 1-1.4: USB disconnect, device number 3
[ 114.185755] usb 1-1.4: new high-speed USB device number 4 using xhci_hcd
[ 114.316461] usb 1-1.4: New USB device found, idVendor=07fd, idProduct=0008, bcdDevice= 1.02
[ 114.316480] usb 1-1.4: New USB device strings: Mfr=1, Product=3, SerialNumber=2
[ 114.316497] usb 1-1.4: Product: M4
[ 114.316512] usb 1-1.4: Manufacturer: MOTU
[ 114.316528] usb 1-1.4: SerialNumber: M40000067238
[ 116.386086] snd-usb-audio: probe of 1-1.4:1.0 failed with error -71
[ 116.388053] snd-usb-audio: probe of 1-1.4:1.3 failed with error -71
[ 116.388553] snd-usb-audio: probe of 1-1.4:1.4 failed with error -71
[ 116.389992] usb 1-1.4: USB disconnect, device number 4
[ 116.695724] usb 1-1.4: new high-speed USB device number 5 using xhci_hcd
[ 116.826393] usb 1-1.4: New USB device found, idVendor=07fd, idProduct=0008, bcdDevice= 1.02
[ 116.826412] usb 1-1.4: New USB device strings: Mfr=1, Product=3, SerialNumber=2
[ 116.826428] usb 1-1.4: Product: M4
[ 116.826443] usb 1-1.4: Manufacturer: MOTU
[ 116.826459] usb 1-1.4: SerialNumber: M40000067238
[ 120.028561] usb 1-1.4: USB disconnect, device number 5
[ 120.325642] usb 1-1.4: new high-speed USB device number 6 using xhci_hcd
[ 120.456304] usb 1-1.4: New USB device found, idVendor=07fd, idProduct=0008, bcdDevice= 1.02
[ 120.456323] usb 1-1.4: New USB device strings: Mfr=1, Product=3, SerialNumber=2
[ 120.456340] usb 1-1.4: Product: M4
[ 120.456356] usb 1-1.4: Manufacturer: MOTU
[ 120.456371] usb 1-1.4: SerialNumber: M40000067238
[ 122.545871] snd-usb-audio: probe of 1-1.4:1.0 failed with error -71
[ 122.547832] snd-usb-audio: probe of 1-1.4:1.3 failed with error -71
[ 122.548322] snd-usb-audio: probe of 1-1.4:1.4 failed with error -71
[ 122.549708] usb 1-1.4: USB disconnect, device number 6
[ 122.845573] usb 1-1.4: new high-speed USB device number 7 using xhci_hcd
[ 122.976339] usb 1-1.4: New USB device found, idVendor=07fd, idProduct=0008, bcdDevice= 1.02
[ 122.976358] usb 1-1.4: New USB device strings: Mfr=1, Product=3, SerialNumber=2
[ 122.976375] usb 1-1.4: Product: M4
[ 122.976391] usb 1-1.4: Manufacturer: MOTU
[ 122.976406] usb 1-1.4: SerialNumber: M40000067238
[ 125.025803] snd-usb-audio: probe of 1-1.4:1.0 failed with error -71
[ 125.027740] snd-usb-audio: probe of 1-1.4:1.3 failed with error -71
[ 125.028232] snd-usb-audio: probe of 1-1.4:1.4 failed with error -71
[ 125.029159] usb 1-1.4: USB disconnect, device number 7
[ 125.325534] usb 1-1.4: new high-speed USB device number 8 using xhci_hcd
[ 125.456258] usb 1-1.4: New USB device found, idVendor=07fd, idProduct=0008, bcdDevice= 1.02
[ 125.456277] usb 1-1.4: New USB device strings: Mfr=1, Product=3, SerialNumber=2
[ 125.456293] usb 1-1.4: Product: M4
[ 125.456309] usb 1-1.4: Manufacturer: MOTU
[ 125.456324] usb 1-1.4: SerialNumber: M40000067238

Additional context
Also tried with 5.10 kernel which I got with rpi-update. Same behaviour.
I know that Motu M4 is not officially supported but it is said to be Audio Class2 and therefore should be fine.
Sounddrivers work and I could see "amixer -1 contens" once before it got disconnected.
@DrCWO
Copy link
Author

DrCWO commented Feb 4, 2021

I also downloaded the latest Boot-ROM formware from here https://github.com/raspberrypi/rpi-eeprom/releases and flashed it into my Pi4 hoping the VIA USB Code may fix it but no success.

@DrCWO
Copy link
Author

DrCWO commented Feb 4, 2021

Tested same system on RPI2B got this:
[ 103.230251] usb 1-1-port4: Cannot enable. Maybe the USB cable is bad?
[ 104.140320] usb 1-1-port4: Cannot enable. Maybe the USB cable is bad?
[ 104.140519] usb 1-1-port4: attempt power cycle
[ 105.390260] usb 1-1-port4: Cannot enable. Maybe the USB cable is bad?
[ 106.300258] usb 1-1-port4: Cannot enable. Maybe the USB cable is bad?
[ 106.300443] usb 1-1-port4: unable to enumerate USB device

@pelwell
Copy link
Contributor

pelwell commented Feb 4, 2021

How is the M4 powered?

@DrCWO
Copy link
Author

DrCWO commented Feb 4, 2021

It is powered by th Pi4. I measured the power it needs and saw 400mA which should be in the range of the Pi. Pi has 3A power supply...

@pelwell
Copy link
Contributor

pelwell commented Feb 4, 2021

The Pi 4 needs most of that 3A power supply for itself under load. Can you try attaching the M4 via a powered hub?

@DrCWO
Copy link
Author

DrCWO commented Feb 4, 2021

I ordered one yesterday and will report as soon as it is shipped.

@DrCWO
Copy link
Author

DrCWO commented Feb 5, 2021

Little update from my side:
tested with a Pi Zero W directly connected zo Motu M4: No disconnects, works like charm!

@DrCWO
Copy link
Author

DrCWO commented Feb 5, 2021

Tested with external power supply, no more disconnects!
Im my opinion something is wrong with the USB-controller in the Pi4!
Any comments?

@DrCWO
Copy link
Author

DrCWO commented Feb 5, 2021

I wonder why the USB power of a Pi Zero works and a Pi4 fails. Did this make any sense?

@P33M
Copy link
Contributor

P33M commented Feb 5, 2021

The Pi Zero has a direct connection between the power micro-USB socket and the OTG micro-USB socket. All "B" model Pis since Pi 1 B+ have a built-in current limit of 1.2A for the downstream USB ports. It's quite likely that the device disconnects are due to transient overcurrent (overcurrent events <~5ms are not flagged as a fault by the USB power switch).

Using a powered hub is the solution.

@PeterPablo
Copy link

Would adding a capacitance of appropriate size between the 5V pin and GND pin allow the Pi to cope with transient overcurrents or is the limiting factor some power conditioning circuit inside the Pi4?

@DrCWO
Copy link
Author

DrCWO commented Feb 5, 2021

P33M, what you say is quite reasonable :-) I already thought about this. PeterPablo, thank's for the tip with te capacitor, I will figure out how big it has to be.
But regarding the 5ms. My understanding of a USB current limiter is, that it should accept short overcurrents. My notebook is also limited but did not have this issue! May this be a bug in the implementation of the VIA USB firmware?
I read a lot of posts complaining about this behaviour also with other USB devices at the Pi4.
What did you think?

@P33M
Copy link
Contributor

P33M commented Feb 5, 2021 •
edited
Loading

It's not a bug. It is documented behaviour of the USB power switch that we use, specifically to prevent brownouts of the Pi itself. The recommendation is the same - use a powered USB hub with sufficient downstream current source capability for the device in question.

@DrCWO
Copy link
Author

DrCWO commented Feb 5, 2021

Soldered a wire from the USB-C Power connector directly to the power pin of the USB-2 connector with no improvement. Still disconnects. Will try capacitor tomorrow...

@DrCWO
Copy link
Author

DrCWO commented Feb 7, 2021

Let me report about the Hub I got:
Connected Hub to Pi, external Hub power suppyl on, Motu M4 on --> Anything fine
Connected Hub to Pi, NO EXTERNAL POWER SUPPLY! --> Anything fine

This means:

  • Power is NOT the problem. In the last scenario Pi4 powers Hub plus Motu M4 and it works.
  • My conclusion is that the issue lies inside the USB controller of the Pi4

Dear maintainers of the USB controller firmware of Pi4, now it't your turn, I cant do anything anymore.

Here the list of lsusb with Hup and Motu m4 connected WITHOUT Hub power supply
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 006: ID 07fd:0008 Mark of the Unicorn
Bus 001 Device 003: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

@DrCWO DrCWO mentioned this issue Feb 7, 2021
Closed
@pelwell
Copy link
Contributor

pelwell commented Feb 7, 2021

Even unpowered hubs are not passive devices - they provide a degree of electrical and protocol-level separation. Previous problems with non-compliant devices have been solved by placing a hub inline, so this may also be one of those cases.

@DrCWO
Copy link
Author

DrCWO commented Feb 7, 2021

One more and final findig.
Installed a debian today on a gigabyte brix box. No USB disconnects at all.
This means for me that Linux is NOT the problem but the USB controller firmware in Pi4....

@DrCWO
Copy link
Author

DrCWO commented Feb 7, 2021

Even unpowered hubs are not passive devices - they provide a degree of electrical and protocol-level separation. Previous problems with non-compliant devices have been solved by placing a hub inline, so this may also be one of those cases.

Phil,
I know that a Hub is a USB controller bundling multiple devices for the host.
And yes, using a Hub is a practical workaround. But I am not willing to accept that as a solution.

There is a bug in the USB controller firmware of the Pi4 and I (and probably others too) would be very happy to get this fixed.
The M4 works at a PC USB with Debian, and at a PI Zero with exactly the same SD card that I took out of the Pi4.
There is a bug and maybee also other devices may have trouble with it.

I hope you admit that it should be fixed instead recommending a workaround...

@DrCWO
Copy link
Author

DrCWO commented Feb 11, 2021

I found a solution to the issue.
Motu M4 is equipped with a USB-C connector and is shipped with a standard USB-C to USB-A cable. Not a USB-3 type!
I got a real USB3 cable with an extendes USB-A connector and a USB-C connector at the other side.
Using this cable I got no more disconnects :-)

@DrCWO DrCWO closed this as completed Feb 11, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@P33M @PeterPablo @pelwell @DrCWO