• State TI Thinks Resolved
  • Replies 1 reply
  • Answers 1 answer
  • Subscribers 82 subscribers
  • Views 92 views
  • Users 0 members are here
Support feedback
Options
Options
Related

TMS320F28377D: F28377D: Input X-BAR TZ1 immediately trips when the source GPIO is owned by CPU2

OH SEUNG YEOB
Prodigy 10 points

Part Number: TMS320F28377D

Hi,

I'm using a TMS320F28377D dual-core device.

I want CPU2 to trigger CPU1 ePWM Trip Zone using:

★★ CPU2 GPIO95 -> Input X-BAR INPUT1 -> TZ1 (OSHT1) ★★

CPU1 configures:

GpioCtrlRegs.GPCPUD.bit.GPIO95 = 0U;

InputXbarRegs.INPUT1SELECT = 95;

GpioCtrlRegs.GPCCSEL4.bit.GPIO95 = 1;

During CPU1 boot, when executing: 

GpioCtrlRegs.GPCDIR.bit.GPIO95 = 1;

the ePWM trips immediately during boot, before CPU2 changes the GPIO state. Observations:

- Removing INPUT1SELECT eliminates the startup trip.

- OSHT2 using a CPU1-owned GPIO works correctly.

- The issue only occurs when OSHT1 uses an Input X-BAR source GPIO owned by CPU2.

- The same behavior occurs with GPIO53, so it is not GPIO95-specific.

Is using a CPU2-owned GPIO as an Input X-BAR source for TZ1 officially supported? Is there any known hardware limitation or recommended implementation for this use case? 

※ Has anyone successfully used a CPU2-owned GPIO as an Input X-BAR source for ePWM Trip Zone on F28377D? 

Thank you. 

  • 0
    TI__Mastermind 35653 points

    Hello,

    Yes, using a CPU2-owned GPIO as an Input X-BAR source for TZ1 is officially supported. The Input X-BAR has access to every GPIO pin regardless of CPU ownership 1. There is no hardware limitation or errata for this cross-CPU scenario.

    The issue is an initialization timing problem, not a silicon bug.

    Why the Trip Occurs

    TZ1–TZ3 are active-low inputs — a trip triggers when the signal transitions from high to low 2. When CPU1 transfers GPIO95 ownership to CPU2 via GPCCSEL4, CPU2's GPyDAT register defaults to 0 (low). This causes the Input X-BAR to see a low state on INPUT1, which immediately triggers the TZ1 one-shot trip 3.

    During boot, CPU2 is held in reset while CPU1 executes 4, so CPU2 cannot initialize the GPIO before CPU1's trip-zone logic sees the low state.

    Recommended Solution

    Have CPU2 pre-write its GPyDAT register to 1 before CPU1 transfers ownership:

    1. CPU1 boots and brings CPU2 out of reset (via IPCBootCPU2)
    2. CPU2 writes GpioDataRegs.GPCDAT.bit.GPIO95 = 1 (this is allowed even while CPU1 still owns the pin) 3
    3. CPU2 signals CPU1 via IPC that it's ready
    4. CPU1 then configures GPCCSEL4.GPIO95 = 1 (transfer ownership) and INPUT1SELECT = 95

    Alternative Workarounds

    • Delay Input X-BAR configuration: Don't write INPUT1SELECT = 95 until after CPU2 has initialized GPIO95 to the safe (high) state.
    • Clear the trip flag after boot: After CPU2 initializes, clear the OSHT flag with TZCLR.OST = 1 before enabling PWM outputs.
    • Enable internal pull-up: You already have GPCPUD = 0 (pull-up enabled), but this alone may not prevent the glitch if the output driver actively drives low during the ownership switch.

    The most robust approach is to sequence the initialization so that INPUT1SELECT is not configured until CPU2 has established the GPIO in its safe (high) state.

    Have you considered using IPC synchronization (e.g., IPC flags) between CPU1 and CPU2 to gate the Input X-BAR configuration until CPU2 confirms GPIO95 is initialized?

    1. C2000 X-BAR Application Report
    2. ePWM Trip Zone Application Report
    3. E2E: CPU2 GPIO state during ownership transfer
    4. C2000 Boot Sequence
    Best Regards,
    Zackary Fleenor