What I observe is chaotic SPI communication when using otherwise proven code. What makes this more complicated is this does not seem to happen on every build of the underlying firmware.

The observable issue is that code that worked on a recent micropython build had very stable and predictable SPI communication to an external display. After updating the build to a new version the same code easily because unstable and often does not complete drawing to the display.

After hours of trying to isolate the issue I found it improved when adding a microsecond delay after the CS line was pulled low. Further showing it was SPI related.

Then finally I was able to "resolve" the issue by enabling and disable IRQs at the same time enabled and disabled the CS line. Code now consistently does not have issues, except that it is terrible slow with the IRQ enable and disable combined with the 1us delay on CS pulled low.

This does feel like a compile time decision because the same version of Python produced different results. But because it has been hard to reproduce both working and non-working version hard for me to understand if this is actually the problem.

This issues seems to be related at least in concept
https://github.com/micropython/micropython/issues/1677

This forum post also describes something similar to my issue and some inspiration.
https://forum.micropython.org/viewtopic.php?t=4904

Is this a DMA issue?
Is there a way to work around with without so much manual IRQ enabling/disabling?
Why would I see this only sometimes that new firmware is built?

I was worried that DMA had conflicts but I am only using SPI and CAN as major peripherals. Granted I am using a setup similar to the Pyboard D which uses software serial for external flash being used for the filesystem.