Are you using flash at all? That's the usual first suspect for this kind of thing - typically the CPU is fetching from cache or RAM when the interrupt occurs and the interrupt sequence starts on the next cycle, but if the CPU happens to be fetching an instruction (or data word) from flash when the interrupt occurs, that flash access has to complete first (~16 cycles) before the interrupt sequence can start.
Note that it's not enough to just put your interrupt handler itself in flash - it's whatever the foreground code (or lower priority interrupt handler) is executing at the time that matters.
If you aren't able to make your entire application copy_to_ram to get rid of the problem entirely, then the usual approach is to dedicate one of the cores to low-latency stuff: make sure that EVERYTHING running on that core (foreground code, data, interrupt handlers) is in RAM, then run everything else (that needs to run from flash) on the other core.
Re your questions:
Q1: in theory the DMA could use a significant amount of bandwidth to one of the RAM blocks and so cut CPU performance by 50% or so (depending on priority settings, instruction mix etc). However, to do that it would have to be doing a continuous RAM-to-RAM copy in the same RAM bank as your code happens to be executing from. That's a pretty unlikely thing to be doing in the first place, and typically the RAM address striping would reduce the impact anyhow. In your case, you are apparently doing only peripheral-paced DMA transfers so the impact on instruction fetch is likely to be minimal.
A related point (not your problem, but while we're on the subject) is that accessing the flash through XIP addresses will stall all of the DMA channels if any one of the stalls on a flash access. This doesn't affect the CPUs, but in a similar way to the discussion above about interrupt handlers, means one DMA channel can have impact on an entirely unrelated channel. Simple answer is to never DMA from XIP flash addresses - if you must DMA from flash for some reason, use the 'streaming DMA interface' instead.
Q2: Very unlikely that A2 vs A4 has any relevance. Much more likely is that you now have the USB connected (even if not actually using it for anything) and so taking 1kHz interrupts. That's likely to perturb the flash cache, change nesting of interrupts etc.
Note that it's not enough to just put your interrupt handler itself in flash - it's whatever the foreground code (or lower priority interrupt handler) is executing at the time that matters.
If you aren't able to make your entire application copy_to_ram to get rid of the problem entirely, then the usual approach is to dedicate one of the cores to low-latency stuff: make sure that EVERYTHING running on that core (foreground code, data, interrupt handlers) is in RAM, then run everything else (that needs to run from flash) on the other core.
Re your questions:
Q1: in theory the DMA could use a significant amount of bandwidth to one of the RAM blocks and so cut CPU performance by 50% or so (depending on priority settings, instruction mix etc). However, to do that it would have to be doing a continuous RAM-to-RAM copy in the same RAM bank as your code happens to be executing from. That's a pretty unlikely thing to be doing in the first place, and typically the RAM address striping would reduce the impact anyhow. In your case, you are apparently doing only peripheral-paced DMA transfers so the impact on instruction fetch is likely to be minimal.
A related point (not your problem, but while we're on the subject) is that accessing the flash through XIP addresses will stall all of the DMA channels if any one of the stalls on a flash access. This doesn't affect the CPUs, but in a similar way to the discussion above about interrupt handlers, means one DMA channel can have impact on an entirely unrelated channel. Simple answer is to never DMA from XIP flash addresses - if you must DMA from flash for some reason, use the 'streaming DMA interface' instead.
Q2: Very unlikely that A2 vs A4 has any relevance. Much more likely is that you now have the USB connected (even if not actually using it for anything) and so taking 1kHz interrupts. That's likely to perturb the flash cache, change nesting of interrupts etc.
Statistics: Posted by arg001 — Wed Dec 10, 2025 8:44 pm