Hello, thanks for the answer. Seems this hardware bug has been fixed. We changed the driver for our needs so the CS is now controlled by the SPI core and it works: CS is exactly for the transfer time on low level. But the main problem with the timings is still the same; the time difference between two SPI instructions hasn't changed. Also polled transfers aren't working correctly when the SPI core controls CS. The SPI Slaves are sending the correct data over MISO, but the RX register is all the time 0xFF. If we use the old driver, polled transfers are working and they're much faster than "normal" transfers (but still too long...). So I guess it's a problem of the PDC... what do you think?
Ingo On Mon, Dec 13, 2010 at 04:10:46PM +0100, ingo.kn...@porsche-engineering.de wrote: > Hello all, > > We're having issues with ecos on two identical custom boards with an > AT91SAM7X-512 chip, similar to the AT91SAM7XEK Eval board. Additionaly, > there're MCP2515 CAN Controller and MCP23S08 PortExpander connected via > SPI (six devices at each SPI channel). > Actually it works; we can send and recevice data, we can use different > frequencies (1 to 10MHz) and the interrupts are working as well. But > because of the time critical application the following problem is serious. > > The SPI ChipSelect is too long low for every instruction. The AT91 SPI driver is probably using the CS lines are GPIO pins. The SPI core has a hardware bug where it changes the wrong CS line for devices other than 0. So to get around this hardware bug the AT91 SPI driver controls the CS lines itself. It might be worth reading the errata and see if this has been fixed for the AT91SAM7X. I know it is a problem for the AT91SAM7S. If it has been fixed you can modify the SPI driver to allow the SPI core to control the CS lines. Andrew -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss