• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 346 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.

AM6442: PRU INTC enable

Steven Hansen
Intellectual 686 points
Part Number: AM6442


Two questions:

1. In the Rev F TRM for AM6442, Page 3208 has a set of steps for configuring the PRU interrupt controller (Section 6.4.7.2). Step 5 discusses writing to ICSS_INTC_HINT_ENABLE_SET_INDEX_REG, but does not discuss writing to ICSS_INTC_ENABLE_SET_INDEX_REG. It is my understanding that the "HINT_ENABLE_SET" register enables the host interrupt, and the "ENABLE_SET" register enables the channel.

Do we need to write to ICSS_INTC_ENABLE_SET_INDEX_OFF? If so, is this missing from the list in Section 6.4.7.2?

Note this is also discussed a few pages back in section 6.4.7.1.2.1.1 where it says we should write to ICSS_INTC_ENABLE_SET_INDEX_OFF.

2.  The definitions for ICSS_INTC_HINT_ENABLE_SET_INDEX_REG and ICSS_INTC_ENABLE_SET_INDEX_REG both show bits 0-9 for enable, and bits 10-31 reserved. But this would only allow enabling host interrupts (or channels) 0-9. Since the PRU has 20 channels / 20 host interrupts, how do we enable interrupts 10-20?

This came up while trying to enable Host Interrupt 11 for the RTU (mapped to R31 bit 31).

  • 0
    Intellectual 686 points

    I was able to figure this out by trial and error. 

    ICSS_INTC_HINT_ENABLE_SET_INDEX_REG enables host interrupts. Writing a value of 0 to this register enables interrupt 0, writing a value of 1 enables interrupt 1, all the way up to interrupt 19 (20 total host interrupts).

    ICSS_INTC_ENABLE_SET_INDEX_OFF doesn't enable channels, it enables events (interrupt inputs to the PRU INTC). On AM6442 there are 160 events / source interrupts. Writing a value of 0 enables event 0, writing a value of 1 enables event 1, all the way up to event 159.

    What is particularly confusing is that the TRM uses the word 'interrupt' to refer to 'host interrupts' (interrupt outputs from PRU INTC) and also 'system events' (interrupt inputs to PRU INTC). Often there is little or no clarification as to which type of interrupt is being discussed. It would clarify a lot if the terminology was standardized to avoid these confusions. For example, the TRM occasionally refers to interrupt inputs to PRU INTC as "events". If 'events' was used consistently throughout the TRM when referring to interrupt inputs to the PRU INTC, it would be much easier to understand.

    The TRM also lacks context or additional information that is helpful to figuring out what is wrong when code doesn't work. For example, by trial and error I found that writing an index (side note: 'index' is never defined in the TRM; index of what? host interrupt? source interrupt? system event? channel number?) to ICSS_INTC_HINT_ENABLE_SET_INDEX_REG causes the corresponding bit to be set in ICSS_INTC_ENABLE_HINT_REG0. Likewise writing an index to ICSS_INTC_ENABLE_SET_INDEX_OFF causes the corresponding 'event' bit to be set in ICSS_INTC_ENABLE_REG0-4. But this is never detailed in the TRM.

  • 0 in reply to Steven Hansen
    TI__Guru**** 202390 points

    Hello Steven Hansen,

    Thank you for working on this and updating the thread.

    Have a good day.

    Regards,

    Sreenivasa