AT91SAM7X512 SPI malfunctions - gets disabled on write to SPI_TDR.

Configurations are (Defined in the order of writing):

1. SPI_MR (SPI Mode Register):
   
   • MSTR: Master mode
     
   • PS: Fixed Perhipheral Select
     
   • PCSDEC: The chip selects are directly connected to a peripheral device.
     
   • PCS: Peripheral Chip Select = 0111 (NPCS[3:0] = 0111)
     
   • DLYBCS: Delay Between Chip Selects = 0
     
2. SPI_CSR[3] (SPI Chip Select Register):
   
   • CPOL: Clock Polarity = 0 (The inactive state value of SPCK is logic level zero.)
     
   • NCPHA: Clock Phase = 1 (Data is captured on the leading edge of SPCK and changed on the following edge of SPCK.)
     
   • CSAAT: Chip Select Active After Transfer = 0 (The Peripheral Chip Select Line rises as soon as the last transfer is achieved.)
     
   • BITS: Bits Per Transfer = 0000 (8 bits)
     
   • SCBR: Serial Clock Baud Rate = 20
     
   • DLYBS: Delay Before SPCK = 0
     
   • DLYBCT: Delay Between Consecutive Transfers = 0
     
3. SPI_CR (SPI Control Register):
   
   • SPIEN = 1 (Enables the SPI to transfer and receive data.)
     

After the configurations, the code verifies that the SPI is enabled, by checking the SPIENS bit in SPI_SR (SPI Status Register).
All the communication is done with the SPI functions that were supplied by ATMEL. (source file attached)

I noticed that if I put a delay before the write to the SPI_TDR register, then the code works perfectly and the communications succeeds.
But if not, then the SPI gets disabled (as I can see by watching at the SPIENS bit in SPI_SR), which makes the while() loop (that checks the TDRE bit of the SPI_SR in the SPI_Write() function) to iterate itself indefinitely.
The amount of delay depends on the value of the SCBR register: if SCBR has a big value, then a big delay is required. A small value of SCBR requires a small delay.

Also please note that the NPCS line num. 3 is a GPIO line, and is not controlled by the SPI controller.
I'm controlling this line by myself in the code, by de/asserting the ChipSelect#3 (NPCS3) pin when needed.
The reason that I'm doing so is because that problems occurred while trying to let the SPI controller to control this pin.

Any ideas what's causing the problem?

Attachments:

• Attachment:
  File comment: Includes SPI.c and SPI.h
  SAM7X_SPI_Files.rar [3.71 KiB]
  Downloaded 55 times
  
• AT91SAM7X Series Preliminary.pdf (directly from atmel.com)

Thank you!

Regards,
Dor.

No one experienced this before?
Maybe someone can give me an example of how to configure the SPI interface? Thank you!

Are you calling SPI_Read() after each SPI_Write()?

Also I believe SPIENS is only valid for Slave operation so if you are operating in master mode you probably do not want to check this bit.

See 28.6.3.1 Master Mode Block Diagram

Sorry but I can't see the code right now and I'll be able to read it in about two weeks. But I'll try to answer:


As far as I remember - Yes.


I mistakenly believed otherwise, thanks!

I'll check that out!

Thanks!