topic Re: FlexPWM interrupt not triggering in Zephyr while SDK example works as expected in Zephyr Project

FlexPWM interrupt not triggering in Zephyr while SDK example works as expected

wima88 — Mon, 12 Jan 2026 20:24:44 GMT

Zephyr 4.3.0

MCUExpresso SDK 2.16

Application note used for Example AN14196

Board used mcx_n9xx_evk/mcxn947/cpu0

Description:

I am trying to replicate an NXP SDK FlexPWM example in Zephyr OS. The main goal is to reproduce the SDK behavior where:

A simple PWM signal is generated using the FlexPWM peripheral.
A callback (interrupt handler) is executed after a specified number of PWM edges are counted(Via E-capture).

SDK Behavior (Working):

Using the SDK pwm.c example, the PWM signal is generated correctly.
The FlexPWM interrupt fires as expected.
The callback function executes once the configured number of edges is reached.

Zephyr Behavior (Issue):

Using Zephyr, I am able to successfully generate the PWM signal with the FlexPWM peripheral.
However, the FlexPWM interrupt is never triggered , and the callback function is never executed.
(IRQ_CONNECT(120, 0, FLEXPWM1_SUBMODULE0_IRQHandler, NULL, 0); was used to connect the interrupt line to IRQHandler )

Debugging and Investigation Done So Far:

I compared the FlexPWM register configurations between:
- The SDK example (pwm.c)
- The Zephyr application (main.c)
All relevant register values appear to match during the peripheral setup phase.
I disabled Zephyr power management to ensure the CPU is not entering a low-power state by adding following configs

CONFIG_PM=n CONFIG_PM_DEVICE=n
This change did not affect the behavior—the interrupt is still not triggered.
PWM output on the pin is correct, which suggests the peripheral clocking and basic configuration are working.

Question / Request for Help:

Are there any Zephyr-specific requirements for enabling FlexPWM interrupts (e.g., IRQ configuration, ISR registration, clock gating, or NVIC setup) that differ from the SDK?
Is there anything additional that must be done in Zephyr to ensure FlexPWM interrupts are properly routed and handled?
Are there known limitations or missing support for FlexPWM edge-count interrupts in Zephyr?

Any guidance on how to correctly enable and handle FlexPWM interrupts in Zephyr would be greatly appreciated.

Thank you.

Re: FlexPWM interrupt not triggering in Zephyr while SDK example works as expected

Alice_Yang — Tue, 13 Jan 2026 10:39:18 GMT

Hello @wima88

After building, please check the .config file to confirm that the interrupt is enabled.

Also you can send it to me, I help you check.

Thank you.

Alice

Re: FlexPWM interrupt not triggering in Zephyr while SDK example works as expected

wima88 — Wed, 14 Jan 2026 14:08:21 GMT

Hi Alice ,

I Scan the .config and could not find any red flags their. I upload the .config as well(had to rename since .config is not supported).

After further investigation into the Zephyr base setup, I noticed the following behavior difference between Zephyr and the MCUX SDK:

Even though the FlexPWM register configuration and values are identical between Zephyr and the SDK, the interrupt is never triggered by the peripheral itself in Zephyr after initialization.
In the MCUX SDK, I can observe that the SM0STS register bits CFB0 and CFB1 are being set periodically, which results in the expected interrupt behavior.
In Zephyr, these same status bits (SM0STS->CFB0 and SM0STS->CFB1) are never set, even though:
- The peripheral setup is identical
- The PWM output is correct
During the initial peripheral setup, these bits are automatically set once on both the SDK and Zephyr sides, and both environments execute the IRQ handler once during this initial setup.
However, after this initial IRQ execution, the interrupt status bits are never toggled again in Zephyr, and no further interrupts occur.
In contrast, the MCUX SDK continues to toggle these status bits periodically as expected, resulting in repeated interrupt callbacks.

This suggests that while the initial interrupt path is functional in Zephyr, the FlexPWM peripheral does not continue generating interrupt events afterward, despite identical register configuration.

Any insight into why the FlexPWM status bits (CFB0/CFB1) are not being set in Zephyr, or whether additional Zephyr-specific handling is required to enable periodic interrupt generation, would be greatly appreciated.

Re: FlexPWM interrupt not triggering in Zephyr while SDK example works as expected

Alice_Yang — Mon, 26 Jan 2026 02:11:30 GMT

Hello @wima88

Thanks for your patience. I confirmed with our internal Zephyr expert. In your project, you are using the MCUXpresso SDK driver instead of the Zephyr driver. This may cause potential conflicts.

Your application uses Flexcomm1 submodule 0, which is also enabled in the Zephyr devicetree for the FRDM‑MCXN947 board. If it is enabled, Zephyr will initialize the FlexPWM driver in the startup code before main() executes.

Therefore, if you choose to configure FlexPWM in your application as you are doing now, you should disable the FlexPWM node in the devicetree to avoid conflicts.

Thank you.

Alice

Re: FlexPWM interrupt not triggering in Zephyr while SDK example works as expected

wima88 — Fri, 30 Jan 2026 14:48:31 GMT

Thank you. I understand that their may be a conflict because Zephyr initializes the FlexPWM driver before main() executes.

However, I need to verify something: if I'm correct, Zephyr's devicetree is also handling the pin mux configuration through pinctrl. If I disable the flexpwm1 node in the devicetree to avoid the conflict, would I then need to manually set up the pin mux configuration in my application code, or will the pinctrl settings remain active even with the node disabled?

Wimansha

Re: FlexPWM interrupt not triggering in Zephyr while SDK example works as expected

Alice_Yang — Mon, 02 Feb 2026 09:53:57 GMT

Hello @wima88

”if I'm correct, Zephyr's devicetree is also handling the pin mux configuration through pinctrl. If I disable the flexpwm1 node in the devicetree to avoid the conflict, would I then need to manually set up the pin mux configuration in my application code, “

->> Yes.

Alice