@mjs513 - I think it all has to do with the T4 memory caching stuff... There is stuff in place to try to resolve it.

For example in the ISR for the DMA frame completion, there is a check that if we are going to continue to the next frame it does:
Code:
} else {
		// maybe need to flush cache again
		if ((uint32_t)_pfbtft >= 0x20200000u)  arm_dcache_flush(_pfbtft, CBALLOC);
Which appears to mostly work, the problem is that this is going on, while for example the DMA/SPI stuff is still in a race condition, of which things are going to win...

That is, the ISR fires, when we have completed a frame, at which time, it increments the frame counter, and in the else condition, hopefully flushes stuff to memory, and then returns... The main line code then sees the frame count changed and exceeded some value and does the fillRect or the like that writes the new color out, to the ram...

Now the issue could be that some of these writes to RAM stay in the cache and others make their way through the cache to the actual RAM during that process, so that frame could be part of one and part of the other, but then the next frame it should flush all out and should show up as the new color...

Not sure how to really resolve this? I don't know anyway programmatically to say turn that blinkidy blink cache off for this memory range....

For my type of stuff I don't use the continuous updates, I am more the generate new page, output page....

But if I were doing something like video output or like, I might want some of this structured slightly different. That is I maybe would want to enable more interrupts in the code, and maybe fill sections after each section outputs...

Or if for more general case, I would hate to have to have to change all of the frame buffer code, that when you do each write to memory you either always follow it with the arm_dcache_flush or again keep track of where you are in the outputs...

SO for now I am thinking good enoug