We are witnessing instabilities while using the Sitara AM3894. For the sake of clarity, I will mention the "good_board" and a "bad_board".
The major difference between those 2 boards is the length of the traces between the GPMC and the FPGA (~80mm but poorly matched on the good_board and 100mm on the bad one)
I will bound my description on one failure mode, at 62MHz of this interface. We have different setups with other failure modes, but this one is the easiest to communicate.
The technical description is as follow:
The problem is around the GPMC. Our GPMC settings are the following for the ChipSelect0 device:
GPMC_CONFIG1 = 0x28601011 # general config
GPMC_CONFIG2 = 0x00020300 # CS# timings
GPMC_CONFIG3 = 0x00010200 # ALE timings
GPMC_CONFIG4 = 0x01000201 # WE# and OE#
GPMC_CONFIG5 = 0x00020304 # cycle time
GPMC_CONFIG6 = 0x00000000 # intercycles time
The test consists in writing a check pattern (0xaaaa5555) through the GPMC to our external FPGA.
On the good_board if have the attached "good_wf.jpg" access waveform for the write accesses.
On the the bad_board, I have the attached "bad_wf.jpg" access waveform for the write accesses, which as you see is missing the second halfword...
These waveforms are captured using a free running 375MHz clock on the FPGA side, much like a "Timing acquisition" logic analyzer would do it.
So the problem seems to be a failure of the control mechanism of the GPMC.
From the initial analysis I have made, the only reasonable source of discrepancy is a timing mismatch on the WAITN pin. But as you can see on the waveforms WAITN is stuck at one, and furthermore how can it propagate as a control error in the GPMC ?
I think I will need help to clarify that, and to quantify the timing budget on this interface.
The TI references are:
Our device_ID in both case is
0x48140600: 0x1B81E02F (silicon rev1.1)
