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 interrupt: omapl137

Other Parts Discussed in Thread: OMAP-L137

I am developing the server side of a codec. It runs on the DSP side of the OMAP-L137. The app is on the ARM9 side of the OMAP-L137. In addition to the codec, I have two DSP background tasks. One of them calls SEM_pendBinary to wait for a response from another board. The SEM_postBinary is in an ISR that I expect to execute on the rising edge of GPIO9. (I've debugged all of the behavior by spoofing data from the board up until now. That is, I've allowed the SEM_pendBinary to return with a timeout, and spoofed data when that happens.)

My GT trace output (from the background task that waits for the semaphore) indicates that the pin is low before SEM_pendBinary and high after timing out. My tcf file has the following:

bios.HWI.instance("HWI_INT4").interruptSelectNumber = 65;
bios.HWI.instance("HWI_INT4").fxn = prog.extern("MSI_ctl_intr");
bios.HWI.instance("HWI_INT4").useDispatcher = 1;
bios.HWI.instance("HWI_INT4").interruptMask = "all";

The ISR MSI_ctl_intr is this:

void MSI_ctl_intr()
{
    SEM_postBinary(&SEM_MSIready);
}

The task that calls SEM_pendBinary, initializes as follows:

   CSL_GpioRegs *hGpio = (CSL_GpioRegs*)CSL_GPIO_0_REGS;
   GPIO_setDirection(9, GPIO_IN);  //(The associated line is driven as expected.)
   hGpio->BANK[GP0].SET_RIS_TRIG = GP0P9;
   hGpio->BINTEN = 1;

SEM_pendBinary still times out. I've tried adding lighting an LED in the ISR, and there is no evidence that it executes the ISR. Is there another Interrupt Enable that I'm missing (other than BINTEN)? I've looked at the vector table, and there is something in the HWI4 locations. All code is in external memory. I based the initialization on the GPIO interrupt sample code, although it seems to have been written for a different processor (soc, etc are different).

  • Okay, no reply to that. How about this. On the OMAP-L137, is there a DSP ICR, IER, GIE? If so, where? (I can't find anything like that in the INTC table.) I find an IER in the EDMA3CC registers. I also see something similar in the AINTC documentation. The megamodule documentation says "You must enable interrupts in order for the CPU to recognize them. The CPU requires individual enables via the interrupt enable register (IER) and via the global interrupt enable field in the interrupt task register (ITSR.GIE)." Where are these? Are they available to the DSP? Do I have to do something on the ARM9 side to enable them?

     

  • CPU registers.  Check out p. 371 of http://focus.ti.com/general/docs/litabsmultiplefilelist.tsp?literatureNumber=sprufe8

    You can get to them from the C compiler.

  • I am developing for the codec engine, and my build is under Linux. I do provide a .tcf file, but I usually add elements to it manually. (I do not use the DSP/BIOS configuration tool because I do not have my main/background tasks in a project in CCS.) I do not even know if it is possible to build a Codec Engine project under CCS. I do not have instructions for how to link to the CE with CCS.

    Instead, I have server and app builds under Linux and a copy of a library (codec) buildt on Windows using CCS. The server build links to the CCS-developed library. The interrupt service routine is not part of the codec library. It is part of the server build.

    The TMS320C674x DSP CPU and Instruction Set Reference Guide describes the registers (great!) but I can't find the registers in the OMAP-L137 memory map.

    Similarly, I can't find the addresses in the cslr .h files. I searched for "ICR" in .h files, but the only likely hit was chiphal.h. The one I found doesn't seem to include support for OMAP-L137 or 674x.

    Can you tell me the memory map for the CSR, ICR, IER, IFR, IRP, ISR, ISTP, ITSR, NRP, NTSR, and TSR on the OMAP? (I'll create the .h file myself.) or provide a .h file in the cslr-type format with struct and base address assignment for the OMAP?

  • Please read the wiki page I just referenced and use C64_enable to turn on the interrupts you need.  Everything you need to do with interrupts can be accomplished through the HWI and C64 modules of BIOS.

    Those registers are part of the CPU so they do not have an address.  You need to use the cregister keyword as described in the compiler guide to reference them from C.  Otherwise you would use a MVC instruction from assembly as described in the CPU and instruction set guide.  Again, I don't recommend doing this.  I recommend doing it the way I showed in the wiki page.

  • I have added the C64_enableIER(C64_EINT4) call after initialization. I still don't get to the ISR. Remember I used

    bios.HWI.instance("HWI_INT4").interruptSelectNumber = 65;

    When I read the INTMUX1 register, it had a 0x5 where I expected a 0x41 (65) for the event number for HWI 4. I had assumed that this was set based on the .tcf file. Should it have been 0x41? Is it possible that the codec engine is using this particular interrupt? (I can use another.)

  • Ooh. I tried changing the interrupt from 4 to 7, and now I get the interrupts! Hmm.