The system pinmux must be configured to connect the hardware PWM controlller(s) to the relevant pins. If the pinmux is not configured, PWM signals will not reach the pins! The JetsonGPIO library does not dynamically modify the pinmux configuration to achieve this. Read the L4T documentation for details on how to configure the pinmux.
you should have pinmux configuration to set the pin as PWM, then you’ll able to use it.
thanks
The document you’re quoting is seven months old, before jetson-io.py and the latest version of the jetson nano software was released.
The question I’m asking is did not the jetson-io.py replace the pinmux spreadsheet configuration method as it seems to be from your second link posted above? If not, what’s the purpose of jetson-io.py?
pinmux spreadsheet shows the default pin configurations; you’ll need to have customization and then flash the new configuration to the developer kit if you have different pin configurations.
Jetson-IO could overwrite the pin configuration dynamically.
thanks
The reason I’m really asking is that the pinmux configuration procedure documented in your documentation doesn’t work, so I’ve got to find another way.
You can only access pwmchip0 (@7000a000).
pwmchip4(@70110000) is not expected to be used by user.
“The Pulse Width Modulator controller is a four channel frequency divider whose pulse width varies. Each channel has a programmable frequency divider and a programmable pulse width generator”
As per the above statement, individual 4 channels of pwm@pwmchip0 can be used (based on availability) by exporting them.
i.e. echo <0/1/2/3> > /sys/class/pwm/pwmchip0/export
Please try with above and let us know what problem do you face on your configuration.
Sandipan – thank you very much for that clarification. I understand now, and I can at least manually set the parameters and activate the second PWM line.
In addition to the misconception I had here that was explained above by Sandipan, the library I referenced in the OP is broken. I’ve fixed the library and the working library is at this link:
@Josh1745 were you successful in using jetson-io.py to activate hardware PWM on pin 32, or does this still require the more cumbersome route through the Pinmux spreadsheet modification? I’ve spent hours trying to get PWM to work on the Nano, and while using jetson-io.py appears to activate the PWM, its behavior appears to be erratic at best when in operation: I was hoping to use it to control backlight dimming at 200 Hz of a connected LCD / TFT panel. The following works perfectly when run on a Raspberry Pi, but using the same on the Nano after it was configured for PWM on Pin 32 through jetson-io.py, I get very irregular flickering on the LCD panel, and no dimming at all:
cd /sys/class/pwm/pwmchip0
echo 0 > export
sleep 1
cd pwm0
echo 5000000 > period
echo 2500000 > duty_cycle
echo 1 > enable
I have also tried to go the Pinmux spreadsheet route as described in the customizing_the_jetson_nano_40-pin_expansion_header_v1.2.pdf document (and also here: How to use PWM on Jetson Nano - Latest Open Tech From Seeed), on JetPack 4.4, but this appears to always hang when flashing the Nano, after these lines in the output of flash.sh:
[ 0.7724 ] Retrieving storage infomation
[ 0.7960 ] Applet is not running on device. Continue with Bootloader
Before I keep trying to get the flashing to work, I’d like to find out if this is actually supposed to produce a different result than using jetson-io.py on JetPack 4.4 / L4T R32, revision 4.3?
What am I not getting right? Or is PWM on the Nano simply unreliable or broken?
So here’s the deal. I don’t know exactly how the dev kit is built, but I do know the gpios (including PWM) have essentially no ability to power anything.
First, you don’t need to do the pinmux spreadsheet. You can just use the jetson-io.py and that works fine. I’ve connected the pwm pins directly to a high impedance (digilent logic analyzer), and they do exactly what they’re supposed to once configured using the jetson-io.py file.
However, what you have to do is provide a buffer on the output of the GPIO that has extremely high impedance so that it doesn’t load the pin AT ALL. I chose an op amp, specifically this one – NCV2902DTBR2G – and configured it as a unity-gain amp (connected the output directly to the inverting input).
I just tested this this afternoon, and it is generating PWM and seems to sort of work. I need to put it on the logic analyzer, which I will do either later tonight or tomorrow, and see if it’s working right or if I need to add pull-ups or something else – I might also just need to adjust some values in my code as well, it’s a rather complex application with a bunch of levels of abstraction.
Another thing to look at – I’m not sure that 250000 is the right value for duty cycle. Try 50 just for good measure. I think that duty cycle is just an integer between 0 and 100. I’ll try that when I get my digilent out later and see – I know in the library I use that’s what it is anyway.
@Josh1745 great, thank you for looking into this! I’d be very interested to hear what the logic analyzer will show. Regarding the duty cycle: I’m pretty sure it is the correct value for 50% When working with the file system, the values provided are in nanoseconds. And it produces the desired result on the Raspberry Pi.
@juerg – I’ve tested this with a logic analyzer, the solution I showed earlier works and is rock solid. Basically just need a high impedance buffer on the output of the pwm line before it goes into anything else.
@Josh1745 thank you for looking into this! I will try this approach with the high impedance buffer and report back here once I get to it. It’ll be in about 2 weeks, after the holidays.