[ECOS] AT91 SPI Problems (CS / SPI Modes)
Wed Dec 15 14:02:00 GMT 2010
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
So I guess it's a problem of the PDC... what do you think?
On Mon, Dec 13, 2010 at 04:10:46PM +0100,
> 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
> 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.
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
More information about the Ecos-discuss