• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 30 subscribers
  • Views 556 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.

Original question:

TM4C123GH6PM: When to call IntPrioritySet() in the configuration process?

TM4C123GH6PM: IntPrioritySet() under interrupt enabled, IRQ priority re-evaluation, IntPrioritySet() execution time.

Hideaki Nambu
Mastermind 9165 points
Part Number: TM4C123GH6PM

Hello,


Q1.
Please advise a general procedure of interrupt priority change under interrupts enabled.
Is it possible just to call IntPrioritySet() ?

Assume:
- Interrupt enabled at the beginning.
- Tivaware driver library


Once I wondered the necessity of disabling interrupts, but a sample code
[interrupts.c: Ln417] calls IntPrioritySet() under GPIO interrupts enabled.

I also think it would be best to disable interrupts if the application accepts:
e2e.ti.com/.../563599

Q2.
Please assume that there are multiple IRQ pending.
Then IntPrioritySet() changes the priority of a pending IRQ.
In the case, is it possible for the function to change the next ISR?
In other words, Is the next ISR chosed after the function?

Q3.
My customer asked the CPU cycle # of the funciton IntPrioritySet().
Could you please advise?

My idea is to insert the instruciton in the C code to makes sure
the completion of the priority change.
In the case my customer would not have to put a delay loops until the change become effective.


DS p.92
Dynamic exception priority change
When an exception priority has to change when the exception is pending or active,
use DSB instructions after the change. The change then takes effect
on completion of the DSB instruction.

  • 0
    TI__Guru*** 135355 points

    Hello Nambu-san,

    Q1.

    Yes, only IntPrioritySet call is needed to set the priority.

    It is ideal to set the Priority beforehand. The example is a bit different than practical application as it manually triggers the interrupts. So there was no issue of interrupts already being fired when making the change.

    Q2.

    I don't believe that changing the priority will take affect on the order of the ISR's unless the IRQ fires AFTER the priority change, but I can't say this case has come up before or we have tested it. This is a very obscure case to begin with and borderline unrealistic for practical applications because it implies an ISR would include changing the priority for interrupts and I am not sure why any application would want to change interrupt priorities based on another interrupt. Interrupt priorities should be established at the start of the application. Dynamic prioritization like that sounds like something far too advanced to make logical sense inside of a 32-bit ARM MCU.

    Q3.

    Looking at the Disassembly view for the interrupts example and looking at the IntPrioritySet API, it looks like it only takes 3 assembly commands to execute. The change should take affect as soon as the API ends. I don't see any specifications indicating time for the value to take affect.