This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TM4C1294KCPDT: MUX decodes have GPIO pin 0 (6) encodes are for APB not AHB

Guru 55913 points
Part Number: TM4C1294KCPDT


The datasheet leaves out a single word in the statement below perhaps leads to GPIO pin 0's being defined instead of the specific pin number specified in the call. The Tivaware DMUX values of (pin_map.h) are all set to GPIO pin 0 and should be the physical GPIO pin value set in REG22 of GPIOPCTL 0x524. There should be no shifting in the GPIOPCTL leading anyone to question (pin_map.h) defines below when debugging source by visual inspection methods. The MUX decode values of GPIO pins MUST be static table entries so quick inspection by visual checks can correlate a proper match to the visual port value in the call. Why anybody on earth would ever thrust shifting of GPIO pin mux values goes beyond any sound logic.

Far below is an example of GPIO decodes for PWM M0FaultN MUX configuration that visual inspection suggest GPIO pin 0 configured (6) matching datasheet 23.2, PWM module. The first thing anyone thinks is that can't be right then check out the GPIOConfigure() and scratch head wiggle a bit in their seat. Anyone who ever trusted GPIOPinConfigure() must explicitly go into CCS debug and verify ever single GPIOPCTL (pin_map.h) define actually shifted the GPIO pin number as seemingly the last step of call below preforms???? What if that last part in call screws up shifting bits of GPIO port MUX defines, then odd things start to happen don't they!

GPIOPinConfigure(uint32_t ui32PinConfig)
{
    uint32_t ui32Base, ui32Shift;

    //
    // Check the argument.
    //
    ASSERT(((ui32PinConfig >> 16) & 0xff) < 18);
    ASSERT(((ui32PinConfig >> 8) & 0xe3) == 0);

    //
    // Extract the base address index from the input value.
    //
    ui32Base = (ui32PinConfig >> 16) & 0xff;

    //
    // Get the base address of the GPIO module, selecting either the APB or the
    // AHB aperture as appropriate.
    //
    if(HWREG(SYSCTL_GPIOHBCTL) & (1 << ui32Base))
    {
        ui32Base = g_pui32GPIOBaseAddrs[(ui32Base << 1) + 1];
    }
    else
    {
        ui32Base = g_pui32GPIOBaseAddrs[ui32Base << 1];
    }

    //
    // Extract the shift from the input value.
    //
    ui32Shift = (ui32PinConfig >> 8) & 0xff;

    //
    // Write the requested pin muxing value for this GPIO pin.
    //
    HWREG(ui32Base + GPIO_O_PCTL) = ((HWREG(ui32Base + GPIO_O_PCTL) &
                                      ~(0xf << ui32Shift)) |
                                     ((ui32PinConfig & 0xf) << ui32Shift));
}

23.2 Signal Description:
The number in parentheses (6) is the encoding that must be programmed into the PMCn field in the GPIO Port Control
(GPIOPCTL) register (page 785) to assign the PWM signal to the specified GPIO port pin.

#define GPIO_PF4_M0FAULT0       0x00051006
#define GPIO_PK6_M0FAULT1       0x00091806
#define GPIO_PK7_M0FAULT2       0x00091C06

  • Thank you. I have made note of your suggestion for improving the documentation.
  • Hi Bob,

    Also seems checking the equations below via calculator for the MUX decodes of those three M0Fault AHB GPIO ports, the ui32Base GPIO port array variable is selecting the APB decodes from listings found top of (gpio.c). GPIO ports were configured for AHB bus yet the (pin_map.h) MUX codes seem to produce only APB port configuration. That explains some of the wackiness I'm seeing here. Perhaps since the SYSCTRL register TM4C129x does not have a GPIOHBCTRL (0x400FE06C) register the call always falls through to (else). The bottom calculation is likely correct for the GPIOPTCL pin number selection from MUX decode but on the wrong bus, APB.

        // Extract the base address index from the input value.
        //
        ui32Base = (ui32PinConfig >> 16) & 0xff;

    GPIO_PF4_M0FAULT0 (0x00051006) = 0xA

    ui32Base = 0xA or

        else
        {
            ui32Base = g_pui32GPIOBaseAddrs[ui32Base << 1];
        }
    

    GPIO_PORTF_BASE is selected as the ui32Base and not 0xB GPIO_PORTF_AHB_BASE

  • Let me know if my calculator math is wrong for ui32Base value. Switched to decimal >> 16 and back to Hex for the & 0xff or the value is always 0x0.
  • Adding 1 to ui32Base seems to work for selecting the GPIO PCTL base address of AHB versus APB ports top (gpio.c). Seeming an if test could check for APB in the ui32PinConfig.

        else
        {
            /* Slecect the AHB bus aperture */
            ui32Base = g_pui32GPIOBaseAddrs[(ui32Base + 1) << 1];
        }