OMAPL138 GPIO Interrupt and INTSTAT empty

Hi Cristian,

A similar query was already answered here. Please have a look.

http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/p/338521/1182721.aspx#1182721

Regards,

Shankari

-------------------------------------------------------------------------------------------------------

Please click the Verify Answer button on this post if it answers your question.
--------------------------------------------------------------------------------------------------------

I had already read that post yesterday while looking for a solution.

In that case there was a problem with cleaning the flags, the first one was found anyway; in my case I just can't find any flags :-).

Anyway, here is a dummy version of my callback ( i check only for GP3[9] events.. ):

static void BANK_EVENT_runCallback( void* instance )
{
unsigned int interruptPending;
	interruptPending = GPIOPinIntStatus( 0x01E26000, 58 );
	if( interruptPending == GPIO_INT_PEND )
	{
		/* Clear flag */
		GPIOPinIntClear( 0x01E26000, 58);
	}
}

"interruptPending" is never GPIO_INT_PEND even if GP3[9] is the only enabled I/O.

EDIT: For convenience, here is the "expanded" code o "GPIOPinIntStatus" of Starterware:

unsigned int GPIOPinIntStatus(unsigned int baseAdd, unsigned int pinNumber)
{
    unsigned int intStatus = GPIO_INT_NOPEND;
    unsigned int regNumber = 0;
    unsigned int pinOffset = 0;

    regNumber = (pinNumber - 1)/32;
    
    pinOffset = (pinNumber - 1) % 32;

    if((*((volatile unsigned int *)(baseAdd + (0x34 + (0x28 * regNumber)))))) & (1 << pinOffset))
    {
        intStatus = GPIO_INT_PEND;
    }
        
    return intStatus;
}

Hi Cristian,

Please ensure that the configuration is done correctly for GPIO3[9]. i.e., Pinmux for GPIO3[9], enabling the GPIO in PSC, setting direction e.t.c?

Regards,

shankari

-------------------------------------------------------------------------------------------------------

Please click the Verify Answer button on this post if it answers your question.
--------------------------------------------------------------------------------------------------------

HI Shankari,

PINMUX, PSC, etc are correctly set (or at least I think!).

However I found a clue.

In my projet the GPIO interrupt is used as a diagnostic signal from and external FPGA. In order to trigger this event I used to connect the target with emulator and temporary pause the DSP: this misaligns the FPGA communication causing the GPIO trigger. I could not find an easier way.

Anyway I find out that this temporary pause of the DSP in some way clean the INTSTAT register!

I set up a test moving the GPIO3[9] to an unused one, configure it as output so that I could "auto-trigger" the event manually and set the breakpoint AFTER the INTSTAT test function.

Leaving the DSP running and manually moving, from emulator, the new GPIO makes the interrupt callback be called and INTSTAT read with a non-zero value. If you instead set the breakpoint BEFORE the INTSTAT test funcion and go through it stepping with the emulator here is the 0 value in INTSTAT.

I cannot explain this behaviour.

Hi,

Do you have any TI EVM board?

If yes, I would like to suggest to you that Please try to run our GPIO example projects through CCS then you can check those registers while debugging.

If you face the same behavior, Please revert back to us.

Note:

We have not faced this kind errors.

Note that:

• On ARM side Linux is running and most of the pins of bank3 are configured for EMIFA use.
• On DSP DSPBIOS with DSPLINK is running.
• I use the DSPBIOS API for interrupt handling.
• I use StarterWare wrapper for GPIO configurations (directions, set, enable interrupts )
• GPIO bank3 interrupt is mapped on HW_INT8 (far away from DSPLINK or other used interrupts )
• With emulator, enabling randomly some others GP3 pin I have seen INTSTAT23 with some flags set, so something seems working.

Are you running the DSP app (which comprise the starterware code as well DSP BIOS code) in linux through DSPlink?

I have a "ZOOM OMAP-L138 EVM". Could you please post me a link to the example projects you are referring to? I can try to reproduce the behaviour.

I forgot to highlight that I am working on DSP.

However DSP and ARM are communicating using DSPLINK and, in the boot sequence, the ARM core is the "master", initializing most of the peripherals and launching the DSP.

GPIO settings are instead made by both, depending on the use of each single I/O.