labs icon indicating copy to clipboard operation
labs copied to clipboard
verified publisher icon gopro

GoPro Hero 11 - nmc device stalls some times

Open robertgalo opened this issue 2 years ago • 9 comments

Dear GoPro Labs Team,

I don't know how important this issue might be, but in my opinion it could block remote operations of GoPro Hero 11 (just tested with this ones). In case we can't fix this somehow, also due to the missing of other options, we, so our team, will be forced to climb up to a roof every second or third day and do some manual fixes - we would like not to do so so maybe you can help us ;-).

Here is the issue and what we figured out:

When disconnecting and/or power loss and or camera reboot, and the camera is connected through an USB cable to the computer (UBUNTU 20.04), the USB driver of the cam registers every time (checks made per lusb, dmesg, infconfig -a) but the ncm device (virtual network card) is not registering and thus showing up anymore. The following tests have been made to reproduce the issue:

So it should look like (dmesg | tail - [somelines]) when everything is fine:

[  1] cdc_ncm 7-1.2:1.0 usb1: unregister 'cdc_ncm' usb-xhci-hcd.12.auto-1.2, CDC NCM
[  2] usb 7-1.2: new high-speed USB device number 5 using xhci-hcd
[  3] usb 7-1.2: New USB device found, idVendor=2672, idProduct=0059, bcdDevice= 0.01
[  4] usb 7-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  5] usb 7-1.2: Product: HERO11 Black
[  6] usb 7-1.2: Manufacturer: GoPro
[  7] usb 7-1.2: SerialNumber: C3471327526[XYZ]
[  8] cdc_ncm 7-1.2:1.0: MAC-Address: AA:BB:CC:DD:EE:FF
[  9] cdc_ncm 7-1.2:1.0 usb1: register 'cdc_ncm' at usb-xhci-hcd.12.auto-1.2, CDC NCM, AA:BB:CC:DD:EE:FF
[10] cdc_ncm 7-1.2:1.0 usb1: 425 mbit/s downlink 425 mbit/s uplink
[11] cdc_ncm 7-1.2:1.0 usb1: 425 mbit/s downlink 425 mbit/s uplink
[12] IPv6: ADDRCONF(NETDEV_CHANGE): usb1: link becomes ready

Disconnecting/Rebooting the camera by just unplugging the USB cable and/or turning it on/off produces this issue with a probability of ~ 33% of all tries when a USB connection is up and running and ncm has registered a virtual NIC usb01, etc.

So it looks like, in case ncm is not available any more (dmesg | tail -[somelines]) like the following:

...
[  2] usb 7-1.2: new high-speed USB device number 5 using xhci-hcd
[  3] usb 7-1.2: New USB device found, idVendor=2672, idProduct=0059, bcdDevice= 0.01
[  4] usb 7-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  5] usb 7-1.2: Product: HERO11 Black
[  6] usb 7-1.2: Manufacturer: GoPro
[  7] usb 7-1.2: SerialNumber: C3471327526[XYZ]

Trying eg. something like http://172.2[X].1[Y][Z].51:8080/gopro/camera/control/wired_usb?p=1 or 0 can't help in this case anymore, the web server on cam is not present and the spinner keeps turning ...

The issue has been identified to be related to the firmware/software on the camera, because:

  • resetting USB, reconnecting the camera or rebooting the computer doesn't have any effect, ncm stays not available
  • turning the camera on/off doesn't have any effect, ncm stays not available
  • installing a new firmware (Labs 2.12.07 version) or normal customer version has no effect, ncm stays not available
  • formatting SD has no effect, ncm stays not available

The only thing which helps, without changing or doing anything else (as well as nothing on the computer side) is to set the camera to factory defaults (an interesting detail: when using the labs version only the video settings have been reset then (speed, lens, mode .. - on the main screen) all other things stayed untouched?).

Finally, after doing this, ncm is available and a NIC (usb01) has been registered again.

I would like to request a fix, but I'm not sure how this should look like. For sure, on the "other side" the ncm / NIC should be always available, and the webserver of the camera accessible, and the cam software should somehow take care about it ;-). But maybe, you have some ideas and could help, we would appreciate this very much, thank you.

robertgalo avatar Sep 20 '23 16:09 robertgalo

Sorry, this is way outside of my area, so I will have to file an internal ticket. I was asked if this happens with or without the camera's internal battery?

dnewman-gpsw avatar Sep 20 '23 19:09 dnewman-gpsw

Hi, thanks for replying. It happens in both cases. You can, after it happened, also take the battery out and put it in again (it doesn't matter how long it stays out) and there will be no change. The ncm/virtual nic is not available when the error occurred once before.

robertgalo avatar Sep 23 '23 15:09 robertgalo

The big problem with this issue is, that it is a real show stopper for us. Maybe someone can pm me (I'm available during Mo-Fr UTC 09:00 up to 16:00 for other means of communication as well, in case and if wished so ...)

robertgalo avatar Sep 23 '23 15:09 robertgalo

I think the question the team wants to know, does it only occur (the initial failure) when the battery is out? Or can this happen with stock firmware, with a stock battery installed?

dnewman-gpsw avatar Sep 23 '23 16:09 dnewman-gpsw

I think the question the team wants to know, does it only occur (the initial failure) when the battery is out? Or can this happen with stock firmware, with a stock battery installed?

I think, it's a little bit more weird. I tested right now several further combinations.

  • Generally It happens often when the battery is (charged) inside (when trying to connect)
  • Taking the battery out putting it right back in after a few seconds "can" help (I've two cameras attached to our system, both similar configured) but there is no guarantee:
    • in one case: (in addition to setting it to default as previously described at the first post) it could be resolved by taking the bat out, starting it - cdc_ncm registers
    • in the other case (on the other cam at the same time) it showed me very shortly cdc_ncm registered and then it de-registered the NIC immediately again after a few seconds (?! wtf, I didn't do anything but turning the cam - this I could reproduce two times now) or it didn't register it at all.
  • FINALLY It seems (after now 5 tests in a row) that the error doesn't occur, if the cam is disconnected from any power - meaning, no battery and no USB connected for ~5 seconds. So it seems, that some internal "stuff/cache" is doing strange things. Then, after 5 seconds reconnecting only the USB power and turning the cam on, cdc_ncm is here again.

Conclusion:

  • If a battery is attached, cdc_ncm diapers some-when after a few on/offs (here it doesn't matter if USB power is on or not). You must be lucky that it will register next time you power on the cam (this is random behavior).
  • If no battery is attached and you disconnect the cam totally from any power and power it up again, cdc_ncm always registers correctly (as far as I could test this now several times)

If there is an "wake up USB POWER ON" option, I could be happy again :)

robertgalo avatar Sep 23 '23 18:09 robertgalo

There is a wake on USB power option within Labs. Try !MWAKE=2 see if that helps. The camera will boot automatically when applying external power. Do this without a battery (which I think you want) required a patched Labs (HERO11 Labs 2.12.71: https://www.dropbox.com/t/A5mfO3DANNqTBrHn ) to be included with the next official Labs build.

dnewman-gpsw avatar Sep 23 '23 20:09 dnewman-gpsw

Thanx David,

so finally tested: It seems to work, if you keep the battery out and, in case of the ncm error the cam for > 5 seconds without power, that, when you power on the cam again ncm registers every time. The !WAKE=2 works as well. Now we design an own PCB for switching the USB PD power by the GPIO.

robertgalo avatar Sep 25 '23 14:09 robertgalo

We are also looking into the bug, but it is good there seems to be a workaround.

dnewman-gpsw avatar Sep 25 '23 17:09 dnewman-gpsw