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.

GPIO 126 defined twice?

Other Parts Discussed in Thread: OMAP3530

I see according the the tatest TRM GPIO_126 is defined twice in the Table 7-4. Core Control Module Pad Configuration Register Fields

Once for

CONTROL_PADCONF_MMC1_DAT4[15:0]

and again for

CONTROL_PADCONF_CAM_WEN[31:16]

How can this be? Is this a misprint?

If so are there other GPIO's that are dual defined and actually go to two different pins?

 

  • gpio_126 and some other gpio lines are available on multiple pins according to the software configuration of the pin multiplexing options. Multiple pins are listed for one gpio line in "Table 2-24. General-Purpose IOs Signals Description" in the latest data manual (SPRS507F–FEBRUARY 2008–REVISED OCTOBER 2009) for gpio lines that are available on multiple pins.

  • See attached file "OMAP3530-Multi-Muxed-Report.txt".   This file lists all muxed signals (pad functions) that may be multiplexed

    to more than one ball location.  

     

    A program "PinMux Utility for Sitara and DM37x Devices" is available for help with resolving pin mux issues.  It can be downloaded here:

    http://focus.ti.com/docs/toolsw/folders/print/pinmuxtool.html

    It works with OMAP35xx, AM35xx, AM37xx and DM37xx (for DM37xx, use AM37xx when device type is requested).

    User's Guide is at:

    http://processors.wiki.ti.com/index.php/Pin_Mux_Utility_for_ARM_MPU_Processors

    NOTE:  When signals are muxed to multiple locations, user of the software needs to select one usage of the signal.

    Regards,

    Michael T

     

  • > NOTE:  When signals are muxed to multiple locations, user of the software needs to select one usage of the signal.

    Just a small comment to make the above sentence totally clear. It's the users responsibility to ensure that a signal is only muxed to a single ball at a time. For output signals it will normally work running it to several balls simultaneously (but it's not supported nor suggested :-). For input-signals you will of cause get into trouble since two balls trying to drive the same internal signal high/low simultaneously will make an undefined condition possible harming internal logic..

    Best regards - Good luck
      Søren

  • Soren:

    Yes, thanks for expanding on that.

    There is also the issue of an entire interface being duplicated in the multiplex map, such as UART2 on OMAP3530.   In this case,

    signals uart2_tx, uart2_rx, usrt2_rts and uart2_cts all appear in mux mode 0 and mux mode 1.  Cannot pick some signals from

    mux mode 0 and some from mux mode 1 and use them together.

    Regards,

    Michael T

  • > mux mode 0 and some from mux mode 1 and use them together.

    Why not? I think this is perfectly valid - Although a bit unusual though I admit, and it might not be supported by i.e. ROM-code UART booting :-), but as I know the internals I can't straight out if my mind come up with any reason why this shouldn't work (keeping the constrains in mind)? All IO-cells and balls life their own life AFAIK (as opposed to the pin-muxingof - some of the? - the DSP where pinmuxing is done in sets)...

    Can you clarify on this please?
      Søren

  • Actually I think this is exactally what BeagleBoard (Rev C) does. I believe they have the UART TX in one mux mode and the RX on another.

    DV

  • Just a short note to comfirm this :-) The main UART3 is used in mux mode 0 on both pins (TX and TX) for all Beagle revisions.

    UART2 going to the expansion connector is used in  mux mode (0 and 1) for (TX and RX) in Beagle Rev C2 and onward (Beagle-XM included)

    For Beagles prior to revision C2 UART2 is used in mux mode 1 on the expansion connector...

    Best regards
      Søren