> 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.
Reply by Blue●June 4, 20062006-06-04
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.