title: How do interrupted instructions get continued with Cortex-M NVIC?
body: <p>(I am learning the Cortex-M microcontroller and can't help compare it to the x86 cpu.)</p>
  <p>With x86, for a fault, such as page fault, the instruction that caused/triggered the fault will be executed again after the fault has been handled.</p>
  <p>But with ARM NVIC, I didn't see such mechanism. The NVIC hardware just automatically place the <code>R0-R3, R12, PC, LR, SP xPSR</code> onto the stack at the ISR entry (with no interference from programmer). And restore this register context from stack at the ISR exit. Based on my debugging, after the restore, <strong>the PC register will still point to the address of the interrupted instruction</strong>.</p>
  <p>I think <strong>an interrupt can only happen at the boundary of a cycle</strong> (correct me if I am wrong). I am not sure if below 2 guesses hold:</p>
  <ul>
  <li><p>For a single-cycle instruction, that interrupted instruction will be executed again since the PC still points to it.</p>
  </li>
  <li><p>For a multi-cycle instruction, the remaining cycles of the interrupted instruction should be continued.</p>
  </li>
  </ul>
  <p>I guess these 2 scenarios should be guaranteed by the micro-code that implement the instructions.</p>
  <p>So my questions are:</p>
  <ul>
  <li><p>Does ARM NVIC has a mechanism like x86 to re-execute the instruction that caused fault?</p>
  </li>
  <li><p>Does the interrupted instruction get continued like the 2 scenarios above?</p>
  </li>
  </ul>
  <h2>ADD 1 -- 9:31 PM 10/6/2020</h2>
  <p>Thanks to domen's reminding.</p>
  <p>I checked some materials on <em>exceptional control flows</em>, exceptions are usually classified as:</p>
  <ul>
  <li>interrupt (happens asynchronously, handled after current instruction finishes, handler returns to next instruction.)</li>
  <li>trap (happens synchronously, intentionally triggered by current instruction, handler returns to next instruction.)</li>
  <li>fault (happens asynchronously, relevant to current instruction or not, handler returns to current instruction.)</li>
  <li>abort (happens asynchronously, relevant to current instruction or not, handler never returns to application but to a special abort routine.)</li>
  </ul>
  <p>I checked the ARMv7-M Arch Ref Manual. In section B1.5.6 Exception Entry Behavior, I found a pseudo-code for determining the return address:</p>
  <p><a href="https://i.stack.imgur.com/TN2vr.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/TN2vr.png" alt="enter image description here" /></a></p>
  <p>So for different exception types, different return addresses can be returned . Both <code>ThisInstrAddr</code> and <code>NextInstrAddr</code> are possible.</p>
  <p>I think there should be a little correction to the previous 2 scenarios. That is, the <code>PC</code> value automatically pushed onto the stack by the hardware is the <code>ReturnAddress</code>. And it can be <code>ThisInstrAddr</code> or <code>NextInstrAddr</code>.</p>
  <h2>ADD 2 -- 10:32 PM 10/6/2020</h2>
  <p>Thanks to old_timer. Yes I did mix up the fault and interrupt a bit. Fault doesn't go through the NVIC, interrupt does.</p>
  <p>And below is a the priority list of internal exception/fault and external interrupts. (quoted from the <em>The Designer's Guide to Cortex-M Processor Family</em> 2nd edition)</p>
  <p><a href="https://i.stack.imgur.com/enjwg.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/enjwg.png" alt="enter image description here" /></a></p>