1

(I am learning the Cortex-M microcontroller and can't help compare it to the x86 cpu.)

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.

But with ARM NVIC, I didn't see such mechanism. The NVIC hardware just automatically place the R0-R3, R12, PC, LR, SP xPSR 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, the PC register will still point to the address of the interrupted instruction.

I think an interrupt can only happen at the boundary of a cycle (correct me if I am wrong). I am not sure if below 2 guesses hold:

  • For a single-cycle instruction, that interrupted instruction will be executed again since the PC still points to it.

  • For a multi-cycle instruction, the remaining cycles of the interrupted instruction should be continued.

I guess these 2 scenarios should be guaranteed by the micro-code that implement the instructions.

So my questions are:

  • Does ARM NVIC has a mechanism like x86 to re-execute the instruction that caused fault?

  • Does the interrupted instruction get continued like the 2 scenarios above?

ADD 1 -- 9:31 PM 10/6/2020

Thanks to domen's reminding.

I checked some materials on exceptional control flows, exceptions are usually classified as:

  • interrupt (happens asynchronously, handled after current instruction finishes, handler returns to next instruction.)
  • trap (happens synchronously, intentionally triggered by current instruction, handler returns to next instruction.)
  • fault (happens asynchronously, relevant to current instruction or not, handler returns to current instruction.)
  • abort (happens asynchronously, relevant to current instruction or not, handler never returns to application but to a special abort routine.)

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:

enter image description here

So for different exception types, different return addresses can be returned . Both ThisInstrAddr and NextInstrAddr are possible.

I think there should be a little correction to the previous 2 scenarios. That is, the PC value automatically pushed onto the stack by the hardware is the ReturnAddress. And it can be ThisInstrAddr or NextInstrAddr.

ADD 2 -- 10:32 PM 10/6/2020

Thanks to old_timer. Yes I did mix up the fault and interrupt a bit. Fault doesn't go through the NVIC, interrupt does.

And below is a the priority list of internal exception/fault and external interrupts. (quoted from the The Designer's Guide to Cortex-M Processor Family 2nd edition)

enter image description here

artless noise
  • 21,212
  • 6
  • 68
  • 105
smwikipedia
  • 61,609
  • 92
  • 309
  • 482
  • 2
    It appears you're mixing up synchronous exceptions (page fault) and asynchronous exceptions (interrupts). Could you clarify which you have in mind? Does peeking into ARM ARM (Architecture reference manual) and ARM TRM (technical reference manual) help? – domen Oct 06 '20 at 13:05
  • 1
    Btw, on x86, not all exceptions will make IP point at address of instruction. For example INT3: https://xem.github.io/minix86/manual/intel-x86-and-64-manual-vol3/o_fe12b1e2a880e0ce-209.html "Saved contents of CS and EIP registers point to the instruction following the INT 3 instruction." – domen Oct 06 '20 at 13:10
  • 1
    The nvic is just an (I think optional) interrupt controller, the return solutions are specific to the core/architecture which is in the ARM ARM. with the full sized you would do something like subs pc,lr,#4. the cortex-m exceptions the lr indicates the mode so you have to modify the actual return address on the stack. assuming that the ARM ARM says it doesnt automatically re-run faulted instructions for fault based exceptions, for interrupts which go through the NVIC those are not faults or are chip specific and you have to look at chip docs not arm docs. – old_timer Oct 06 '20 at 14:21
  • 1
    but even a chip fault if you want to go back and re-run an instruction you need to use or change the return address. If the chip vendor used an interrupt to indicate an exception (fault) then that is simply a chip design bug and I would question using that vendor again. depends on the peripheral and the interface though. – old_timer Oct 06 '20 at 14:25
  • @old_timer Thanks for pointing out that the fault doesn't go through NVIC. – smwikipedia Oct 06 '20 at 14:29
  • 1
    if you look at the vector table the first 16 are the stack pointer and reset and the rest are I think various flavors of faults which would be caused by an instruction or a fetch (or an invalid instruction). The ones after that in the table are interrupts that come from the chip vendor into the core. (this is shown in the ARM ARM for the core armv6-m or armv7-m (or armv8-m) depending on your core, but both have the same table and mechanism) – old_timer Oct 06 '20 at 14:36

0 Answers0