Search

Technical Discussion Group Forum

This forum is provided for user discussion. While Logic PD support staff and engineers participate, Logic PD does not guarantee the accuracy of all information within in the Technical Discussion Group (TDG).

The "Articles" forums provide brief Articles written by Logic PD engineers that address the most frequently asked technical questions.

To receive email notifications when updates are posted for a Logic PD product download, please subscribe to the TDG Forum of interest.

PrevPrev Go to previous topic
NextNext Go to next topic
Last Post 10 Mar 2008 03:19 PM by  Badguy
Auxillary GPIO ports using SPI
 2 Replies
Sort:
You are not authorized to post a reply.
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
    You are not authorized to post a reply.