F29H85X-SOM-EVM: Issue in Configuring Pins as a GPIO Output pins

Hi Dimple,

Your SysConfig-generated code is structurally correct. Here are the most likely causes and fixes:

1. Known SysConfig Bug — Missing Direction Mode Generation

There is a confirmed SysConfig bug in F29H85X SDK versions prior to 1.02.01.00 where GPIO_setDirectionMode() was not properly generated in certain configurations (particularly for CPU3, but potentially affecting other scenarios) [1]. The fix that resolved identical symptoms for other users:

• Upgrade to F29H85X-SDK version 1.02.01.00 or later
• Or manually add GPIO_setDirectionMode(D2, GPIO_DIR_MODE_OUT); outside the SysConfig-generated code section as a workaround [1]

2. Verify Both Init Functions Are Called (Correct Order)

Ensure your main() calls both functions, with pin mux configured first:

void main(void)
{
    // ... device/system init ...
    PinMux_init();   // Configure pin mux FIRST
    D2_init();       // Then set direction, pad config, etc.
    
    // Now you can control the pin:
    GPIO_writePin(D2, 1);  // Set high
    GPIO_writePin(D2, 0);  // Set low
}

The pin mux must route GPIO11 to its GPIO function before direction/pad settings take effect [2][3].

3. Hardware Routing on Custom Board

Since you're using the SOM with a custom board, verify:

• GPIO11 is physically routed from the SOM connector to your custom board without conflicts
• No external pull-ups/pull-downs or other circuitry are overriding the MCU output
• GPIO11 isn't claimed by the on-board PMIC (TPS653860XX) or other SOM components [4]
• Check the SOM schematic to confirm GPIO11 isn't shared with another function via 0Ω resistors [2]

4. Confirm CPU Ownership

Your code assigns GPIO11 to CPU1 via GPIO_setControllerCore(D2, GPIO_CORE_CPU1). Make sure the code executing GPIO_writePin() is actually running on CPU1. On F29H85X, GPIO control registers (CTRL_REGS) can only be written by CPU1, while data registers can be written by the assigned core [1].

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

• Which F29H85X SDK version you are currently using
• Whether other GPIO pins work correctly with the same initialization pattern
• What specific behavior you observe (pin stuck high, stuck low, no toggle)
• Whether you've confirmed GPIO11 routing on your custom board schematic
• Which CPU core is executing this code (CPU1 or CPU3)

Resources:

1. F29H859TU-Q1: SysConfig GPIO direction bug — E2E thread
2. F29H85x LaunchPad User's Guide
3. F29H85X GPIO API Documentation
4. F29H85X SDK — TPS653860XX PMIC Example

Best Regards,

Zackary Fleenor

Fleenor said:

Which F29H85X SDK version you are currently using

f29h85x-sdk_1_02_01_00

Fleenor said:

Whether other GPIO pins work correctly with the same initialization pattern

yes

Fleenor said:

What specific behavior you observe (pin stuck high, stuck low, no toggle)

low

when no external pull up and high when external 10k pullup is connected

Fleenor said:

Whether you've confirmed GPIO11 routing on your custom board schematic

yes it is very much correct

Fleenor said:

Which CPU core is executing this code (CPU1 or CPU3)

Core 1

Hi Dimple,

Based on your responses, the diagnosis is now clear: GPIO11's output driver is not active. The pin following an external pull-up (instead of being driven by the MCU) proves the MCU is in high-impedance on that pin, despite your correct software configuration.

Since your SDK is current (1.02.01.00), other GPIOs work identically, you're on CPU1, and your custom board routing is verified—the problem is almost certainly on the SOM module itself, not your custom board or your code.

Most Likely Cause: GPIO11 Claimed by PMIC I2C on the SOM

The F29H85X LaunchPad documentation confirms that GPIO11 can be connected to the TPS65036x PMIC's I2C bus via populated resistors (R29/R32) [1]. The SOM-EVM uses the same PMIC architecture [2]. If GPIO11 is routed to the PMIC I2C (SDA or SCL) on the SOM module, the PMIC or its pull-up circuitry will override your MCU output configuration.

Additionally, the SOM is known to use 0Ω resistor routing for pin multiplexing—similar to how GPIO65/64 are routed to EtherCAT by default and require resoldering to reroute [3].

Recommended Actions

1. Check the SOM schematic (available in the F29H85X-SOM-EVM Design Files under "Design Files") [4] — specifically look for:

   • Whether GPIO11 is connected to PMIC I2C (SDA/SCL) via resistors
   • Any 0Ω resistors routing GPIO11 to another function on the SOM

2. Probe GPIO11 directly at the SOM connector pin (not on your custom board) while toggling with GPIO_writePin(11, 1) / GPIO_writePin(11, 0) — this isolates whether the SOM itself is blocking the output.

3. If GPIO11 is claimed by the PMIC on the SOM, your options are:

   • Remove/depopulate the resistor connecting GPIO11 to the PMIC (hardware mod on SOM)
   • Choose a different GPIO pin that isn't shared with SOM peripherals

4. Quick software test — add explicit toggle code to confirm the write is happening:

   while(1) {
       GPIO_writePin(D2, 1);
       DEVICE_DELAY_US(500000);
       GPIO_writePin(D2, 0);
       DEVICE_DELAY_US(500000);
   }

   If the pin still follows the pull-up instead of toggling, this confirms hardware override.

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

• Whether you've probed GPIO11 at the SOM connector pins directly
• Whether you have a GPIO_writePin() call actively toggling the pin (vs. just configuring direction)

1. F29H85X LaunchPad User's Guide - PMIC I2C GPIO Connection
2. F29H85X-SOM-EVM PMIC TPS653860XX SDK Documentation
3. F29H85X SDK - SOM 0Ω Resistor Routing (CAN SBL Example)
4. F29H85X-SOM-EVM HSEC Pinout & Design Files

Best Regards,

Zackary Fleenor