• State Accepted Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 3 replies
  • Subscribers 352 subscribers
  • Views 4521 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

When an exception is taken into account

Karolis

Hi

Related to ARMv7-M architecture:

I am searching through all infocenter documents but still cannot find anything and answer this question: "When an exception is taken into account?" I mean, are exceptions only serviced after the current instruction in instruction flow, or exception can interrupt current interrupt in execution? I have found that exception servicing is asynchronous, but what does that mean? Also, memory access instructions can be abandoned and restated. So, does that mean that it is possible to interrupt it? Does it have something in common with memory attributes (normal, device, strongly-ordered)? Are other than memory access instructions also possible to interrupt/get them restarted? What indicates that for CPU to do? Reference manual seems to be incomplete from this question point of view or I cannot find what I need. Hope you guys can help me. Thank you in advance.

  • 0 Arm Employee Badge

    It is a big topic :-|

    It depends on the processor's implementation. Armv7-M doesn't specify this, but in the case of Cortex-M3/M4/M7, if the current executing instruction take multiple clock cycles, it can be interrupted subject to some restrictions:

    • Cortex-M3/M4: the current data transfer on the AHB need to be completed before interrupt handling sequence can be taken. If the current executing memory access instruction is LDM/STM/PUSH/POP, the instruction would stop after current transfer (but not at the end of the whole instruction), and the state of the instruction being store in ICI bits in the stacked xPSR, so that it can be resumed from that point when the ISR ended. If the interrupted instruction is LDRD/STRD and only half of the transfer is carried out, the instruction will be abandoned and the whole instruction is restarted when the ISR ended.
    • Cortex-M3/M4/M7: if the current executing instruction is not a memory access/floating point instruction but is multiple cycle (e.g. divide, branch), then the instruction is abandoned and restarted when the ISR ended.
    • Cortex-M3/M4/M7: if the current executing instruction is a floating point instruction, then the instruction execution could continue in parallel with stacking (part of exception handling sequence).
    • Cortex-M7, since it is based on AXI rather than AHB, it is possible for it to issue new transfers before outstanding transfers are completed. So it can start processing an interrupt request while there is outstanding transfer that is issued on the bus. There are some restrictions (not sure if I captured everything here, I could miss something):
      • If the instruction is a read and the access is for Device (including AHB peripheral bus) or Strongly Ordered, it must complete the current transfer on the bus before starting the exception handling sequence. This could be a part of a LDM/POP instruction, and the remaining parts of the LDM/POP can be suspend until after the ISR finished, just like Cortex-M3/M4.
      • If the instruction is an exclusive write to a shareable memory location (shareability defined by MPU/default memory map), it must complete the current transfer on the bus before starting the exception handling sequence.

    In general, if an interrupt is trigger when there is a read to Device/Strongly Ordered location and the read take multiple cycles, the processor need to wait until this transfer is completed before starting interrupt handling sequence.

    FPU memory accesses instructions with multiple data are handled in similar manners as LDM/STM.

    Asynchronous exception – architecturally the point the interrupt handling sequence starts is not guarantee to have any constant relationship with instruction stream. For example, when the IRQ arrived when PC is X, by the time stacking happen, the processor could have executed a number of instructions after that point and the stacked PC would be X+Y. This included IRQs, SysTick, NMI, PendSV, asynchronous bus faults (previously known as imprecise bus faults).

    Synchronous exceptions – architecturally the interrupt handling sequence start right at the current program counter address (e.g. precise bus faults, Memmanage fault, UsageFault) or next address (e.g. SVC).

  • 0 in reply to Joseph Yiu

    I appreciate so much for this answer!! Also, wanted to ask maybe you can provide references to thing mentioned to reference manual or CPU implementation technical manuals?

  • +1 Arm Employee Badge in reply to Karolis

    Hi Karolis,

    Sorry for the delay.

    For Cortex-M3/M4, the technical reference manual (TRM) has some information:

    Cortex-M4:

    http://infocenter.arm.com/help/topic/com.arm.doc.100166_0001_00_en/ric1417175930567.html

    Cortex-M3:

    http://infocenter.arm.com/help/topic/com.arm.doc.100165_0201_00_en/ric1414056338502.html

    Unfortunately Cortex-M7 TRM does not include the details in this area.

    The Device generic user guide also has some general information about exception handling, but not much about details of the behavior:

    http://infocenter.arm.com/help/topic/com.arm.doc.dui0553a/BABEHHHB.html

    In Armv7-M Architecture Reference Manual

    https://developer.arm.com/docs/ddi0403/e/armv7-m-architecture-reference-manual

    Section B1.5.10 documented the details of LDM/STM/PUSH/POP/VLDM/VSTM/VPUSH/VPOP handling (ICI bit)

    Section A2.4.1 gave some references about the synchronous and asynchronous exceptions.

    Some of the information I mentioned in my previous reply I don't really know if they are documented or not.

    regards,

    Joseph