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.

Problem programming GPIO pins in xloader

Other Parts Discussed in Thread: OMAP3530

Hello again.

I am working with a OMAP 3503 processor and having trouble programming GPIO pins (94, 149 and 150) in xloader code. The pin 94 (buzzer)  should be in bank 3 and 149 and 150 in bank 5. I have initialized corresponding GPIO_SETDATAOUT and GPIO_OE (for output) registers as per document. Do I need to initialize any other registers? I would appreciate if someone could provide a brief description (from programming point of view) how to program these pins.

 

Thanks
-- Virendra

  • They are described in the chapter "24.5 General-Purpose Interface Basic Programming Model" of technical reference manual (SPRUF98I–April 2010–Revised August 2010). If you are using them as a data input or output, please refer the section "24.5.4 Data Input (Capture)/Output (Drive)". You also need to configure the corresponding pad configuration registers. Please refer the section "7.4.4 Pad Functional Multiplexing and Configuration" for the details.

  • I'm also having trouble with the same GPIOs (UART1_RTS/GPIO_149 and UART1_CTS/GPIO_150), but on the OMAP3530 (I'm using the OMAP3530 EVM board from Mistral).  I'm modifying the 'dnld_startup_omap3_evm' program (initial bootloader used to download U-boot on an empty system), which came with the 2.x Linux PSP (strangely it seems to be missing from the 3.x Linux PSP - is there a new method for handling this initial process?).  I added code to the UART 1 initialization to configure the pad mux'ing, set the pins to be outputs by hitting the OE register at offset 0x34, and set the pins to the desired state by hitting the 'set' or 'clear' registers at offset 0x94 and 0x90.  I don't have a debugger so it's hard to tell what's going wrong, but the symptom is that the Windows download utility never starts downloading the U-boot image - the log file says that it successfully downloaded the 'secondary image' (the dnld_startup_omap3_evm.bin program), but it never receives the initial msg packet back from the target, which (I guess) indicates that my mods caused it to hang (maybe some sort of exception was generated?).  I narrowed it down to the code that actually hits the GPIO data register - configuring the mux'ing and the OE works fine, but when I add the GPIO set/clear (state doesn't matter), it fails.  Is there some step in the initialization process that I'm missing?  Something that needs to be done before it's possible to use the GPIOs?   I've been reading all the relevant sections of the Reference manual, but I haven't been able to find anything yet.

    (the reason I'm messing with these GPIOs at all is really related to my custom board, which uses them to enable certain logic on the board - I'm just starting with the EVM board (which doesn't have anything connected to RTS/CTS on UART1) to get the s/w debugged).

    Here's the modified code (from src/init.c in the dndl_startup_omap3_evm program):

    void mux_setup_uart1(void)
    {
        /* Configure TX to mode 0, pull-up; RTS to mode 4 (with pull-up) */
        *(PREG_U32)(0x4800217C) = 0x0018001C;

        /* Configure RX to mode 0, no pull-up; CTS to mode 4 (with pull-up) */
        *(PREG_U32)(0x48002180) = 0x001C0000;

        /* Set GPIO 149/150 as OUTPUT (OE=0) */
        *(PREG_U32)(0x49056034) = *(PREG_U32)(0x49056034) & ~0x00600000;

        /* Set GPIO 149/150 HIGH using 'set bit' register at offset 0x94 */
        *(PREG_U32)(0x49056094) = 0x00600000;
    }

    As shown, this fails - if I comment out the last 2 (non-comment) lines, which set the GPIO DATAOUT and OUTPUT_ENABLE regs, it works (but of course, doesn't set the GPIOs the way I need!).  It seems that any write to the 0x4905xxxx address spaces causes the failure.

    Any help or pointers to relevant documentation would be much appreciated.

  • In my case, the code below for GPIO 94 works.

     

    1.  Add line below to  macro MUX_DEFAULT(). You can copy macros from u-boot code for other pins.

     

    MUX_VAL(CP(CAM_HS), (IDIS | PTD | EN | M4)) 

    /*GPIO_94 */

    2. Since most of the pins in my case are output, I use following function to turn them on (value=0) and off (value=1)

     static void * g_banks[] = {
     OMAP34XX_GPIO1_BASE,
     OMAP34XX_GPIO2_BASE,
     OMAP34XX_GPIO3_BASE,
     OMAP34XX_GPIO4_BASE,
     OMAP34XX_GPIO5_BASE
    };

    void set_gpio_output( int gpio, int value )
    {
     /* Get bank address */
     void * bank = g_banks[(gpio & 0xFFFF) >> 5];

     // Set direction to output
     *(unsigned long*)(bank + 0x34) = ~(1 << (gpio % 32));
     if( value ) *(unsigned long *)(bank + 0x94) = 1 << (gpio % 32);
     else *(unsigned long *)(bank + 0x90) = 1 << (gpio % 32);
    }

     

    Hope that helps.

  • Found the problem - in the 'early' programs, like dnld_startup_omap3_evm and probably xloader, the interface and functional clocks are not enabled to the GPIO modules.  In my case, adding the following code fixed the problem:

        sr32(CM_FCLKEN_PER, 16, 1, 1);
        sr32(CM_ICLKEN_PER, 16, 1, 1);

    (this sets just the bit for GPIO5, bit 16)

    Might be a bit different in xloader, due to different macros.

     

     

  • I had this same issue trying to toggle a GPIO during x-loader.  Just confirming that your suggested code for turning on the interface and functional clocks does work in x-loader as well.  Also, if your GPIO is in Bank1 (as it is for me), you would use CM_FCLKEN_WKUP and CMICLKEN_WKUP instead of CM_FCLKEN_PER and CM_ICLKEN_PER.  Thanks for the help!

  • Yes, the same changes worked for me in x-loader.

    Not sure about GPIO_1 usage, but a quick look at the TRM leads be to believe that CM_FLCKEN_WKUP and CM_ICLKEN_WKUP contain the right bits.