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

Can anyone provide an example of asynchronous exceptions?

Below is from ARMv7 Architecture doc.

          An exception is described as asynchronous if either of the following applies:
          — the exception is not generated as a result of direct execution or attempted execution of the instruction
          stream
          — the return address presented to the exception handler is not guaranteed to indicate the instruction that
          caused the exception.

I really don't quite understand , especially for the first scene.

Anyone can show me an example?

Thanks~

Parents
  • Probably the most common example would be interrupts (IRQs and FIQs).  Interrupts are events coming from outside the processor (*), and so asynchronous to the processor's execution.

    Take something like a UART/serial port as an example.  The UART could be configured to generate an interrupt when it receives a packet.  When we receive an interrupt from the UART, it's due to the receipt of a packet - not directly the execution of an instruction on the processor.  It's essentially random (**) when we get the interrupt, so the instruction pointed at by the LR tells us nothing about the interrupt.

    (* processors can have interrupt output signals, for example to signal PMU overflow.  However, these signals would be connected as inputs to an interrupt controller and it's the interrupt controller which would drive the interrupt signals into the processor.)

    (** you could argue that for something like a periodic timer we the programmers have a fairly good idea when it will happen.  But unless the processor was sitting in an idle loop or WFI, you couldn't predict accurately enough to know exactly instruction would be interrupted.)

Reply
  • Probably the most common example would be interrupts (IRQs and FIQs).  Interrupts are events coming from outside the processor (*), and so asynchronous to the processor's execution.

    Take something like a UART/serial port as an example.  The UART could be configured to generate an interrupt when it receives a packet.  When we receive an interrupt from the UART, it's due to the receipt of a packet - not directly the execution of an instruction on the processor.  It's essentially random (**) when we get the interrupt, so the instruction pointed at by the LR tells us nothing about the interrupt.

    (* processors can have interrupt output signals, for example to signal PMU overflow.  However, these signals would be connected as inputs to an interrupt controller and it's the interrupt controller which would drive the interrupt signals into the processor.)

    (** you could argue that for something like a periodic timer we the programmers have a fairly good idea when it will happen.  But unless the processor was sitting in an idle loop or WFI, you couldn't predict accurately enough to know exactly instruction would be interrupted.)

Children