Jetson Nano USB 3.0 Bandwidth Issue

Good Morning,

I’m attempting to use a USB 3.0 HDMI video capture device on the Jetson Nano Dev Kit.
This device captures HDMI video and audio only at 1280x720_60, with MJPEG and RAW output.
On the L4T version released with the Nano, I was able to get MJPEG streaming to work by setting usbfs_memory_mb=1000 and autosuspend=1, however RAW produces usb 2-1.1: Not enough bandwidth for altsetting 1.
I just updated to the most recent L4T release, and now I am unable to get either mode to work.

I found a fix for the AGX Xavier, however it cannot be applied to the Nano. https://devtalk.nvidia.com/default/topic/1048804/jetson-agx-xavier/realsense-camera-unstable/post/5364499/#5364499

Currently the USB firmware version is tegra-xusb 70090000.xusb: Firmware timestamp: 2019-05-08 09:42:10 UTC, Version: 50.22 release.
Under /sys/kernel/debug/clk/xusb_falcon_src
clk_rate is read only at 204000000
clk_parent is pll_p_out_xusb
By setting clk_parent to pll_re_out I can get clk_rate up to 336000000, but it isn’t enough to solve the problem.

I’ve also attempted using the mainline kernel, but without hardware accelerated video handling I can’t even read the video stream.

The following is the kernel log generated from trying to access the device.

[ 600.231960] usb 2-1.1: usb_suspend_both: status 0
[ 600.279860] usb 2-1: usb_suspend_both: status 0
[ 600.280133] usb usb2: usb_suspend_both: status 0
[ 601.544598] usb 2-1.1: reset SuperSpeed USB device number 6 using tegra-xusb
[ 602.766918] usb 2-1.1: USB disconnect, device number 6
[ 602.967760] usb 2-1: usb_suspend_both: status 0
[ 602.967935] usb usb2: usb_suspend_both: status 0
[ 603.079373] usb usb2: usb_suspend_both: status -16
[ 603.292362] usb 2-1.1: new SuperSpeed USB device number 7 using tegra-xusb
[ 603.318454] usb 2-1.1: New USB device found, idVendor=1e4e, idProduct=701f
[ 603.318473] usb 2-1.1: New USB device strings: Mfr=6, Product=7, SerialNumber=3
[ 603.318487] usb 2-1.1: Product: HDMI to U3 capture
[ 603.318498] usb 2-1.1: Manufacturer: Video Grabber
[ 603.318527] usb 2-1.1: SerialNumber: 20000130041415
[ 603.320220] uvcvideo: Found UVC 1.00 device HDMI to U3 capture (1e4e:701f)
[ 603.321498] uvcvideo: UVC non compliance - GET_DEF(PROBE) not supported. Enabling workaround.
[ 603.322696] uvcvideo 2-1.1:1.0: Entity type for entity Extension 4 was not initialized!
[ 603.331621] uvcvideo 2-1.1:1.0: Entity type for entity Processing 3 was not initialized!
[ 603.339903] uvcvideo 2-1.1:1.0: Entity type for entity Camera 1 was not initialized!
[ 604.951864] tegradc tegradc.0: unblank
[ 605.042872] tegradc tegradc.0: unblank
[ 605.602156] usb 2-1.1: Not enough bandwidth for new device state.
[ 605.608307] usb 2-1.1: Not enough bandwidth for altsetting 2
[ 615.027441] FAN rising trip_level:1 cur_temp:51000 trip_temps[2]:61000
[ 620.258481] usb 2-1.1: Not enough bandwidth for new device state.
[ 620.264630] usb 2-1.1: Not enough bandwidth for altsetting 1
[ 624.831448] usb 2-1.1: Not enough bandwidth for new device state.
[ 624.837597] usb 2-1.1: Not enough bandwidth for altsetting 2
[ 642.299390] usb 2-1.1: Not enough bandwidth for new device state.
[ 642.305680] usb 2-1.1: Not enough bandwidth for altsetting 1
[ 672.148647] usb 2-1.1: Not enough bandwidth for new device state.
[ 672.154793] usb 2-1.1: Not enough bandwidth for altsetting 2
[ 682.335044] usb 2-1.1: Not enough bandwidth for new device state.
[ 682.341199] usb 2-1.1: Not enough bandwidth for altsetting 1
[ 686.615695] usb 2-1.1: Not enough bandwidth for new device state.
[ 686.621956] usb 2-1.1: Not enough bandwidth for altsetting 2

Good Evening,

I resolved the issue.
The following additions need to be made to the command line:
usbcore.usbfs_memory_mb=1024 (Increase the available memory to the usb controller, might not be necessary)
usbcore.autosuspend=-1 (Disable USB autosuspend)
usb_port_owner_info=2 (Set the USB controller in USB 3 mode, it defaults to 0, USB 1 mode, 1 is USB 2 mode)

@pgwipeout how/where did you configure those settings? after {APPEND} in /boot/extlinux/extlinux.conf or somewhere else?

I’m running into the same issue.

Thanks!

Correct, it should look like this:

APPEND ${cbootargs} console=ttyS0,115200n8 usb_port_owner_info=2 usbcore.usbfs_memory_mb=1024 usbcore.autosuspend=-1

Thanks, pgipeout. I did get this to work. I ended up moving that to a custom /etc/modprobe.d/ conf file.

Note, though - module settings was only one of my problems. It turns out my USB port resetting was also a thermal issue. I confirmed several times by adding/removing fans and monitoring temp. Once thermal_zone5 reached ~48.5C it would reset.

Hope that helps anyone else with usb resetting issues.

A full gig seems pretty high for usbcore.usbfs_memory_mb since the device only has 4. You might try a value of 128-256 instead and see if it works. From googling it seems the default is 16.

One would think that, but note, this does not mean usbcore will use the full 1G, but that it can use 1G if it needs to.
I’ve tried less than 1G, but when streaming 1080P60FPS uncompressed from a V4L2 device, I’d throttle at anything less than 1G.

Edit: This can also be dynamically controlled through sysfs if needed.

That seems really low compared to the rest of the SOC.
Note, if you have less than the required 5.1V components will run hotter as they try to compensate.
Also the stock cooler has been shown to be insufficient in certain loads, if the issue continues you might want to consider an aftermarket one.

I’ve noticed that when the SOC is drawing it’s max power, USB is one of the first functions to crash.

@pgwipeout I’m doing exactly that - streaming 1080p 60fps uncompressed frames using V4L2.

Any chance you have any ideas on why the USB might be resetting when the SOC is drawing max power? I’m finding USB instability when running in 10w mode using jetson_clocks to max out the CPU frequency.

I’m wondering if there might be workarounds? like perhaps injecting power into the USB devices?

I’ve only encountered instability when trying to run off a battery pack.
I’ve got a barrel plug running at 5.1v 5A, and it is rock solid.

Honestly I think this SOM can pull more power than the board can actually provide.

I’d say we could look at the drawings for the carrier board, since it’s using a USB hub it should already be drawing power straight from the power supply.