- Ask a related questionWhat is a related question?A related question is a question created from another question. When the related question is created, it will be automatically linked to the original question.
Hi,
When clearing a peripheral interrupt (e.g. RTI Compare interrupt, cleared through RTIINTFLAG register), how can it be ensured that the write to the memory-mapped register was indeed completed and that the flag was cleared, before continuing? This write completeness needs to be ensured in the case of an interrupt handler where the IRQs are re-enabled (by clearing the I-bit in the CPSR) after clearing the interrupt flag: if the I-bit is cleared before the write to the interrupt flag has been completed, this will result in the interrupt being caught again.
Is there a standard/recommended way to ensure completeness of writes on peripheral registers and if so, where would that be documented?
Thank you,
Antoine
Hello Etienne,
I think you are refering to §7.118 "Software Read Back of Written Configuration" in the Safety Manual. However, our concern is not safety here. It is pure functional. We are not trying to mitigate HW failures, but simply do the appropriate sequence of operations so that the CPU correctly clears interrupt bits before we re-enable core interrupts (IRQ).
You are correct. This is described within the context of being a safety mechanism but more widely it is to insure that the write has completed successfully. The reason for a different value being read back could be a number of reasons including the flag not being cleared yet. Given the sequencing and the fact that the read will be held until the write is completed, the most likely cause of a mismatch would be either a new interrupt occurrence or a stuck bit, though.
1) We have found some documentation saying how to proceed, but we have questions on it. ARM Cortex-R5 TRM, Appendix D "Memory Ordering" says that since all the accesses to peripherals go through the same port (peripheral bus), reading the same control register as just written will guarantee completion of the write before the read. That seems great. But it only applies if we configure the region as Device. It does not say the behavior if configured as Strongly Ordered. Is that appendix also applicable if Strongly Ordered is used?
Certainly the description indicates a positive behavior with respect to your objectives. However, I cannot infer that this section also applies to Strongly Ordered memory types. This is something only ARM can answer directly.
However, the following from section 7.2 in the ARM Cortex-R5F TRM indicates a similar attribute to the statements in reference to Device type memory. All access will occur in program order.
2) Also, the key for ordering seems to be that all accesses go through the same port. However, there are two ports towards the peripherals: AXI Peripheral interface and Virtual AXI Peripheral interface. By default, the virtual is disabled. But do you confirm that if we would have enabled the virtual interface, we would lose the ordering property between read and writes? (e.g. if the write when through one port and the read through the other...) This makes me realize I don't know what tells through which port an access will go... Could you tell us if the Virtual port is available on the TMS570LC and if so, what is the value of its base address? (Peripheral interface region registers BaseAddress field for LLPP Virtual AXI)
We do not implement the Virtual AXI Peripheral Interface Port. We only have the standard AXI Peripheral Interface Port so there is no concern over having two paths for access.
