Oh gosh! Sorry I overlooked that in the general confusion of losing my code.ijor wrote: 16 Aug 2024 18:41Hi Dave,Badwolf wrote: 16 Aug 2024 10:39 It seems that the blitter drives the data quite early during a write and doesn't hold it very long.
As I said in my previous message, I'm not sure that is the problem. Unless you changed the code, it seems the problem is the opposite, your SDRAM controller is too fast.
As I mentioned in my previous message, your "ACTIVE" logic at the DRAM controller is level triggered. And since you are too fast for Blitter, you start a second SDRAM write access. I performed a quick simulation. This is the simulation waveform:
I have changed the code (I found the old code -- hurrah! -- I simply don't know how to use git properly). But I think I was seeing the same problem and the active signal remains level driven.
The current code is here -> https://github.com/dh219/DSTB/tree/altramwork2
At one point in the codebase it was impossible to get back to STATE_IDLE until DS were deasserted, so I thought ACTIVE was safe, but I see I've tried to shortcut things in an effort to speed the process up that I've allowed it to return to IDLE early on a write now -- your theory certainly fits!
I did find another similar bug recently where it was going around the cycle twice, but that was an error in the DTACK logic at the time.
I'll give it another look.
Many thanks for the analysis!
BW