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

What does "low interrupt latency" means

Hi All,

In R4 trm, there are some words about low interrupt latency. I have a question about it.

"   Low interrupt latency

On receipt of an interrupt, the processor abandons any pending restartable memory operations.

Restartable memory operations are the multiword transfer instructions LDM, LDRD, STRD, STM, PUSH,

and POP that can access Normal memory.

To minimize the interrupt latency, ARM recommends that you do not perform:

• multiple accesses to areas of memory marked as Device or Strongly-ordered

• SWP operations to slow areas of memory."

My question is that:

Suppose I use the LDM instruction and this causes a cache miss, and this cache miss triggers line fill which take forever. This hangs my cpu. So my cpu cannot respond  any more. In this case, will IRQ/FIQ trigger the cpu to abandon this LDM? If yes, what kind of special configuration I need. Thanks.

Best,

Patrick

Parents
  • Hi,

    I'm afraid the issue here is because your AXI transaction never receives a response. This is a violation of the AXI protocol, and as a result the behavior of the Cortex-R4 processor is undefined.

    While the Low Interrupt Latency feature of the R4 allows memory transactions to be 'abandoned' so that an interrupt can be serviced sooner, any AXI transactions that have already begun must still complete (otherwise, as I've said above, it is a protocol violation).

    For a read operation that is abandoned like this, the R4 will usually discard whatever data is returned and it will ignore the read-response, but it is critical that any AXI transactions still complete in their entirety.

    The solution to this will be system dependent - for example, changing the behavior of the target so that it complies to the AXI protocol and completes the transaction, or marking the region of memory marked as 'No Access' so that no transactions are issued to it.

    Dave

Reply
  • Hi,

    I'm afraid the issue here is because your AXI transaction never receives a response. This is a violation of the AXI protocol, and as a result the behavior of the Cortex-R4 processor is undefined.

    While the Low Interrupt Latency feature of the R4 allows memory transactions to be 'abandoned' so that an interrupt can be serviced sooner, any AXI transactions that have already begun must still complete (otherwise, as I've said above, it is a protocol violation).

    For a read operation that is abandoned like this, the R4 will usually discard whatever data is returned and it will ignore the read-response, but it is critical that any AXI transactions still complete in their entirety.

    The solution to this will be system dependent - for example, changing the behavior of the target so that it complies to the AXI protocol and completes the transaction, or marking the region of memory marked as 'No Access' so that no transactions are issued to it.

    Dave

Children
  • Hi Dave,

    I agree with you. But if ARM hangs because of a LDM, which is issued through AXI READ channel. And if I interrupt it with a FIQ, even I try to use STM instructions, no AXI transaction is issued through ARM AXI-main interface. Should I expect to have the AXI write transaction because AXI supports outstanding transactions. Do you have any special/debug registers I can set to clean this undefined status.

    Thanks,

    Patrick

  • I'm still not sure whether when you talk about 'hang' you mean a hardware design error like Dave is talking about. In fact I'm wondering now whether you have actual hardware or a simulation as I'd be very surprised to find an error like that in production hardware.

  • When a processor behavior is 'undefined' it means that it is outside of the specification the processor was designed to, so the actions taken by the processor will be unknown and unpredictable. Since an incomplete AXI transaction is a violation of the AXI specification it isn't something the R4 was intended to cope with, so I'm afraid there isn't any register you can use to 'flush' it from the R4.

    Incidentally, it is fairly likely that an incomplete AXI transaction would also have wider impacts throughout a system, so I would imagine that only way to get the system into a known safe state would be to reset all of it.