AM6526: Questions regarding GPMC I/O Settings

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.

Regards,
Paul   

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.

Regards,
Paul   

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.

Regards,
Paul