Rp2350 - IRQ latency is affected by XIP cache misses

[dikdom]

Hello,

it would be good to see in doc (would have been good not facing with it on testpad) that the interrupt latency is heavily affected by the XIP cache misses.
I mean instead of 12 cycle the ~300 cycles are a bit dreadful.

The reason is written here I believe: https://forums.raspberrypi.com/viewtopic.php?p=2036379#p2036379

It also would be good to have in doc that what happens if an un-XIP-cached flash code is interrupted with an ISR located in RAM, on the same core (would it still stall the ISR startup?).

If it is documented in RP2350 the datasheet, then my bad. (Could you please give me a reference to that part of the specs?)

[Wren6991]

It's not directly documented but you can infer this from the AHB5 bus protocol rules: https://documentation-service.arm.com/static/6141bf0d674a052ae36ca811

The worst-case penalty for IRQ entry is 4x the XIP cache miss time, because you can have all of the following outstanding transfers on XIP at the point the IRQ asserts:

• 1x C-port address phase
• 1x S-port address phase
• 1x C-port data phase
• 1x S-port data phase

Depending on the arbitration order, it might be necessary for all four of these reads to complete before the vector table fetch can complete.

[dikdom]

Ok.. and do the XIP (non-cached) reads also influence the IRQ latency?

Anyway, IMHO a note would be nice at interrupts discussing the causes for latency (what can increase the latency. Not for me, because I'm already aware of that...)

[Wren6991]

Yes. Uncached actually has a lower worst-case because it'll be (up to) a 32-bit access, whereas cache misses are 64-bit accesses. The cache always blocks on the downstream transfer.

I included loads (reads) in my list above: instruction fetch happens through the Code (C) port on our M33, and load/stores happen through the System (S) port.

I'm happy to add this to the docs but it's useful to talk things through first so we know everything we should add.

[dikdom]

Yes. Uncached actually has a lower worst-case because it'll be (up to) a 32-bit access, whereas cache misses are 64-bit accesses. The cache always blocks on the downstream transfer.

I included loads (reads) in my list above: instruction fetch happens through the Code (C) port on our M33, and load/stores happen through the System (S) port.

I'm happy to add this to the docs but it's useful to talk things through first so we know everything we should add.

Ok, for me the consequence is that to minimize the IRQ latency it is not enough to put the VTOR into RAM (it is already there by default) and put the ISR into RAM. It is also important, that the code, which is being interrupted also should be in RAM, otherwise a flash read could easily block the ISR startup (do I see it right)?

And... this can be achieved by either putting all the code into RAM (copy_to_ram) or make sure that all the code, which is executed on the same core that accepts the interrupt, are marked with __not_in_flash_func ... all the library function calls must be inline or copied by hand from the source to my source...