WFI and cpsid i in ARM Cortex R5

Hello everyone,

I am working on an ARM Cortex-R5 design where the core operates in VIC (Vectored Interrupt Controller) mode and is connected to a custom Vectored Interrupt Manager (VIM) via the dedicated VIC port interface.

Our system architecture requires the bootloader to issue an SoC-level reset to jump into the main application. A strict hardware constraint of this SoC reset is that the Cortex-R5 core must be in a steady WFI (Wait For Interrupt) low-power state for the reset signal to successfully propagate throughout the system fabrics.

Before triggering the WFI state, the bootloader's teardown sequence is responsible for disabling and clearing all peripheral interrupts at the VIM level. However, we are observing a strange, non-deterministic behavior depending on when CPSID I is called relative to the VIM de-assertion.

The Sequences

Sequence 1 (Fails Intermittently):

CPSID I ; 1. Mask IRQ exceptions in CPSR
; [Code to disable VIM interrupts]
; [Code to clear active VIM flags]
DSB
ISB
WFI ;

Behavior: The device fails to jump to application because the reset cannot be propagated, which points to the fact that device is not in wfi.

Sequence 2 (Succeeds Consistently):

; [Code to disable VIM interrupts]
; [Code to clear active VIM flags]
DSB
ISB
CPSID I ; 3. Mask IRQ exceptions in CPSR
WFI ; <-- Core enters WFI standby consistently

Behavior: The SoC level reset propagates correctly.

My Questions for the Forum:

Per the ARMv7-R Architecture Reference Manual, setting the CPSR I bit (CPSID I) masks interrupt exceptions from branching to vectors, but does not block the architectural WFI wake-up event logic. A pending signal on the nIRQ line will always prevent or wake the core from a WFI.

VIC Port Handshake: When the core is in VIC mode and CPSID I is executed first (Sequence 1), does masking the IRQ inside the CPSR affect or freeze the hardware-level handshake protocol across the VIC port interface?
Ghost Pending Interrupts: Does clearing/disabling the VIM after CPSID I leave a "phantom" pending event inside the core pipeline? Does the internal interrupt controller of the Cortex-R5 require the CPSR I bit to be 0 (0) to properly complete a de-assertion handshake over the VIC port?
What exactly happens inside the Cortex-R5's interrupt pipeline state machine when CPSID I is executed while a physical nIRQ signal from the VIC is still asserted?

Any architectural insights into how the Cortex-R5 VIC interface tracks de-assertion cycles under a masked CPSR state would be highly appreciated!

Thanks in advance,

Aswin