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.

WEC7 Pin Mux Configuration Explanation

Is there any detailed information on how to configure and implement the pin mux settings for the AM33x using the Adeneo-based Compact 7 BSP?  For several days I have been trying different combinations of configurations for the bsp_padcfg.h and bsp_padcfg.c without being able to flip a single output bit.  I have successfully been able to control the GPIO3_4 bit which is already configured in the BSP, but enabling a non-standard pin like GPIO1_12, or GPIO1_21 seems to be more involved than just the following (in bsp_padcfg.h):

#define ANNUN_PADS \

PAD_ENTRY(GPMC_A5, MODE(7) | AM335X_PIN_OUTPUT) /* GPIO1_21 */ \

...and in bsp_padcfg.c:

const PAD_INFO AnnunPads[] = {ANNUN_PADS END_OF_PAD_ARRAY};

.

.

.

const EVM_PIN_MUX GP_BOARD_PIN_MUX[] = {

{ CTPPads, AM_DEVICE_CTP, PROFILE_0 | PROFILE_1 | PROFILE_2 | PROFILE_7, DEV_ON_DGHTR_BRD},

{ ADCTSCPads, AM_DEVICE_ADC_TSC, PROFILE_0 | PROFILE_1 | PROFILE_2 | PROFILE_7, DEV_ON_DGHTR_BRD},

{ BKLPads, AM_DEVICE_BKL, PROFILE_0 | PROFILE_1 | PROFILE_2 | PROFILE_7, DEV_ON_DGHTR_BRD},

//{ I2C0Pads, AM_DEVICE_I2C0, PROFILE_ALL, DEV_ON_BASEBOARD},

{ I2C1Pads, AM_DEVICE_I2C1, PROFILE_ALL, DEV_ON_BASEBOARD},

{ LCDCPads, AM_DEVICE_LCDC, PROFILE_0 | PROFILE_1 | PROFILE_2 | PROFILE_7, DEV_ON_DGHTR_BRD}, //although its separate LCD board, use BaseBoard as location; will use profile info to know if LCD is valid or not

{ MCASP0Pads, AM_DEVICE_MCASP0, PROFILE_ALL, DEV_ON_BASEBOARD},

//{ MCASP1Pads, AM_DEVICE_MCASP1, PROFILE_0 | PROFILE_3, DEV_ON_DGHTR_BRD},

{ MMC0Pads, AM_DEVICE_MMCHS0, PROFILE_ALL & ~PROFILE_5, DEV_ON_BASEBOARD},

//{ MMC0_NoCD_Pads, AM_DEVICE_MMCHS0, PROFILE_5, DEV_ON_BASEBOARD},

{ MMC1Pads, AM_DEVICE_MMCHS1, PROFILE_2, DEV_ON_DGHTR_BRD},

{ MMC2Pads, AM_DEVICE_MMCHS2, PROFILE_4, DEV_ON_DGHTR_BRD},

{ NANDPads, AM_DEVICE_NAND, PROFILE_ALL & ~PROFILE_2 & ~PROFILE_3, DEV_ON_DGHTR_BRD},

{ NORPads, AM_DEVICE_NOR, PROFILE_3, DEV_ON_DGHTR_BRD},

//{ RGMIIMultiplePhyPads, AM_DEVICE_CPGMAC0, PROFILE_1 | PROFILE_2 | PROFILE_4 | PROFILE_6, DEV_ON_DGHTR_BRD},

//{ RGMIISinglePhyPads, AM_DEVICE_CPGMAC0, PROFILE_0 | PROFILE_3 | PROFILE_5 | PROFILE_7, DEV_ON_BASEBOARD},

{ VARPHYSPads, AM_DEVICE_CPGMAC0, PROFILE_ALL, DEV_ON_BASEBOARD},

{ SPI0Pads, AM_DEVICE_MCSPI0, PROFILE_2, DEV_ON_DGHTR_BRD},

{ SPI1Pads, AM_DEVICE_MCSPI1, PROFILE_3, DEV_ON_DGHTR_BRD},

{ UART0Pads, AM_DEVICE_UART0, PROFILE_ALL, DEV_ON_BASEBOARD},

{ UART1Pads, AM_DEVICE_UART1, PROFILE_ALL, DEV_ON_BASEBOARD},

{ UART2Pads, AM_DEVICE_UART2, PROFILE_ALL, DEV_ON_BASEBOARD},

{ UART3Pads, AM_DEVICE_UART3, PROFILE_ALL, DEV_ON_BASEBOARD},

{ USB0Pads, AM_DEVICE_USB0, PROFILE_ALL, DEV_ON_BASEBOARD},

{ AnnunPads, AM_DEVICE_GPIO1, PROFILE_ALL, DEV_ON_DGHTR_BRD},

{0},

};

Under the kernel debugger, I can't see any difference in the handling of the GPIOOpen(), GPIOSetMode(), and GPIOSetBit() handling between setting GPIO3_4 (which works), and setting GPIO1_21 (which doesn't).  I feel there must be some other initialization that I am missing but have been unable to find any documentation.

 

  • Moving this to the WinCE forum.

  • I have made some progress on this.  It seems that the "Profile" setting in the mux table is daughterboard dependent and left in my BSP from the EVM BSP which used the DIP switches.  On my Variscite BSP, only Profile(1) is used.  In my confusion I had assumed (yes, I know) that the Profile (0-7) and Mux Mode (0-7) were the same.  I found documentation in the AM335x General Purpose EVM HW User Guide to set me straight.  The SPI2 function is working now but I'm still not able to configure/toggle GPIO1_21.

  • Have you tried going to the Command Prompt and using do in32 <address>

    ie

    >\do in32 44E10950 (Return)

    Running thru some of the SPI0 pads gave the following
    conf_spi0_sclk = 0x44E10950 = 0x00000020
    conf_spi0_d0 = 0x44E10954 = 0x00000020 

    If you type

    \>do ?

    you get a list of available commands 

    (note \> is the prompt and not to be typed)

    Terry

  • Hi David,

    I ran into the same problem when trying to control GPIO1_16 on Variscite SOM-AM33.
    Have you solved it?

    Regards,
    Dmitry
  • Hi Dmitri

    Have you got the peripheral clock enabled for the GPIO bank?

    From my BSP

    WINCE700\platform\common\src\soc\COMMON_TI_V1\AM33X\INC\am33x_clock.h

                AM_DEVICE_GPIO0 (for GPIO pins 0_0 to 0_31)
                AM_DEVICE_GPIO1 (for GPIO pins 1_0 to 1_31)
                AM_DEVICE_GPIO2 (for GPIO pins 2_0 to 2_31)
                AM_DEVICE_GPIO3 (for GPIO pins 3_0 to 3_31)

    If the clock is not enabled the GPIO pin won't work.

    Terry

  • Hi Terry,

    I see the bootloader enabling the GPIO1 clock:

    C:\WINCE700\platform\VAR_SOM_AM33\SRC\BOOTLOADER\EBOOT\main.c(181): EnableDeviceClocks(AM_DEVICE_GPIO1,TRUE);

    and couldn't find anything disabling it, so I presume the clock stays enabled.

    Actually the problem seem worse: I can't even disable GPIO3_ 10 that was enabled by default:

    From bsp_padcfg.h I removed line

    //PAD_ENTRY(MII1_RXCLK, MODE(7)) /* RGMII2 PHY Reset */

    that configures MII1_RXCLK pad as GPIO3_10.

    After I rebuild and download WinCE and run a test application I'm still able to control the pin.
    Is there any chance that this pad is reconfigured by something other than bootloader and OEMInit() ?

    Any idea will be greatly appreciated.
    Dmitry
  • I presume Ethernet is not used and is disabled in the Catalog for the BSP in Platform Builder?
  • No, I did not resolve the issue.  If we decide to use the board, we will redesign our daughterboard to use working GPIO pins.

  • Does it have to be disabled?

    I'm using 100/10 Ethernet which I guess is mapped to RMII1 ( RMII0 on the Variscite SOM-AM33 block diagram).

    I believe MII1_RXCLK is not used when the MAC is connected in RMII mode.
    The original BSP code uses that pin to reset RGMII2 PHY on the carrier board so I thought I could use it.
  • David,

    We are at the stage when we are trying to evaluate several AM335x SOMs for our project.
    Did you manage to reassign pins on any SOM other then Variscite?
    Can you tell if this problem is specific to Variscite's BSP ?

    Dmitry
  • I cannot verify that it is specific to Variscite or the TI BSP it is based on. We have only evaluated the one board using WEC7. I successfully reassigned GPIO pins on the InHand Fingertip 4 that uses a CE 5.0 BSP but we are migrating away from that board after 10 years.
  • Hi David,

    I managed to program GPIOs on the Variscite development kit.

    Here is what I've done:

    1. In bsp_padcfg,h defined the pads I would like to use as GPIOs:

    #define CBOARD_PADS_J7 \
    PAD_ENTRY(GPMC_A0, MODE(7)) /* GPIO1_16, pin 1 */ \
    PAD_ENTRY(GPMC_A4, MODE(7)) /* GPIO1_20, pin 9 */ \

    2. in bsp_padcfg.c added my definition to the array of the Back Light pads:

    const PAD_INFO BKLPads[] = {BKL_PADS CBOARD_PADS_J7 END_OF_PAD_ARRAY};

    and took out RGMII2_PADS that use same pads from the VARPHYSPads:

    const PAD_INFO VARPHYSPads[]= {MII1_PADS /*RGMII2_PADS */ END_OF_PAD_ARRAY};

    My GPIOS will be initialized in the \oal\oallib\init.c by calling :

    if (!RequestDevicePads(AM_DEVICE_BKL)) OALMSG(OAL_ERROR, (TEXT("Failed to request pads for Backlight\r\n")));

    3. Last but not least:

    I moved resistor assemblies R104 and R105 on the carrier board to switch from 1Gb PHY to connector J7.
    That wasn't spelled out explicitly in the custom board datasheet, but you can see it on the schematics.


    Now I can toggle GPMC_A0 and GPMC_A4 from my test application.