[ECOS] [ecos] AT91 SPI Problems (CS / SPI Modes)

[ECOS] [ecos] AT91 SPI Problems (CS / SPI Modes)

[Ingo.Knuth]

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. On the first 
board for around 60µs, on the second one between 300 and 400µs; the data 
consist just of 2-13 bytes and they're sent in a couple of µs, depending 
on the SPI frequency. The difference between the falling slope of CS and 
the start of the clock signal: 
- Board1: 10µs, so CS is after stopping the clock and transmitting the 
data for another 50µs low.
- Board2: 50µs, and 250-350µs low level afterwards.

The second issue: There's also a problem with the supported SPI Modes of 
the MCP2515. It should work with 1-1 and 0-0 (Polarity-Phase), but we have 
to use on both boards 1-0. 

Anyone who made the same experience or has an idea what the reason could 
be? Is it a general ecos driver problem?


There are no major changes in the ecos configuration from the default 
config, using the template for Atmel AT91SAM7XEK eval board.

Our SPI device configuration for the MCP2515:
Header:
#define MCP2515_CL_POL 1                        ///< Clock polarity (0 or 
1) - experiential determined. POL-PHA: 1-1 0-0 doesn't work
#define MCP2515_CL_PHA 0                ///< Clock phase (0 or 1)
#define MCP2515_CL_BRATE 10000000       ///< Clock baud rate - 10 MHz 
#define MCP2515_CS_UP_UDLY 1        ///< Delay in usec between CS up and 
transfer start
#define MCP2515_CS_DW_UDLY 1        ///< Delay in usec between transfer 
end and CS down
#define MCP2515_TR_BT_UDLY 1        ///< Delay in usec between two 
transfers

cyg_spi_device* p_cyg_spi0_dev1;

C-File:
cyg_spi_at91_device_t spi0_dev1 CYG_SPI_DEVICE_ON_BUS(0) =
{
    .spi_device.spi_bus = &cyg_spi_at91_bus0.spi_bus,

    .dev_num     = 1,                                   // Device number
    .cl_pol      = MCP2515_CL_POL,              // Clock polarity (0 or 1)
    .cl_pha      = MCP2515_CL_PHA,              // Clock phase (0 or 1)
    .cl_brate    = MCP2515_CL_BRATE,            // Clock baud rate - 1MHz
    .cs_up_udly  = MCP2515_CS_UP_UDLY,      // Delay in usec between CS up 
and transfer start
    .cs_dw_udly  = MCP2515_CS_DW_UDLY,      // Delay in usec between 
transfer end and CS down
    .tr_bt_udly  = MCP2515_TR_BT_UDLY       // Delay in usec between two 
transfers
};
cyg_spi_device* p_cyg_spi0_dev1 = &spi0_dev1.spi_device;

A sample SPI Instruction:
cyg_uint8 mcp_read_register(cyg_spi_device* p_dev, cyg_uint8 u_reg)
{
        cyg_uint8 rx_data[3];
        const cyg_uint8 tx_data[2] = {SPI_READ, u_reg}; // Instruction 
Byte + Address
        cyg_spi_transfer(p_dev, 0, 3, tx_data, rx_data);
        return rx_data[2];
}


Kind regards,
Ingo

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] [ecos] AT91 SPI Problems (CS / SPI Modes)

[Andrew Lunn]

On Mon, Dec 13, 2010 at 04:10:46PM +0100, Ingo.Knuth@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