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.
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
Hi Patrick,
the situation you describe is exactly where the Low latency interrupt mode is designed to help. It's described in more detail in the TRM halfway down this page: ARM Information Center and enabled by default. On returning from the interrupt, the LDM will be restarted. No special configuration should be needed.
regards,
Jon
Hi Jon,
Thanks for your reply. I can't agree with you more.
But based on our system, when the R4 hangs because LDM, my interrupt is still not served. This LDM doesn't get any data back since the data request shows up on the AXI. AXI read data response channel never gives any valid data back. Will this block something like LSU/PFU to get the ISR code from ITCM?
Thanks,
Although it's unlikely, can you check that the Low Latency bit is still set in the system control register?
The other possibility is that the address you are accessing has been marked by the MPU as Device or Strongly ordered memory. The memory attributes are described in more detail in the TRM here:ARM Information Center
This application note may also be helpful:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dai0296a/index.html
Please note that even if the MPU is disabled, although no access checks are performed, there is still a default memory map which has regions of strongly ordered and device regions - see here for details:
ARM Information Center
Thanks for your reply. In the past days I did some arm simulation to catch the problem. I can make ARM-R4 serve FIQ when LDM is on-going now. In my ISR, I try to use STR instruction, but i cannot see any transaction on the AXI-Main interface. I am wondering whether LSU is stopped because of the previously un-responded LDM.
when you say you did some simulation, are you simulating RTL, or is this on a model? What sort of memory is the store going to? (ie just checking it's not on a TCM interface). Even if it's to normal memory, it could be ending up in the cache depending on whether you have write-through or write-back mode configured. Just trying to make sure I've got a full picture of your system.
I see you're talking about loading a cache line in an abandoned LDM.. By hang do you mean the time to load a cache line from memory and that the processor is slowed down by that, or do you mean the processor actually does hang and does not continue execution?
If one is worried by that time and have to have a low latency interrupt then one needs to use Tightly Coupled Memory for everything the critical interrupt handler uses.
The problem as I see it then is whether a cache line fill for the abandoned LDM will interfere with a device access using STR. I don't know the answer to that, presumably it depends on the implementation.I suppose it is possible. Also a device access will complete rather than be abandoned if an interrupt happens during one which could also affect the interrupt latency.
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
If the CPU delay a long time, the CPU is equivalent to sleep!
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.
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.