This is a follow-up to issues that were posted a few months ago regarding a mismatch between data written to the SN74V293 and data read out from it.
Hopefully the link here will properly redirect to it.
In this application, some of the time the FIFO read clock is being generated by the MCO1 output from a STM32F427.
In this application, MCO1 connects to a 25MHz clock source.
It turns out that MCO1 is extremely badly behaved when selected as the pin output function (but that isn't the primary problem: I'll get to that in a moment). This is how MCO1 appears when the pin is changed from GPIO to MCO1 (blue trace, a couple of examples):
In this application REN (FIFO read enable) was not asserted when MCO1 was selected as a clock, a requirement if PAE is to update synchronously.
Later, REN was asserted to enable the read clocks to update data at the FIFO outputs.
Because REN was asserted by code asycnhronously, the relationship between REN and RCLK was not defined and, although the setup and hold times are very forgiving, there were some occasions when their violation caused erroneous behaviour of the FIFO.
On my 500MHz bandwidth MSO these are a few captures of REN (green trace, marked DB8) and RCLK when operation was subsequently correct:
This is a capture when subsequent operation was incorrect:
So the trace that precedes operation that subsequently failed actually looks as though it's more likely to have met the set up and hold requirements.
I've modified the code so that RCLK comes from a well-behaved source. Also, the clock is stopped before REN is asserted, and then restarted, ensuring that plenty of setup time is allowed.
With those modifications, the disrupted output doesn't occur.
The surprise (to me!) is that the REN and RCLK timing violation causes a perisistent failure of the FIFO's internal read and write registers. The failure only seems to be fixed by issuing a reset.
Possibly a little foolishly I hadn't worried about the setup and hold timing between REN and RCLK because I'd imagined that the outcome would be a missed read event. In this applicaiton that wouldn't have mattered at all.
Going back to the original post, Emrys was almost correct when proposing that a timing problem was causing incorrect data to be stored. In fact, a single incorrect timing violation is causing all subsequent data to be incorrectly retrieved.