Hi,
We are using imx6dl SOM in our custom board and I wanted to know if there is a way to configure pwm pin voltage to 3.3V in device tree we are using pwm4?
Currently in our device we noticed voltage is being reduced when duty cycle is changed.
At 100% duty cycle → 3.2V
At 10% duty cycle → 1.8V
Regards,
Adnan
Hi, I’m the Toradex AI Assistant.
I might make mistakes. Our support team will step in if needed. If I answered your question, please tick the “Solution” checkbox. For follow-up questions to me, please use @ToradexAI in your post.
Did you like my answer? 
Based on the Toradex documentation for i.MX 6 based modules, the behavior you’re experiencing is expected for PWM signals. Let me explain the PWM functionality and configuration options available.
For i.MX 6/6ULL based modules, the PWM output voltage varies with duty cycle because PWM generates a digital switching signal, not a constant analog voltage(1). The voltage you measure with a multimeter represents the average voltage over time:
This is normal PWM behavior across all Toradex modules.
For i.MX 6/6ULL based modules, pin configuration involves assigning a device tree node with the property fsl,pins inside the pin controller node(1). Each pin requires five cells, with the first four often provided by pre-processor macros(1).
The pin configuration is handled by either:
The PWM interface provides several capabilities(2):
If you need a constant 3.3V output rather than a PWM signal, you have these options:
The PWM interface can be used as an easy way to emulate a DAC and generate a variable DC voltage if used with a suitable RC circuit(2).
The SoC level device trees define the base configuration and allow extending entries through the iomuxc label(1). You’ll need to modify your device tree to properly configure the pinmuxing for your specific requirements.
Best regards, Toradex AI Assistant.
Below is my pinmux configuration.
MX6QDL_PAD_SD4_DAT2__PWM4_OUT 0x0001B0B0
Hey, @adnan,
Can you please specify how you are measuring the pin voltage?
Are you measuring it via an oscilloscope and observing a reduction in the peak voltage? Or are you measuring it with a multimeter? If you are using a multimeter, that is expected behavior from PWM, since the RMS voltage drops with a lower duty cycle.
Best regards,
This was due to measuring with a multimeter as you mentioned. Currently, during boot, the PWM pin stays high (1.8V) for the first 3 seconds and then goes low. However, if the device is restarted through a software reset or reboot, the pin remains low.
We want the pin to stay low right from the start of boot, not just after the configuration is applied. Although we have already configured this PWM pin with a pull-down, it seems that the pin remains high until the pull-down configuration takes effect during initialization.
Regards,
Adnan
Hey @adnan,
So from what I understood, the issue is that the pin stays high during power up, and you wish for it to be low whenever it’s not used, right?
Firstly, can you specify which PWM pin you are using, and how you configured the pin as pull-down?
Best regards,
we are using pwm4 and below is my pwm4 pin configuration.
MX6QDL_PAD_SD4_DAT2__PWM4_OUT 0x000130B0
Hey @adnan,
The initial high state of the pin is due to the configuration sequence followed by the SoC and U-Boot, you can configure U-Boot to keep the pin in a low state while it runs, which would make it go low earlier, but the SoC itself will probably pull the pin up during the power-up sequence, before U-Boot runs.
May I ask why you need the pin to be in a low state during all the power-up sequence? Since the pin is intended to be used as a PWM, I don’t see why a few moments of it being high would be an issue.
If you do wish to configure U-Boot to pull the pin down, you’ll need to edit the device tree in the U-Boot source code (inside u-boot/arch/arm/dts) and then rebuild U-Boot. Keep in mind, however, that this will likely only lower the amount of time the pin stays high, and the SoC itself will still drive it up during the power sequence, this is not something that can be avoided via software.
Best regards,
we need the PWM default state to be low because it will be used for buzzer control. We want the buzzer to remain off initially and only enable the PWM signal when required (event-based). So if it’s toggling during boot time it gives wrong indication.
Regards,
Adnan
@adnan
If you’re using a passive buzzer (one without a built-in oscillator), which requires a sound frequency signal, an initial high state on the PWM line it will generate a short ‘pop’ sound that can be easily distinguished from a normal buzzer tone.
On the other hand, if you’re using an active (internally driven) buzzer, it should not be controlled via PWM. Instead, it should be turned on or off using any regular GPIO pin.
We are using Active buzzer(I have tried configuring this pin as gpio also but still we see this issue). Our aim is to not have this pin toggle at boot time. we want it to be stay low until it is enabled by our application after boot is completed.
Hey @adnan,
If you are using an active buzzer, this issue is unavoidable. This is something done by the SoC itself, and is not controllable via software. As I said in my previous answer, you can modify the U-Boot device tree and rebuild U-Boot so that the pin will stay low during the boot process, but that will only make the pin be driven low faster, it will still be in a high state for a short amount of time when the chip is powered.
If rebuilding U-Boot is not worth it for your project, the other alternative is to not power off your device, or do it as little as possible. Or you could use a passive buzzer instead, since you are already using PWM, it shouldn’t require much adapting from the software side.
Best regards,
Why are we seeing 1.8V instead of 3.3 during this time when the pin toggles
Hey @adnan,
I’m confused, can you clarify what is the issue you are facing? From what I understood, the 1.8V was observed when you configured a 10% duty cycle and was due to you using a multimeter.
Are you saying that, through an oscilloscope, you are now seeing the pin being driven to 1.8V at boot time? More importantly, are you facing an actual problem due to this?
Best regards,
Most other GPIOs remain floating during boot, so you can choose a different GPIO to control the buzzer and add an external pull-down resistor to ensure it won’t trigger the buzzer until that GPIO is explicitly set high.
Hi @leonardo.costa.tx
When i enable pwm after boot and if i measure using pico scope i see voltage being stable(3.3V) for different duty cycles. same thing when i capture waveform during boot using same pico scope i see a voltage of around 1.8v when pwm toggles during boot.
Regards,
Adnan
Hi @alex.tx
We’re seeing the same behavior on several GPIOs that drive a relay: on boot/power-up these pins briefly toggle for about few seconds. The affected pins and their current mux settings are:
MX6QDL_PAD_EIM_A25__GPIO5_IO02 — 0x000030B1
MX6QDL_PAD_EIM_D22__GPIO3_IO22 — 0x000130B0
MX6QDL_PAD_EIM_OE__GPIO2_IO25 — 0x000030B1
MX6QDL_PAD_EIM_RW__GPIO2_IO26 — 0x000030B1
Regards,
Adnan
Hey @adnan,
The i.MX6DL SoC’s GPIO pin voltage levels depend on OVDD, which can be in the range of 1.8V to 3.3V. The level change is something the module does during the power up process, I don’t see why it would be an issue.
Once again, you can rebuild U-Boot to mitigate the problem of the high level signal during power up, but it would probably be better to just use a passive buzzer instead of an active one.
Best regards,
