-1

This is a rather an 'expert' question but we have a similar issue and I have trouble understanding the concept of interrupt-priority with respect to the execution of ISR in and embedded DSP system.

Let's say we have two - ISR1 and ISR2 - interrupts occuring after each other like shown below:

enter image description here

I'd like to compare two scenarios with respect to the interrupt priority and thread-safety of the system. Assume, we have no semaphore, mutex, etc. and gcc as a compiler

So, what happens if:

a)

  • NVIC priority of IRQ1 is higher than IRQ2
  • ISR1 contains a critical memset function, ISR2 contains uncritical sections only

b)

  • NVIC priority of IRQ1 is lower than IRQ2
  • ISR1 contains a critical memset function, ISR2 contains uncritical sections only

My expectation would be:

a) Nothing happens, ISR2 is exectuted once ISR1 is finished

b) Memset is interrupted (uo-oh), system throws an exception.

Am I correct with that?

hendrikschnack
  • 75
  • 1
  • 9
  • Why (and how) would the system "throw an exception"? Most likely, it'll just silently produce incorrect results when code that expects to be a critical section is interrupted. – EOF Oct 02 '20 at 17:13
  • memset, memcpy, etc are just loops that use store or load and store instructions which can be interrupted all day long, no problem. memset/cpy etc should be re-entrant as C is re-entrant so everything you need is passed in so even if one is in some magic high level language function call, another can make a magic high level language function call as well...its just instructions. – old_timer Oct 02 '20 at 17:55
  • the only time it matters is if the data overlaps then you need to outside of this put some locking in as well as a way to record the interrupt and handle it in the foreground or in some lower priority periodic housekeeping interrupt. – old_timer Oct 02 '20 at 17:56
  • kinda by definition the higher priority interrupt if you have a priority system can interrupt a lower but not vice versa, what you define higher and lower is part of your system design not the architecture. Ideally but is architecture dependent and sometimes settings, that irq2 if lower priority will start once irq1 is done. when possible you may wish to set flags/data in the isr and do the actual handling later in a foreground driver that is interruptable and can have extra code and time to wait for a lock, etc. – old_timer Oct 02 '20 at 17:57
  • at the end of the day this is all about your system design which includes software and the features/limitations of the hardware which you can/should peform target tests on. (well well over 99% of bare metal programming is reading and throwaway coding, the actual code end of the day is relatively simple after that). – old_timer Oct 02 '20 at 18:03

1 Answers1

0

If see NVIC then I understand that we talk about Cortex-M core uCs.

The first question is what you mea by critical section. There are two posibilities:

  1. Yuo modify the shared object.
  2. The timing of the code executed is critical and it should not be interrupted by antyhing (for example it is a bitbanding communication driver)

If the pririty of the interrupt 1 is higher than the interrupt 2 then the interrupt 1 cannot be preempted by the interrupt 2. The uC will remember that the interrupt 2 is pending and it will invoke its handler when interrupt has finished.

In the opposite situation interrupt 2 will preempt the execution and return to the interrupt 1 handler when finished.

b) Memset is interrupted (uo-oh), system throws an exception.

I do not understand what you mean. memset is just a normal function. If interrupt arrives in the middle of its execution then when interrupt handler returns control to it will continue from the point where it was interrupted. No exceptions. Interrupts always happens in the middle of some function.

If both handlers modify the same area of memory you need to provide the synchronisation mechanisms to prevent unpredicted results of this operation. Example: interrupt 1 executes memset and sets the value 5 to the memory location starting at address 100 and ending at address 100. You expect to have 5 in all 100 bytes. But in the meantime (lets say memset was at address 160) the interrupt 2 arrives and sets the same memory locations to 10. When this interrupts finishes execution that memory area is set to 10. But the interrupt 1 continues execution and sets the remaining 40 bytes to 5. So after it you have memory area from address 100 to 159 set to 10 and from 160 to 200 to 5 which probably is not what you would expect.

0___________
  • 60,014
  • 4
  • 34
  • 74