SPI Synchronization Problem

[Altera_Forum]

Hi all, 

I'm establishing SPI communication between a NiosII CPU and an external MCU (ATMEL AT91SAM7S256). I'm using the CycloneIII development kit (EP3C120F780).   A problem seems to arise in the synchronization between the master/slave connection. The data is corrupted almost all the time.  I have tried either CPU to be a master while the other being a slave. The same synchronization problem still exist in both cases.  One more thing, I have tried to test either CPUs individually by connecting the MOSI/MISO together. Each CPU was found to send/receive successfully. That means a correct application software.  Are there any suggestion about this?  Thanks in advance,  A.M.AbdelFattah

[Altera_Forum]

Are both devices using the same clock edge to drive the SPI?

[Altera_Forum]

--- Quote Start ---  Are both devices using the same clock edge to drive the SPI?  --- Quote End ---    YES Both devices have the same clock configuration (active high-send on rising edge).

[Altera_Forum]

OK. 

 I can't remember the details of SPI but is the receive data sampled on the rising or falling edge of the clock? If it is the rising then you may have setup/hold times if the data changes very close to the sampling clock edge. It might be worth seeing if you can ensure the receive data is sampled on the falling edge of the clock.  I apologize if this cannot be done on the Altera core or your Atmel part but I am a bit rusty with SPI  Rgds  Vern

[Altera_Forum]

Hi, 

 SPI interfaces usually have a clock polarity and a clock phase bit (CPOL and CPHA). You have to set these bits to the same values on both sides. The most common mode is to se CPOL=CPHA=0 (in my exerience). If CPOL is low, clock is low when not sending and with CPOL high, the clock is high when in idle. With CPHA low, data is sampled by the receiver on the first edge of each clock pulse (leading edge). With CPHA high, data is sampled on the trailing edge of the clock pulse. In each case, it is best for the master to outpu data on the edge which is not used by the slave for sampling.     You should also set one side as the master and the other side as the slave. Master-Master and Slave-Slave cannot work. The master generates the clock. On the slave side, you may have a nSS signal (active low slave select). If enabled, the nSS must go active (low) before the transfer starts and must remain low for tghe duration of the byte being transferred). On the Atmel AVR's, the nSS signal is optional. I would recommend using it, however since it allows you to synchronize the transfer. Without it, your transfer may loose byte synchronization if you have a noise glitch on the clock line. One other thing to check is whether your clock frequency generated by the master falls within the limits of the slave. Refer to the datasheets.    A last thing to check is that, if you send more than one byte at a time, you do not send them too fast for the slave to read the received byte from its receive buffer. One option is to choose a low enough clock speed so that this is guaranteed (taking into account interrupt latency etc.).    The problem with SPI is that it is very much like an UART - there is no flow control or feedback from the slave to stop the master if it needs time to process data. In that respect I2C is better (but more complex).   Regards, Niki

[Altera_Forum]

Thanks a lot for the replies, 

The problem is nearly solved. I will later add a reply explaining how it is done.