• State
  • Locked Locked
  • Replies 10 replies
  • Subscribers 106 subscribers
  • Views 643 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

More on interrupts on DM365 w/o Linux

alexanderk
Expert 1055 points

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!

  • 0
    TI__Expert 7435 points

    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

    • Handle CPPI interrupts
    • Handle Endpoint interrupts
    • Acknowledge interrupts by writting into the EOI registers

    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

  • 0 in reply to swami
    Expert 1055 points

    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.

  • 0
    TI__Expert 5475 points

    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

  • 0 in reply to Zegeye Alemu
    Expert 1055 points

    Zegeye Alemu said:
    I 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!

  • 0 in reply to alexanderk
    Prodigy 130 points

    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

  • 0 in reply to Andy4678
    Expert 1055 points

    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.

  • 0 in reply to alexanderk
    Intellectual 570 points

    alexanderk said:

    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

  • 0 in reply to alexanderk
    Prodigy 60 points
    I am having similar difficulties with dm365. Could you please post your solution or the referenced TI code? thank you.
  • 0 in reply to Colin Hankins
    Prodigy 60 points
    I am having similar difficulties with dm365. Could you please post your solution or the referenced TI code? thank you. My Email: johnbill@163.com
  • 0 in reply to Bill Lee77
    Expert 1055 points
    Bill,
    at the time I was working on a USB bootloader program (if I remember correctly, ROM USB bootloader option did not work on the DM365 or did not provide the features I needed). I was able to get some code from TI doing something very close to what I needed, but interrupts were not even used in this code.