Hi all,

I found a mysterious behavior of the at91sam7s256's SPI port.
When it runs as a slave using PDC, I cant get working the SPI transmit direction reliable (receiver works perfectly).

Example:
*init the SPI as a slave
*initialize a send buffer with 0x30, 0x31,0x32, 0x33, 0x34, 0x35, 0x36 ...
*disable Transmitter / Receiver
*initialize the PDC Transmit Pointer Register with the address of the send buffer and the Transmit Counter Register with the length of this buffer.
*enable transmitter and receiver

Then I receive on the SPI master's side (checked with an ocsilloscope) e.g.:
0x00, 0x30, 0x31, 0x31, 0x33, 0x34, 0x35, 0x35, 0x35, 0x36 ...

The sequence of retransmitted or lost bytes is randomly.

It seems that the PDC doesn't update the transmit register (SPI TDR) correct.
Test patterns, which are received by the slave using PDC at the same time are o.k.
Also the SPI master implementation for this controller (receive and transmit)
is o.k.


Does anybody have an idea?
Can anybody provide an example code for the SPI slave, what works?

Thank you!

Matthias.

Hi all,

now I did SPI slave tests without PDC.

I write the data byte directly to the Transmit Data Register and enable the Transmit Data Register Empty (TDRE) interrupt.
The remote SPI master reads one data byte per second with a speed of about 115 kbps - very slow, to be sure that there is no performance problem.

On the oscilloscope I can see fine signals (slave select, clock and MISO).
But sometimes (randomly) the slaves SPI doesn't trigger the TDRE interrupt when the data byte is shifted out.
That meens it doesn't load the SPI_TDR contents into the shift register.

This is probably a bug in the SPI hardware.

Matthias.

any progress on your work? I am doing similar stuff with an ADC. Wonder if it is the sam chip's problem?

Hi,

I'am using the SAM7S SPI (with PDC, 16 bits per transfer) in slave mode, and have exactly the same behavior here.

Here are my observations : when I prepare a buffer for transmission and enable PDC transmission, in the normal case, the PDC_TCR register immediatly decrease by 1, meaning PDC has writen the first 2 bytes into the serializer. But when the problem occurs, the PDC_TCR register doesn't decrease when I enable PDC. So when the master device starts the transmission, the first 2 bytes transmitted by my slave are incorrect. In fact, those 2 bytes are the last 2 bytes that have been sent into the serializer (during previous transmission). I don't know if that is clear here ... Sorry for my bad english !

Anyone else having the same problem ?

Any work around ?

Any advise would be welcome ! Thanks !

EricL

Hi there,
I have not used the SPI in slave mode yet. However, I did discover a hardware bug in using the SPI with PDC. Basically - you cannot use the FDIV bit - if you do, it breaks the hardware statemachine. Wat you are seeing may be the same bug in slave mode. See here
http://www.at91.com/www/phpBB2_mirror/v ... hp4?t=2171
or if the link does not work, here is the thread name
SPI with PDC and AT91C_SPI_FDIV

Hope this helps

Thank for your post ! But I was not using FDIV... I had already noticed a lot of people having trouble with this.

It was just an electrical problem. I had the internal pull-up resistor enabled, but it seems it was not enough. I disabled them and installed external pull-up and it start working correctly !

EricL

I didn't use FDIV, and disable internal pull-up resistor, setting the PIO_PPUDR. I use 4.7KR to be external pull-up resistor, but this problem happen too. How many R pull-up resistor do you use? My VCC is 3.3V.

I have no idea for the other but the more we dig in SAM7 peripherials the more bugs are coming out

1. the well known reset latch problem (due which Atmel stopped shipping SAM7S128 and SAM7S256)

2. USB engine is mess, the user code and USB engine can read/write in same memory/registers and if user doesn't keep track of who/when/where writes the USB communication will work correctly only from time to time (same thing is made smart in the LPCs where you send your request to the USB engine and only USB engine reads/writes the intern memory/registers)

3. I2C (TWI) interface have undocumented feature - if you are sending your data slow SAM7S will issue automatic STOP

perhaps it's good idea to collect and document these all SAM7S bugs found so far so other peopels who start working not waste their time as we did

Thanks
Tsvetan

I am using it as slave too. Which signal line did you put the pull-up on?

thanks
Andrew

Hello, Matthias, I have used SPI in slave, and fixed your problem. In your master device, if the DLYBCT(Delay Between Consecutive Transfers) in SPI_CSR is long enough to leave time for slave to move new data into SPI_TDR, it will work alright.
In my project, the SPI master is 1Mbps and DLYBCT must > 4.
So leave more time for slave to move new data.