• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 31 subscribers
  • Views 170 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

AM6422: AM6422 PRU Interrupt Vector Table Location

Seth Appleman
Prodigy 220 points

Part Number: AM6422
Other Parts Discussed in Thread: TMDS64EVM

I am setting up a timer on the AM6422 PRU_ICSSG to act as a frame interrupt timer, using the PRU IEP module. I am setting up the timer compare function per AM64x TRM section 6.4.13.2.4.

 

When the timer expires, as indicated by register IEP_CMP_STATUS_REG, I want to configure the PRU_INTC event 7 (pr0_iep_tim_cap_cmp_pend) to fire an interrupt. I want the fired interrupt to invoke an interrupt handler I can use to trigger my periodic frame processing within the PRU firmware. Is there some sort of Interrupt Vector Table within the PRU firmware that I can setup to map the interrupt firing to an interrupt handler routine? I have seen this concept for mapping interrupts to handlers in one of the other processing cores (A53, R5F, M4F), but not in the PRU itself.

  • +1
    TI__Guru** 109810 points

    Hello Seth,

    PRU deals with interrupts a bit differently from other cores.

    The interrupt controller INTC does not actually have the capability to preempt currently running code - this makes your code 100% deterministic by default. For more information about the INTC, please start by taking a look at 
    https://dev.ti.com/tirex/explore/node?isTheia=false&node=A__ARwLDTX.JuwQ7FVKGFsVJg__AM64-ACADEMY__WI1KRXP__LATEST

    PRU_ICSSG subsystems have an additional tool, called the task manager, which IS capable of preempting PRU execution - we added the task manager specifically because it helped us to get to gigabit Ethernet speeds.

    I have not had time yet to write documentation on the task manager, so you are stuck with the Technical Reference Manual (TRM) for our public documentation for now. However, we just published a new example to the OpenPRU repo which uses task manager. You can find that project here, hopefully we included enough comments and documentation to give you an idea of how it is programmed:
    https://github.com/TexasInstruments/open-pru/tree/main/examples/multicore_scheduler 

    Don't be surprised if you see some includes shift around in that project in the next week or so, I am getting rid of external dependencies within the PRU firmware to make future porting efforts between processors easier.

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    TI__Guru** 109810 points

    Also, I sent you an e2e friend request so we can have an offline discussion about connecting you with your company's TI representative. Please accept that so we can have a sideband chat.

  • 0 in reply to Nick Saulnier
    TI__Guru** 109810 points

    Also also, I'm evaluating an update to the default makefile structure for OpenPRU projects. Could I get your input as someone who is ramping on the core?

    I am considering grouping reused PRU makefile content into a single include file. From an "ease of understanding/use" standpoint, what are your thoughts on the proposed pru_rules.mak + per-core makefile organization compared to the existing per-core makefiles?

    Proposed approach: pru_rules.mak + per-core makefile

    project's PRU0 makefile

    pru_rules.mak

    Current approach: self-contained makefile

    project's PRU0 makefile

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    Prodigy 220 points

    I appreciate you reaching out but I have not yet had a chance to play with the makefiles or other build processes yet - I am still awaiting a shipment with my TMDS64EVM to arrive at my office. Hopefully soon, and I can try both of these approaches and let you know.