Go to previous topic
Go to next topic
Last Post 10 Mar 2008 03:19 PM by  Badguy
Auxillary GPIO ports using SPI
 2 Replies
Author Messages
sygi@canbus.pl
New Member
New Member
Posts:


--
16 Nov 2007 04:18 AM
    Hi

    I writing an additional GPIO driver based on the mcp23s17 SPI chip.
    I have problems with the spi_write_then_read() function. The returned value is dummy (0xFF or 0x00).
    I tried different values ".del_cs_to_clk" and ".del_after_trans" in the chip structure, without results. I checked signals on the SPI bus using oscilloscope and they are correct.
    The spi_write() function work very good.

    I think it is software problem.

    Here is my function form the driver module:

    static u8 expander_read(u8 addr, u8 data)
    {
    u16 spi_word;
    u8 result;
    s8 retval;

    if (gpio_device==NULL || gpio_device->spi==NULL)
    return -ENODEV;

    spi_word = ((addr&0xFF)<<8)|(data&0xFF);

    #ifdef MCP23S17_DEBUG
    printk("m5329gpio data write before read -> 0x%x\n", spi_word);
    #endif
    retval = spi_write_then_read(gpio_device->spi, (u8*)&spi_word, 2, &result, 1); // 3 bytes -> 24 bits [opcode][reg_addr] [read reg_data]

    #ifdef MCP23S17_DEBUG
    printk("spi_write_then_read status -> %d\n", retval);
    #endif
    if (retval < 0) {
    #ifdef MCP23S17_DEBUG
    printk("m5329gpio spi_write_then_read error -> %d\n", retval);
    #endif
    }
    #ifdef MCP23S17_DEBUG
    printk("m5329gpio data read -> 0x%x\n", result);
    #endif
    return result;
    }


    Any suggestions ??

    Regards
    sygi@canbus.pl
    New Member
    New Member
    Posts:


    --
    15 Jan 2008 01:24 AM
    Hi
    I've figured out (on oscilloscope) that the SPI driver changes CS signal (set inactive for a while) during read sequence (after success opcode and register address transmission). That causes connection problem with the chip.
    I tried to change some code in the SPI driver but without results.
    For example cs_change flag value in the spi_write_then_read function.

    Does anyone can give me any hint where to look for the part of code responsible for this ??

    Regards
    Badguy
    New Member
    New Member
    Posts:


    --
    10 Mar 2008 03:19 PM
    Hello sygi,

    I am currently seeing the exact same behaviour.

    and I have boiled it down to a few small areas.
    but I am still perplexed.

    cs_change is not causing it, as far as the linux code goes, the support is there for this behaviour.
    assert a cs during transfer, but it is currently not responsible.

    in other words cs_change is not set, thus not performing a chip select assertion during transfer.

    Someone else is.

    Also I have verified that the control register does not contain the bit MXC_CSPICTRL_SSCTL
    (when I look at it) I feel I am perhaps viewing the register contents at the wrong time.

    I am looking into this, but running out of options.
    still just a beginner here.

    If anyone has any ideas for me to look at, or anything at all I would be most grateful

    Thanks


    ---