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.

AM6526: Questions regarding GPMC I/O Settings

Part Number: AM6526

From Table 6-1 in the AM65xx datasheet (Pin Attributes) we see most pins are "HI-Z" at RESET.

I am supporting an application where the GPMC address pins (GPMC0_A**) are connected to MRAM; they are not PU/PD externally.

The terminology from Table 6-1 is that "Ball Reset State" is "OFF" which = Hi-Z
Also, it looks like after RESET they default to GPIO (Hi-Z) and have to be reconfigured.

What we are really wondering here is if external noise when they are Hi-Z could be causing latch-up on these pins?

Do these pins really go to HI-Z at RESET?
Is there no requirement for external PU/PD resistors in this case?
(How about termination for unused GPIO ("OFF") pins?)

  • It typically takes a lot of energy to cause an IO to latch-up and it is unlikely enough energy would be coupled into an unterminated signal trace by radiated noise. However, noise could couple enough energy into the signal trace to change its voltage potential, and there is a chance this results in a mid-supply voltage being applied to the input buffer of attached devices. This condition potentially creates a different problem that needs to be considered. 

    Input buffers will experience shoot-through current which peaks around mid-supply. Shoot-through current flows through the input buffer from VDD to VSS when the input voltage is not at VDD or VSS. This shoot-though current can cause long-term reliability issues for the input buffer if the accumulated time spent in this mid-supply region is allowed to persist too long over the life of the device. This is not unique to AM65x. It is true for most CMOS semiconductors and the concern increases for devices implemented with advanced process nodes that use smaller geometry circuits.

    This is not an issue for any of the AM65x IO as long as the input buffer is disabled, which is the default configuration for most pins. The default state of the input buffer and output buffer is shown in the RXACTIVE / TXDISABLE column of the Pin Attributes table in the datasheet. The state of the RXACTIVE and TXDISABLE bits of the respective PADCONFIG register are shown for each pin.  The state of RXACTIVE determines if the input buffer is disabled (0) or enabled (1).  The state of TXDISABLE determines if the output buffer is forced off (1) or allowed to be driven by the selected mux mode signal function (0).

    Most of the AM65x IOs default to their GPIO signal function, so software will need to configure the appropriate bits of the respective PADCONFIG register before using any of these IOs. Many of the AM65x IOs provide an internal pull-up/pull-down option, but these internal pulls are typically weak and may not be able to hold a valid logic state if the signal trace is susceptible to noise.   

    It is very important that you do not allow any enabled input buffers of the AM65x device to float to mid-supply. There is a good chance this is also the case for attached devices, when their input buffers are always on or turned on by default. In this case you should use external pulls to hold a valid logic state on any input pins without internal pulls. The system designer needs to carefully evaluate this concern for all device inputs.


  • Hi Paul,

    I'd just like to clarify my understanding through an example (using ball M23).
    I am checking the CTRLMMR_PADCONFIG1 register setting from the TRM, and the Pin Attributes table from the datasheet.

    On reset, the default behavior of ball M23 (GPMC0_AD1) is this:
    1) The ball is configured to be GPIO0_1 (setting #7)
    2) The ball is configured to be an input (RXACTIVE / TXDISABLE column shows 1/1)
    3) The ball has no internal PU/PD enabled and is "Hi-Z"  and susceptible to floating voltages / noise
    4) Floating voltages could cause shoot-through currents, possibly harming device long-term; we recommend external PU/PD

    Is my understanding okay so far?

    If you wanted to then change the MUX setting to MUX = "0" setting, what would be the appropriate proceedure?
    Would you enable the default GPIO PU/PD first, then switch?

    What would be the "best practice" when modifying the Pad Config registers?


  • Yes, your understanding is correct.

    I misunderstood which pins were being discussed. I thought you were asking about the GPMC_A[27:0] pins. I didn't realize you were asking about the GPMC_AD[15:0] pins. The input buffers associated with the GPMC_AD[15:0] pins are enabled by default because they are used for the bootmode inputs, which are latched on the rising edge of reset. All of these inputs must be pulled to the appropriate logic state to select the desired boot mode.

    You will not need to enable internal pulls on the GPMC_AD[15:0] pins since external pulls are required on each of these pins to select the appropriate boot mode. You would simply change the mux mode value to the appropriate signal function. However, in this case you also need to clear the TXDISABLE bit which removes the over-ride on the output enable of the output buffer and allows the GPMC module to control the output enable of the output buffer.

    The TXDISABLE bit should be set before changing the mux mode value and cleared after changing the mux mode value. This sequence is required because the output buffer may glitch to an unexpected value during the mux mode change. This glitch can occur because the multiplexing logic may have race conditions that briefly connect any of the possible signal functions to the output buffer during the change. These glitches are typically only a few ns in duration, but they could cause attached devices to do something unexpected.


  • Hi Paul,

    Sorry, I think I was misunderstanding the balls/signals from the customer.
    It seems they were probably referring to the GPMC_A[27:0] pins.

    I just went through the DS and TRM and see these are all disabled by default (Rx & Tx);
    so no internal/external PU/PD is required, right?

    When dealing with the GPMC_A[27:0] balls,
    your description of making sure the output buffer is disabled before changing MUX function still holds right?

    From your first email, I understand as long as the Rx/Tx are both disabled, then floating input voltages won't affect operation, right?
    The issue is when they get enabled as inputs but have no PU/PD and could see mid-level voltages, right?

  • The answer to your first question is, it depends.

    You need to consider the effects on the entire system, not just our device. The requirement for external pulls will also depend on the attached device and how each signal is used after software has initialized the IOs. First example, the device attached to AM65x IOs may have inputs without internal pulls enabled by default. If so, external pulls will still be required to prevent these inputs from floating until software configures the IOs. In some case, an external resistor may be needed during normal operation. Second example, a bidirectional bus will not be driven when there are no active data transfers. The signals associated with this bus need to be held in a valid logic state while not driven.

    I do not recommend trying to apply any rule of thumb to the pull decision. The system designer needs to understand the operation of every signal for all possible use cases and make sure inputs are never allowed to float. An example that never requires a pull resistor is a signal that is driven by an always on push-pull output buffer.

    There may be a few use cases were the TXDISABLE sequence is not required, but the system designer needs to carefully consider the consequences of not doing it before skipping this sequence.

    Floating inputs will not be a problem for any AM65x IO that has its input buffer disabled. However, that may not be the case for the device connected to the AM65x IO.

    Correct, it may be a problem for the AM65x IO once the input buffer is enabled.