AM263P4: Routing PWM feature to non PWM GPIO pin

Hi Huey,

Yes, you can route an EPWM output to pin D15 (PR0_PRU1_GPIO19) using the OUTPUTXBAR — no ISR or bit-banging required.

Pin D15 supports XBAROUT13 in MUX MODE 5 [1], which means it can serve as a destination for the OUTPUTXBAR. The OUTPUTXBAR is specifically designed to take internal signals — including EPWM outputs — "out" of the device to a GPIO pin [2][3].

The signal path is:

Configuration Steps:

1. Configure your EPWM module to generate the 50kHz PWM waveform as normal (set period, duty cycle, etc.)

2. Configure OUTPUTXBAR instance 13 to select your desired EPWM output as its source. This is done in SysConfig by adding an OUTPUTXBAR instance and selecting the appropriate EPWM signal [2][3].

3. Set pin D15's mux mode to Mode 5 (XBAROUT13) in your pinmux configuration. The datasheet confirms this mux mode is available on this pin [1].

This creates a purely hardware path — the EPWM peripheral generates the waveform, the OUTPUTXBAR routes it, and the pin outputs it. No CPU involvement at runtime.

The TRM explicitly states: "The OUTPUTXBAR takes internal signals 'out' of the device to a GPIO" [2], and the CONTROLSS XBAR diagram confirms that PWM outputs feed into the OUTPUTXBAR which then connects to the GPIO Mux [3]. The datasheet pin table confirms XBAROUT13 is available on ball D15 at MUX MODE 5 [1].

There is some ambiguity in the available documentation about exactly which EPWM signals (e.g., EPWMxA/B outputs vs. trip-out signals) are selectable as OUTPUTXBAR sources. You should verify in SysConfig or the TRM's OUTPUTXBAR source selection registers (Section 7.5.11) that your specific EPWM output waveform is available as an OUTPUTXBAR input. If only trip-related signals are available, the PRU pass-through approach (EPWM → PWM XBAR → INPUT XBAR → ICSS GPI → PRU firmware → GPO on pin D15) is a viable alternative with ~40ns latency [4], which is negligible for a 20μs period signal.

To help refine this recommendation, it would be helpful to know:

• Which specific EPWM instance you intend to use as the PWM source
• Whether you need precise duty cycle control or just a fixed 50kHz output
• Whether you have access to SysConfig to verify the OUTPUTXBAR source options for your SDK version

Resources

1. AM263Px Datasheet - Pin Attributes Table
2. AM263Px TRM - Crossbar (XBAR) Section 7.5.11
3. AM263Px TRM - CONTROLSS XBAR Diagram (Figure 7-379)
4. AM263Px MCU+ SDK - EPWM Protection PRU Example

Best Regards,

Zackary Fleenor

Thank you for your quick response, I will start trying to implement your solution tomorrow.  

Follow up question:

In terms of selecting a PWM, can I use any pin that is configured for a non-PWM function but has an alternate PWM function?  For example we configured pin E18 (PR0_PRU1_PGPIO3) pinmux for GPIO functionality.   Can we use EPWM23_B and route it to D15/XBAROUT13?

To answer your questions:

1.  If the above answer is yes, then there's a bunch of EPWMs we can use.  We only use EPWM0-10 as actual PWMs outputs.  Please suggest a few that is guaranteed to work.

2. The output is to a fan PWM.  The duty cycle will need to be adjusted based on the requested fan speed.  Precision isn't that important, and a bit of jitter can be tolerated.

3. Yes, we will be using sysconfig to configure this. (Although it is a bit old 1.23).  

Hi Huey,

Yes, you can absolutely use EPWM23_B (or any unused EPWM instance) and route it to D15 via OUTPUTXBAR13 — the pin's physical mux configuration is irrelevant to the internal EPWM signal.

The key insight is that the OUTPUTXBAR routes the internal EPWM signal, not the physical pin output. Pin E18 being configured as GPIO doesn't prevent EPWM23's internal module from generating a waveform — the EPWM peripheral operates independently of its pin assignment [1][2]. You just need the EPWM module itself to be enabled and configured.

Recommended Approach

Since you're using EPWM0-10 for actual PWM outputs, any instance from EPWM11-31 will work. EPWM23_B is a perfectly valid choice. The signal path remains:

Configuration in SysConfig 1.23:

1. Add an EPWM instance (e.g., EPWM23) — configure it for 50kHz with adjustable duty cycle. You do not need to assign it a pin output.
2. Add OUTPUTXBAR instance 13 — select EPWM23_B as the source signal.
3. Set pin D15 mux to Mode 5 (XBAROUT13).
4. Adjust duty cycle at runtime by writing to EPWM23's compare registers — standard EPWM register updates, no ISR needed for the signal generation itself.

This gives you a purely hardware-driven fan PWM with software-adjustable duty cycle and zero CPU overhead for waveform generation.

Verify OUTPUTXBAR source availability in SysConfig 1.23: There is documented ambiguity about whether direct EPWMxA/B waveform outputs (vs. trip-zone/event signals) appear as OUTPUTXBAR source options [3]. When you open the OUTPUTXBAR configuration in SysConfig, check the source dropdown for your EPWM instance's output signal. If only trip-related signals appear, the workaround is to use an EPWM configured to output a static value and trip it to the desired state — this pattern has been confirmed working on AM263P4 [1].

SDK bug note: Release notes for MCU+ SDK versions 09.01.00 and earlier document bug MCUSDK-12247 affecting OUTPUTXBAR SysConfig code generation [4]. If your SDK 1.23 maps to this version range, you may need to manually configure OUTPUTXBAR registers via driver APIs rather than relying solely on SysConfig-generated code.

Summary

To help refine this recommendation, it would be helpful to know:

• Whether SysConfig 1.23 shows EPWMxA/B outputs in the OUTPUTXBAR source dropdown (this would confirm direct waveform routing is supported in your SDK version)
• Whether you have flexibility to update to a newer SDK if OUTPUTXBAR code generation issues arise
• Whether any EPWM instances in the 11-31 range are reserved for other system functions in your design

1. AM263P4-Q1: ECAP TRIPOUT reference/config guidance (E2E)
2. AM263P4-Q1: Loopback implementation via XBAR (E2E)
3. AM26x Academy - EPWM Peripheral Overview
4. MCU+ SDK AM263Px - EPWM Diode Emulation Example

Best Regards,

Zackary Fleenor

I had to make changes to the pin selections and use EPWM11A  and XBAROUT15(P2).

To answer your questions:

I am using SDK1.23.   I don't see EPWMxA/B outputs in the OUTPUTXBAR source drowpdown. 

Unfortunately we can not update the SDK.  We are using SDK 10.2.0.15.

Yes EPWM instances 11-31 may be reserved for other pin functionality (not particularly for PWM).  Need to look more closely what they are configured for.

I downloaded sysconfig 1.27.1+4634 and I still don't see the fix for MCUSDK-12247.   The XBAR Output dropdown does not have any EPWMxA/B outputs.

Only TRIPOUT, SOCA, SOCB, and SYNCOUT.

Can you provide a .syscfg file that configures OUTPUTXBAR to select EPWM11A as input and XBAROUT15 as output?

Regards

I don't mind writing an API to configure the XBAROUT.  Can you provide the code that would be needed to do this?  Looking at cslr_xbar_integration_data.h in SDK 26.0.0.0 and there still isn't any OUTPUT_XBAR_EPWM11_A/B defines.

I was hoping using SYSCONFIG tool 1.27 would provide the configuration code in ti_drivers_open_close.c but as I mentioned before, MCUSDK-12247 doesn't seem to have been fixed for 1.27.

Can you also elaborate on the other suggestion to use "static value and trip it to the desired state"?  Some code or pseudocode would really help explain this more.  Tripout signals come from an active TZ. TZ are sourced by GPIO (mostly).  I am not sure how tripout can generate different duty cycles?

Hi Huey,

Thank you for the detailed follow-up. Let me address each point directly.

On OUTPUTXBAR and EPWMxA/B Signals

You are correct. After reviewing the register-level documentation more carefully, the OUTPUTXBAR on AM263Px does not support direct EPWMxA/B waveform outputs as source signals. The available sources are limited to TRIPOUT, SOCA, SOCB, and SYNCOUT. I apologize for the confusion.

This means the direct EPWM waveform routing path I described is not viable on this device, and the "static value with trip" comment I made was incorrect. A TRIPOUT signal cannot encode variable duty cycle information in the way I implied.

Viable Paths Forward

Given your constraints (SDK 10.2.0.15, no SDK update, 50kHz fan PWM with adjustable duty cycle on pin D15 or similar XBAROUT pin), here are the realistic options:

Option 1: PRU Firmware (Recommended)

Since pin D15 is already a PRU pin (PR0_PRU1_GPIO19), this is the most natural solution. The PRU subsystem on AM263Px can generate a precise, jitter-free PWM signal entirely in firmware without any R5F CPU involvement at runtime.

• Configure PR0_PRU1_GPIO19 as a PRU GPO output
• Write a simple PRU firmware loop that toggles the pin high and low with cycle-accurate delays based on a duty cycle value written to shared memory by the R5F
• The R5F updates the shared memory duty cycle register whenever fan speed changes
• At 50kHz (20us period), the PRU running at 200MHz has 4000 cycles per period, giving you very fine duty cycle resolution

This requires no ISR on the R5F side. The PRU handles waveform generation independently. TI's MCU+ SDK includes PRU GPIO examples that demonstrate this pattern.

Option 2: Use a Pin That Has a Native EPWM Mux Mode

If there is any flexibility in your PCB or pin assignment, selecting a pin that natively supports an EPWM output mux mode eliminates all of this complexity. If pin D15 is fixed due to board layout, this may not be an option, but it is worth confirming with your hardware team.

Option 3: ECAP in APWM Mode Routed via OUTPUTXBAR

The ECAP peripheral has an APWM mode that generates a PWM output. The ECAP SYNCOUT or related signals may have different OUTPUTXBAR availability. However, I want to be transparent: I need to verify whether ECAP APWM output is exposed as an OUTPUTXBAR source on AM263Px before recommending this confidently. I would not want to send you down another path that hits the same wall. I will follow up on this specifically.

On Writing OUTPUTXBAR Registers Manually

Since MCUSDK-12247 is unresolved in your toolchain, and given that EPWMxA/B are not valid OUTPUTXBAR sources regardless, manual register configuration of OUTPUTXBAR for TRIPOUT/SOCA/SOCB signals is straightforward using SDL or direct register writes, but this does not help for your use case since those signals cannot carry a variable duty cycle waveform.

Recommended Next Step

Given what you have described, the PRU firmware approach on pin D15 is the most direct and reliable path. It leverages the pin you already have, requires no SDK update, no hardware changes, and gives you full duty cycle control from the R5F via shared memory.

If you can confirm whether your project already uses the PRU subsystem for other functions (which may affect available PRU resources), I can help outline the firmware structure more concretely.

Best Regards,

Zackary Fleenor