Still trying to figure it out. I'm writing an application that uses the USB controller (device mode) on DM365 (without any OS). Trying to get interrupts going. Could someone please help with the following questions (unfortunately in case of DM365 the documentation doesn't live up to TI standards that I was used to).
1. On the USB controller level: what is the supposed use of the INTVECTR register? The only thing mentioned in the document (sprufh9a, p.94) is "Recycles the Interrupt Vector input to be read by the CPU". Could someone please explain what's that supposed to mean? An example might help a lot.
2. On the ARM interrupt controller (AINTC) level: what exactly needs to be done so that device interrupts (in my case the USB controller's ) cause ARM interrupts to occur? I can see the correct bit reset to 0 in the IRQ0 status register of the AINTC, but the code is not interrupted. Some (but not necessarily all) issues requiring clarification:
2a) What setting of CPSR register is required to get interrupts going AND still be able to use the emulator? This register is manipulated in the .gel file, but the description (sprufg5a, p.19) is inadequate to figure out which setting to use in which circumstances. I've seen some vague references to this register on the web, but not in the DM365 documents that I looked at.
2b) How to set up and handle ARM's exception vectors (sprufg5a, p.20). Is it necessary to be able to use interrupts?
2c) How to set up and handle AINTC's vector table? Is it necessary? What are the alternatives? One of the DaVinci Linux driver files has a following comment: "we don't use the hardware vector table, just its entry addresses". Could someone please elaborate on that?
It would probably take less than half a page of code to give a complete example of doing what needs to be done to get interrupt working. Unfortunately searching the LSP for a solution is not very productive since a large part of the LSP code doesn't even apply to the DM365, or DaVinci, or any TI product for that matter.
Any help will be greately appreciated!
Pl. refer to the following file in the Linux distribution for details on handling the USB interrupts. The files are located under "drivers/usb/musb" directory.
1. davinci.c -> This is DM365 platform specific file that implements the first level interrupt handling. This file is generic for all DaVinci series of devices such as DM355, DM644x, DM646x etc. Refer to "davinci_interrupt()" function that implements the first level isr. Typically the sequence is as follows
2. musb_core.c -> This is the generic interrupt handler - second level. This file implements the logic for handling the endpoint, usb generic (connect, disconnect etc.) interrupts. This file implements the logic for initializating the USB controller FIFO's, setting up the controller modes - device/host etc. Refer to musb_init_controller() function for the init sequence. This would be typically called from musb_probe() function.
3. musb_gadget.c -> This file implements the device mode functionality. It handles the IO transfers Rx, Tx directions. Refer to musb_gadget_queue(), musb_g_rx() and musb_g_tx() functions.
regards
swami
Swami,
thank you for the response. However my question is related more to the programming of the ARM's interrupt controller (items 2a, b, c above). I'm getting USB interrupts, they propagate to IRQ0 (status) register of the AINTC, but my code is either never interrupted, or a "target reset" is reported by the CCS (depending on the settings of the CPSR made from the .gel file). I suspect some interrupt vector setting is missing, causing the vector 0 (reset) ARM interrupt, but the documentation doesn't explain how it needs to be done properly.
So, again, my questions are:
- what is the proper CPSR setting (and how this register could be modified directly from the code code, not the .gel file)?
- what's a proper way of setting the ARM vector table, specifically address 0x18, the IRQ vector?
- Is it necessary to use the Interrupt Entry Table of the AINTC, how to use it, and what are the alternatives?
Thank you for your help.
Alexander.
Hi Alex,
1. I think in the future we will have this register location reserved and it is only used for debug purposes. This register is a Read only register and is identical with INTSRCR. Same information on your other post applies here too. Anyway, here is more details on it.
The core interrupts (INTRUSB, INTRRX, and INTRTX in addition to USB_DRVVBUS) are aggregated into one within this register.
INTVECTR[31:25] is reserved.
INTVECTR[24] is USB_DRVVBUS interrupt.
INTVECTR[23:16] is INTRUSB.
INTVECTR[15:13] is reserved.
INTVECTR[12:09] is INTRRX[4:1]
INTVECTR[08:05] is reserved.
INTVECTR[04:00] is INTRTX[4:0].
2. If the corresponding bits within IRQ0 is set, this means that you have correctly configured/enabled interrupt at the USB Peripheral level. You probably are need to check your settings on configuring interrupt from the core interrupt handler level.
I would let others who are expert on the core interrupt handler take a stab on this part of the question.
Best regards, Zegeye
Zegeye AlemuI would let others who are expert on the core interrupt handler take a stab on this part of the question.
While the experts must be still looking for their daggers, I was searching other forums. Found something relevant in OMAPL137 posts. In my understanding, to get IRQs working I need to do the following (as a minimum):
1. Set up a separate stack for IRQ mode. Not sure how to combine it with .gel initialization. Seems like my .gel file sets the supervisor mode, but after my setStack() function is called from main() I don't see any changes in the stack pointer (looking at R13 in "All banked registers" in CCS). What's the right way of doing that (with and without a .gel file)?
2. Set up the IRQ ARM vector (address 0x18). That I seem to have figured out.
3.Set up an IRQ handler. Need to save/restore context, acknowledge the interrupt, jump to the relevant ISR, etc. There are minor questions not clear from the documentation. I can't believe that nobody at TI had written that code before.
"Experts on core interrupts", hello! Please!
Hi Alexander,
I am far from an "Expert on Core Interrupts" (I only started with the arm two months ago) but just a few moments ago, I was able to respond to an IRQ with an ISR. The configuration of the ARM was not as straight forward as I was expecting, but it seems to work now.
It has been a while since you posted this question. Let me know, if you are still looking for a solution.
Andy
Andy,
thank you. I'm past that point. Eventually I've got some code from TI that was doing 99% of what I needed to do (of which interrupts were a minor part).
Regards,
alexanderk Andy, thank you. I'm past that point. Eventually I've got some code from TI that was doing 99% of what I needed to do (of which interrupts were a minor part). Regards, Alexander.
Alexander,
I know this was a while ago but just in case you notice this, I am having similar difficulties with a different Divinci ARM. Could you please post your solution or the referenced TI code?
Thanks,
Colin