Hi, we have an Orin Nx with Jetpack 6.2.1 on a custom carrier board. The carrier board uses a blower fan with its own tachometer which reports the rpm under the /sys/class/hwmon/hwmon2/rpm entry. We noticed that rpm has very large and often spikes (jumps from 10,000rpm to 20,000rpm) in the reported value.
The board had previously used Jetpack 5.1.2 and the rpm did such spikes and was generally changing in around the same 20 value range.
I did some tests on Jetpack 6.2.1 to confirm that nvfancontrol was not the responsible. I disabled the service and set the pwm value:
$ sudo systemctl stop nvfancontrol
$ echo 100 > /sys/class/hwmon/hwmon1/pwm1 && cat /sys/class/hwmon/hwmon1/pwm1
100
This still shows constant spikes in the read value. After checking the tachometer driver in Jetpack 6.2.1 (pwm-tegra-tachometer.c) I also tried setting the capture-window-length in the device-tree to a higher setting to see if this would allow for more stable readings:
@@ -21,6 +21,7 @@
status = "okay";
upper-threshold = <0xfffff>;
lower-threshold = <0x0>;
+ capture-window-length = <8>;
};
};
While this reduce the amplitude of the spikes (10,000rpm to 14,000rpm), they are still appearing. Increasing the window length further doesn’t seem the correct approach, as this would be a more averaged reading of the RPM. The upper-threshold/lower-threshold values were also changed but this had no visible effect on the RPM reading.
I have attached images of all the cases to illustrate the difference in behaviour.
- Is there a way to remove the instability in the RPM readings in Jetpack 6.2.1?
- What changed in the way this value is calculated that might cause instability in Jetpack 6.2.1?
hello jafeth.garcia,
since this is a customize carrier board, please probe the signaling of the FAN_TACH pin.
for instance, is rpm has very large and often spikes related to a glitch at the rising edge of FAN_TACH?
@JerryChang I understood you wanted me to check the raw RPM reading from the FAN_TACH pin. This is how I checked for this reading:
while true; do
raw=$(sudo busybox devmem 0x039c0000 32)
period=$((raw & 0x7ffff))
rpm=$(cat /sys/class/hwmon/hwmon1/rpm)
printf "%s %s %d %d\n" \
"$(date +%H:%M:%S.%3N)" "$raw" "$period" "$rpm"
sleep 0.2
done
This is following what on how the driver gets the information for the RPM calculation later. I am seeing this value directly change along side the rpm. I have attached the recovered readings and plotted th 50 first readings of these values to better see the behaviour.
- Is this what you meant for me to do?
- This is still an unstable behaviour compared to Jetpack 5.1.2. Can something be done to stabilize the reading?
jp6_monitor.txt (35.2 KB)
hello jafeth.garcia,
we’ve a known issue before, which due to incorrect pinmux/prod settings,
please double check you’ve below changes applied.
diff --git a/prod/tegra234-mb1-bct-prod-p3767-0000.dts b/prod/tegra234-mb1-bct-prod-p3767-0000.dts
--- a/prod/tegra234-mb1-bct-prod-p3767-0000.dts
+++ b/prod/tegra234-mb1-bct-prod-p3767-0000.dts
@@ -83,7 +83,9 @@
<0x0C303044 0xf0000000 0xf0000000>,
<0x0C30304C 0xf0000000 0xf0000000>,
/* AUD_MCLK */
- <0x02448034 0x01f1f000 0x01f1f000>;
+ <0x02448034 0x01f1f000 0x01f1f000>,
+ /* NV_THERM_FAN_TACH0 */
+ <0x02430050 0x00001000 0x00001000>;
};
};
also, the pinmux update to removes the internal pull-down on SOC_GPIO29/FAN_TACH0.
diff --git a/pinmux/tegra234-mb1-bct-pinmux-p3767-dp-a03.dtsi b/pinmux/tegra234-mb1-bct-pinmux-p3767-dp-a03.dtsi
--- a/pinmux/tegra234-mb1-bct-pinmux-p3767-dp-a03.dtsi
+++ b/pinmux/tegra234-mb1-bct-pinmux-p3767-dp-a03.dtsi
@@ -287,7 +287,7 @@
soc_gpio29_pq2 {
nvidia,pins = "soc_gpio29_pq2";
nvidia,function = "nv";
- nvidia,pull = <TEGRA_PIN_PULL_DOWN>;
+ nvidia,pull = <TEGRA_PIN_PULL_NONE>;
nvidia,tristate = <TEGRA_PIN_ENABLE>;
nvidia,enable-input = <TEGRA_PIN_ENABLE>;
nvidia,io-high-voltage = <TEGRA_PIN_DISABLE>;
@JerryChang I have checked the files. I can confirm these changes are present and being used on the Jetpack 6.2.1 image.
Are there any other changes I could test?
We’ve hit this exact pattern on a couple of custom boards, and in my experience those spikes are almost always an extra tach pulse sneaking in, not the fan actually changing speed. The tach driver basically measures the period between pulses, so one glitch on FAN_TACH for a 10k rpm reading makes the driver see ~20k. That matches what you’re describing too well to be coincidence.
Two things I’d check beyond the pinmux/prod changes. First, make sure the device tree tach pulses-per-revolution matches your blower fan. Most blowers are 2 pulses per rev, and if the tree assumes 4 your readings come out doubled and super twitchy. Second, scope the FAN_TACH line right at the SoM pin. On our board the tach trace ran next to the fan PWM line and we picked up ringing, a small RC low-pass on the carrier fixed it.
As a practical workaround, don’t try to read RPM raw in one pass. I ended up reading the tach register a few times and taking the median before doing the RPM math, single glitches get thrown out and the displayed value is rock solid. Not a fix for the hardware noise, but it makes the reported value usable while you chase the signal quality.
hello jafeth.garcia,
those were changes applied to developer kit.
since you’re working with a customize board. please double check your board configuration has those changes as well.
Yes, these are applied. Is there nothing else that can be updated or checked?
hello jafeth.garcia,
you may probe the hardware signaling, if there was a lot of glitch at the rising edge, please try the following..
