The nRF52840 from Nordic Semi has an issue with SPIM3, in that using it with a shared memory buffer could lead to data corruption (Erratum 198). The description describes a simultaneous access from CPU and DMA on the same RAM block as the cause, but after some testing I believe the explanation to be insufficient. The problem seems to only occur with the first byte transmitted, and then it is not corrupted, it is not loaded at all and the SPIM uses the last byte from the last transaction instead. My theory is that the DMA needs to feed two bytes at the start, and that it does not wait for the first transaction to finish before starting the DMA clock. So the first load has no tolerance to retrieve its data before the read for the second byte is issued, which also aborts the first read. On the other hand SPIM0-2 seem to wait: only after the first byte has been read will the module start with transmission, and the DMA start issuing reads for the following bytes. For all following bytes I assume that the read has, on all SPIM, at least half the byte time to get filled.
The best support for this thesis is that when we arrange for SPIM0 to SPIM2 to start at the same time, we see that with contention the times differ, while without they line up nicely.
It looks like it is only the CPU that can lead to corruption, at least a test with the 3 other SPIM could not cause an issue. This is surprising given that all other AHB Masters have higher priority than SPIM3, and so could cause a critical delay. Peripherals however work at 1/4th the speed of the CPU and RAM, and so I guess it needs more than four masters to saturate the bus.