SPI Asynchronous Master - MODE_0 works, MODE_1 doesn't

[ahenshaw]

I have my interface to an LCD panel working fine with the Synchronous Master SPI library, but I wanted to try for more speed by using the Async library. Unfortunately, I'm having difficulty. It appears that the MODE_1 transfers are getting screwed up and I don't know why. MODE_0 seems to produce the proper results, but my LCD device needs MODE_1.

Here's the relevant code:

Code: Select all

extends client interface spi_master_async_if  : {

    uint8_t transfer8(client spi_master_async_if self, uint8_t data)
    {
        uint8_t data_in;
        uint8_t * movable buffer_in  = &data_in;
        uint8_t * movable buffer_out = &data;

        self.begin_transaction(DEVICE_ID, SPI_SPEED, SPI_MODE_1);
        self.init_transfer_array_8(move(buffer_in), move(buffer_out), 1);
        select {
            case self.transfer_complete():
                self.retrieve_transfer_buffers_8(buffer_in, buffer_out);
                break;
        }
        self.end_transaction(SPI_DELAY);
        return *buffer_in;
    }
}

When I send 0x00, 0x13, 0x24, I get the output shown in the attached VCD trace (MODE_1.png), which is clearly wrong. If I just change the SPI_MODE to SPI_MODE_0, the output is exactly correct (MODE_0.png).

[ahenshaw]

Responding to myself: MODE_3 also works, which should allow me to drive the display properly (but not read).

Also, MODE_2 doesn't work. I'm guessing that the problem is in this bit of code in the SPI library (function init_init_transfer_array_8):

Code: Select all

    if((active_mode == SPI_MODE_1 || active_mode == SPI_MODE_2) && (!isnull(mosi))){
            unsigned b = data>>7;
            asm volatile ("setclk res[%0], %1"::"r"(mosi), "r"(XS1_CLKBLK_REF));
            partout(mosi, 1, b);
            asm volatile ("setclk res[%0], %1"::"r"(mosi), "r"(cb1));
            data = data<<1; //This is shifted up as the MSB is already on this pin
    }

Still, I would like to be able to operate in MODE_1.

[ahenshaw]

Well, I was hoping that my question would have gotten some response from XMOS, by now.

I do, however, have another observation. If I transfer two or more bytes in SPI_MODE_1 or SPI_MODE_2, then only the first byte seems to be corrupted. Again, as before, SPI_MODE_0 and SPI_MODE_3 work correctly, but I need SPI_MODE_1.

[Ross]

I've had a quick look over the code, inspection only at this point im afraid.

The code writes 0xffffffff to MOSI port at startup, this doesn't seem quite right - some of this data is still left in the port by the looks of it - can you try removing this output (and also the previous if)

[ahenshaw]

Unfortunately, that doesn't fix it.

I've attached a minimal program that demonstrates the problem. If you change the #define SPI_MODE at the top of the program from SPI_MODE_0 to SPI_MODE_1, the MOSI output waveform is no longer correct. I can't discern a pattern, except that the first byte of a transaction is always wrong.

SPI_MODE_0 works fine.

[Ross]

Can i ask you to raise this as an issue here please? https://github.com/xmos/lib_spi

[ahenshaw]

Done.

[ahenshaw]

Any progress on this? My project is at a standstill, right now.

Apparently the unit tests for this library only include tests for MODE_0 and MODE_3. This makes sense, since those are the only two modes that work -- MODE_1 and MODE_2 do not.

[cschopges]

Hello,

I'm having the same problem. Any idea how this can be fixed? :)