Hello all,
As mentioned in earlier post, I have developed a custom carrier for the Nano. After struggling for a long time with the wrong Nano module (A02 instead of B01), I found that my board was working OK. The ethernet, CSI, USB3.0, I2C and USB2.0 devices all enumerated and seemed to be working.
The USB2.0 interface (on the Jetson’s USB2) is used to connected a high-speed USB enabled microcontroller which acts as a CDC device. While developing the firmware for this microcontroller something odd has come up. The CDC bulk transfers time-out when using the interface. However when a WiFi USB stick is inserted in the USB 3.0 Type A connector on the carrier is inserted, the CDC bulk transfers come through as expected. When trying different USB devices (a Gigabit Ethernet dongle, USB thumb drive, wireless keyboard receiver, …) the transfers time-out. When I try to do the transfers in a loop for a number of times, the interface gives time-outs until I plug in a WiFi stick.
This perplexed me and encouraged me to review my board design, but after checking everything I could think of I believe it is a software issue. The only clue I am trying to investigate is that powertop shows a kWork process called tegra_xusb_boost_cpu_freq_fn when the USB WiFi stick is plugged in and does not show up otherwise.
Is there anyone who might have encountered this kind of issue with USB devices or knows how I could make sure the CDC bulk transfers come through properly without having to plug in a WiFi stick. Is there a way I can enable the tegra_xusb_boost_cpu_freq_fn?
Thanks in advance!
Hi,
Looks like you hit the issue on the custom board. Is it possible to run the case on default carrier board and reproduce the issue? If we can follow your steps to reproduce it, it can help us do further investigation.
For information, do you see error log in dmesg? And please share the release version( $ head -1 /etc/nv_tegra_release ).
Our carrier is also capable of using the microcontroller as a USB device (without the Jetson Nano Module), therefore I was able to try your suggestion with the same custom hardware in combination with the dev-kit carrier and the Jetson Nano Module.
The results were exactly the same, when booted up without a WiFi dongle inserted, the bulk transfers give timeouts (and powertop does not show the kworker tegra_xusb_boost_cpu_freq_fn). Once the WiFi dongle is plugged into the dev-kit carrier, the bulks transfers work as expected (and powertop shows the kworker tegra_xusb_boost_cpu_freq_fn). Is there a way to manually trigger the tegra_xusb_boost_cpu_freq_fn so I could perhaps include it in a udev rule?
To further answer your questions, when running the loop of bulk transfers and dmesg, no errors are shown. The release version is: # R32 (release), REVISION: 4.3, GCID: 21589087, BOARD: t210ref, EABI: aarch64, DATE: Fri Jun 26 04:38:25 UTC 2020
After digging through the Developer Guide, I tried the /usr/bin/jetson_clocks script to manually maximize the clock speeds. This also does the trick to allow CDC bulk transfers from the High Speed USB microcontroller to the Jetson, both on the dev-kit carrier as our custom one.
A couple of questions do arise from this finding:
- Why does the
/usr/bin/jetson_clocks script solve this issue? Is the USB throughput that much dependent on the CPU or GPU clock?
- Why does a WiFi dongle automatically trigger the boosted clocks and our High Speed USB device does not? Is that somehow related to how the driver implementation based on the USB PID?
- Why don’t the clocks automatically speed up when bulk transfers are being initiated? As above, is this a USB device driver or USB host driver issue?
Hi,
The script jetson_clocks also put the cpu governor to performance and thus the issue got resolved. The USB throughput should be fine and meets the spec.
For performance issue, we should firstly find out the bottleneck, and for this case, cpu freq should be one of the major facts.
As usb firmware is running on one of the falcon, the cpu freq is mainly related to the ability of the OS. (data preparing and analysis).
The boost cpu function would be triggered when using bulk transfer and the buffer length is less than 4KB. It is the case os using WIFI dongle.
You may check and modify the “nvidia,boost_cpu_freq” and “nvidia,boost_cpu_trigger” properties to set the minimum cpu freq and buffer length of the feature in device tree.
We do not intentionally increase the cpu feq except needs. As of now, this issue might not be the issue on device driver or host driver.