AM6548: Using PRU pins as GPIO

Hello Ben,

Can you please share your code ?

How you are configuring PADCONFIG for GPIO input purposes.

For output, you don't need to tell type as output by default PADCFG can be treated as output only, but for the input, the user needs to tell as input.

Typically, for the input, we need to configure, like as below.

Regards,

Anil.

Hi Swargam,

Thanks for replying! I actually don't use the the PDK BSP for setting the pinmux, here is the code I use to build the pad config setting:

enum MuxMode : uint8_t
{
    MODE0 = 0U,
    MODE1,
    MODE2,
    MODE3,
    MODE4,
    MODE5,
    MODE6,
    MODE7,
    MODE8,
    MODE9,
    MODE10,
    MODE11,
    MODE12,
    MODE13,
    MODE14,
    MODE15,
};

enum class PullUpDownEnable : uint8_t
{
    DISABLE = 0U,
    ENABLE,
};

enum class PullTypeSelect: uint8_t
{
    PULLDOWN = 0U,
    PULLUP,
};

enum class RecieveActive : uint8_t
{
    DISABLE = 0U,
    ENABLE,
};

const uint32_t PULLDEN_OFFSET = 16U;
const uint32_t PULLTYPESEL_OFFSET = 17U;
const uint32_t RXACTIVE_OFFSET = 18U;

static inline uint32_t buildPinSetting(
    const MuxMode muxmode,
    const PullUpDownEnable pulluden,
    const PullTypeSelect pulltypesel,
    const RecieveActive rxactive)
{
    return static_cast<uint32_t>(muxmode) |
            ((1U - static_cast<uint32_t>(pulluden)) << PULLDEN_OFFSET) |
            (static_cast<uint32_t>(pulltypesel) << PULLTYPESEL_OFFSET) |
            (static_cast<uint32_t>(rxactive) << RXACTIVE_OFFSET);
}

And then I write the pad config with this code:

const uint32_t PAD_CONFIG_MAP_OFFSET = 0x1C000U;

void commonApply(const uint32_t addr, const uint16_t pinOffset, const uint32_t settings)
{
    // Write settings
    HW_WR_REG32_RAW(addr + PAD_CONFIG_MAP_OFFSET + pinOffset, settings);
}

This has the effect of writing the corresponding PADCONFIG register for a pin offset defined from ti/board/src/am65xx_idk/AM65xx_pinmux.h. 

The only values I set are circled in the image below:

For GPIO input, I configure RXACTIVE to high, and PULLUDEN to disabled. For output I configure RXACTIVE to low, and also disable PULLUDEN, since our design relies on external pullups / pulldowns.

Is there a configuration I am missing?

Thanks,
Ben

Benjamin Roytburd said:

For GPIO input, I configure RXACTIVE to high, and PULLUDEN to disabled. For output I configure RXACTIVE to low, and also disable PULLUDEN, since our design relies on external pullups / pulldowns.

Is there a configuration I am missing?

Hello Ben,

With the above settings and configuring the Mux mode should work.

If this is not working, then we need to check on our side.

Regards,

Anil.

If you could that would be helpful, we are not exactly sure why the pullups appear to be enabled still

Interestingly, debugging the board a bit, our power supply for some of the input pins seems off. The GPIO pins that are giving us wrong readings are floating around 1.3-1.5V, triggering high / low in the firmware randomly. 

These pins are powered from VDDSHV3 and VDDSHV4, which get their power from CAP_VDDA_1P8_IOLDO1, which for some reason is sitting at around 2.9V, instead of 1.8V. According to the AM6548 datasheet this signal should be 1.8V, and CAP_VDDA_1P8_IOLDO0 is at 1.8V, so gpio pins that are powered off that voltage seem fine. 

Why would CAP_VDDA_1P8_IOLDO1 be sitting at 2.9V? Is there some sort of internal bypass / configuration to fix this? We are pretty sure this is what is causing our GPIO issues

What is even more strange is that CAP_VDDA_1P8_IOLDO0 is at 1.8V, and CAP_VDDA_1P8_IOLDO_WKUP is at 2.9V. We are attempting to use 3v3 logic for the corresponding VDDSHVx banks. 

On the IDKEVM, all these signals are sitting around 1.26V. Are they configurable in software somehow? Or through some resistor selection?

We are not sure what would cause this discrepancy. 

A coworker of mine found this thread: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1025865/am6548-boot-mode-pins-state-during-device-reset

Which seemed to mirror our issue almost exactly. Specifically this comment:

"""

Btw, I've already provided scope snapshots of CAP_VDDA_1P8_IOLDO0 (on August the 19th) for two slew rate values of 3V3 power supply rail (fast and slow ramp). With a slow ramp on 3V3 we've observed the excursion above 1V8 - to around 2.8V for a period of around 7ms.

"""

Except in our case CAP_VDDA_1P8_IOLDO0/1/0_WKUP was being help at 2.8V continuously. 

What we found that fixed it was reducing the slew rate for our 3.3V logic supply from 7-8ms to <1ms, that made  CAP_VDDA_1P8_IOLDO0/1/0_WKUP stay at a steady 1.8V. All of our GPIO input pins now are at a more reasonable logic level. 

According to the TI engineers in the linked thread, this was reproduced on the EVM as well. 

Our question is, why is this issue not documented anywhere? There is no mention of slew rate or behavior of these CAP_* signals anywhere besides in the linked thread. Especially if this issue is able to be reproduced on an EVM.