--- Quote Start ---
With a 8 MHz MCU, I guess the time between CS_U1 going down up and CS_U2 going will probably be several times 125 ns. So, plenty of time to meet setup time.
And since you're not changing the values right after U2 samples them, plenty of time to meet hold time.
Really, don't see why it's failing occasionally.
That said..
- U2 samples PI at the rising edge of clk.. when CS_sync is '1', not CS. So, it's happening 2 clocks later. You probably have something similar in U1, so it evens out. But best keep it in mind.
- The signal can take some time from U1 setting it and becoming stable at U2's inputs, because of the pull-up scheme, connection cable, etc. I've seen pull-up schemes being unexpectedly slow, so this would be my first guess.
- Since there are two different boards, the clocks at U1 and U2 won't be in perfect phase and this may work against you too.
Try to draw a timing diagram of the signals involved, it's usually worth the trouble.
Try measuring the delay between the rising edge of U2's clock and PI[*] reaching a stable value.
Try to get a min/max range for some of the 72 signals.
This will be the min/max input delays you should to set on PI, by the way.
Other nice things to measure may be the phase between U1's clock and U2's clock; and the time between U1's CS and U2's CS.
--- Quote End ---
If I remember correctly, the rising time of P[*] was a hundred or so ns long due to the 1K pull up. If the timing between U1's CS and U2's CS is too close, the simplest solution would be to just put a delay of a uS between them. Very easy in an AVR.
The boards are the same i.e U1 and U2 are on the same board and share the same clock. Because this is just internal equipment we didn't care much about aesthetics - the wires just connect at one end, wrap around and connect on the other end. However, the board has the capability to be extended i.e. there's another board which only has CPLDs and no MCU. This board connects via ribbon cable to the 'main' board. Interestingly, the data transmission between the MCU and the CPLDs that are on same board as the MCU is always OK. I have, so far, never seen a bad data transfer between them.
However, the other boards, which connect via the ribbon cause the issues. But as I said, even that was reduced drastically to be 1 in 10,000 data transfers now. The only difference is that the SCK, CS, SO and SI travel quite a bit more but at just 2 MHz (and 7 ns rise times) one would think that signal integrity wouldn't be an issue. The overshoot on these signals is 1.3 V but it settles quickly and there is no ringing. Perhaps I should slow down these signals even further?
The system works great if SCK is 1 MHz, by the way. No bad transfers.
Honored Contributor
