Forums

AT91SAM7S SPI NCPHA Setting Opposite Data Sheet Description?

Started by Blue June 4, 2006
Has anyone here used the SPI port on the AT91SAM7SXXX parts?  If so, have 
you observed the same problem I have?

It appears to me that the edge used to capture data is reversed from what 
the data sheet shows.  I am using CPOL=0, NCPHA=1.  According to the data 
sheet, this should cause the SPI clock to idle low, and to capture MISO data 
on rising clock edges, including the first rising edge.

On my scope I can see that the data is clearly low for the first rising edge 
of the clock, with plenty of room for both the setup and hold times on each 
side of the edge.  It is also low for several other rising edges, during the 
16-bit transfer.  The data is high immediately before each falling edge. 
The data received in response to this transfer has all 16 bits being '1'.

When I then set NCPHA=0 (still with CPOL=0) for exactly the same transfer, I 
then get data that makes sense, and agrees with what I am seeing on my 
scope.  However, this behavior would be completely opposite both the 
waveform charts in section 29.6.2 of the data sheet, and the descriptions of 
CPOL and NCPHA in section 29.7.9.

I have scoured Atmel's web site and searched many other places on the web, 
and have found no mention of this. 


"Blue" <xxx@do_not_spam_me.net> wrote:
> Has anyone here used the SPI port on the AT91SAM7SXXX parts? If so, have > you observed the same problem I have? > > It appears to me that the edge used to capture data is reversed from what > the data sheet shows. I am using CPOL=0, NCPHA=1. According to the data > sheet, this should cause the SPI clock to idle low, and to capture MISO > data on rising clock edges, including the first rising edge. > > On my scope I can see that the data is clearly low for the first rising > edge of the clock, with plenty of room for both the setup and hold times > on each side of the edge. It is also low for several other rising edges, > during the 16-bit transfer. The data is high immediately before each > falling edge. The data received in response to this transfer has all 16 > bits being '1'. > > When I then set NCPHA=0 (still with CPOL=0) for exactly the same transfer, > I then get data that makes sense, and agrees with what I am seeing on my > scope. However, this behavior would be completely opposite both the > waveform charts in section 29.6.2 of the data sheet, and the descriptions > of CPOL and NCPHA in section 29.7.9. > > I have scoured Atmel's web site and searched many other places on the web, > and have found no mention of this. >
A follow up to this issue... I found that the NCPHA setting works correctly for sending data on MOSI. However, when I want to receive data, NCPHA is reversed, as described. This is a nuissance because if I am using a device which you must first send a command to, and then read back data from, I must now switch NCPHA between sending and receiving.