Board: Jetson Orin Nano Super Developer Kit (8GB)
JetPack: 6
L4T: R36 (Linux 5.15.148-tegra)
Jetson.GPIO: 2.1.12
Power Mode: MAXN Super
I spent a good chunk of time trying to drive a hobby servo from the 40-pin header on my Orin Nano Super and couldn’t get any of the hardware PWM chips to actually output a signal. The frustrating part is that sysfs happily accepts all the writes and reports everything as enabled, but nothing comes out on the pins.
What I tried (none of these produced output):
| Method | Pins Tested | Result |
|---|---|---|
sysfs pwmchip0 |
15, 32, 33 | Writes succeed, enable=1, no signal |
sysfs pwmchip2 |
15, 32, 33 | Same |
sysfs pwmchip3 |
15, 32, 33 | Same |
| Pinmux devmem fix + sysfs | 15, 32, 33 | Register writes succeed, still no signal |
| Jetson.GPIO software PWM | 33 | Signal present but ~200-500us jitter, not usable for servos |
Here’s what the silent failure looks like:
echo 0 > /sys/class/pwm/pwmchip0/export
echo 20000000 > /sys/class/pwm/pwmchip0/pwm0/period
echo 1500000 > /sys/class/pwm/pwmchip0/pwm0/duty_cycle
echo 1 > /sys/class/pwm/pwmchip0/pwm0/enable
cat /sys/class/pwm/pwmchip0/pwm0/enable # Returns "1" but no electrical output
I also tried Pin 15, which the JETGPIO library lists as the only hardware PWM output on the Orin Nano. Applied the pinmux fix (busybox devmem 0x2440020 w 0x5), register write went through fine, still nothing on the scope.
On the original Jetson Nano B01, Pins 32/33 are real hardware PWM outputs via sysfs. That doesn’t seem to carry over to the Orin Nano Super.
What actually worked: GPIO bit-bang on Pin 33 using Jetson.GPIO. Just toggling the pin high/low with time.sleep() for the pulse timing. Python’s sleep has about 50us of jitter on this board, which is plenty good enough for hobby servo pulse widths (1000-2000us at 50Hz). I also wrote a C version with clock_nanosleep and RT scheduling, but honestly the Python version works just as well for standard servos.
I put everything in a repo with the full debugging story, wiring, and ready-to-run scripts:
A few questions:
- Is hardware PWM intentionally not routed to the header on the Orin Nano Super carrier board, or is there a pinmux/device-tree config I’m missing?
- If it’s a carrier board limitation, any chance this could be documented somewhere? The fact that sysfs writes all succeed silently makes this really hard to figure out.
- Any plans to fix this in a future JetPack or device tree update?
There’s also some discussion on Reddit where a few other people have run into similar issues.
Happy to grab device tree dumps or pinmux register state if that would help narrow it down. Thanks!