XCore Exchange

Posted: **Thu Nov 10, 2016 12:13 am**

Hi. Developing some code to R/W to standard SPI flash memory and then wish to expand onto QSPI modes and running into some issues.

Using AN00160 as the foundation with SPI Library 3.0.2, run the default program @ 100khz in SPI_MODE_1 - works fine according to the attached Total Phase Beagle SPI bus analyzer (sampling rate @ 50 Mhz; 10 Mhz also reports the same data). See below.

Same test with SPI_MODE_0 - does NOT work correctly. We recall this observation back in 2014.

Can someone confirm that SPI_MODE_0 works correctly or is this a code or Beagle tool bug ?

Will test the same code run using a different SPI bus analyzer (Zeroplus) later this week to confirm the issue is not Beagle tool related. Welcome all comments.

SPI_MODE_1 code run from AN00160:

Code: Select all

/* This application function sends some traffic as SPI master using
 * the synchronous interface. Since this is run in simulation
 * there is no slave, so the incoming data (stored in the 'val'
 * variable) will just be zero.
 */
void app(client spi_master_if spi)
{
    uint8_t val;
    printstrln("Sending SPI traffic");
    delay_microseconds(30);
    spi.begin_transaction(0, 100, SPI_MODE_1);
    val = spi.transfer8(0x11);
    val = spi.transfer8(0x22);
    val = spi.transfer32(0x33445566);
    val = spi.transfer8(0x77);
    spi.end_transaction(100);

    delay_microseconds(40);
    spi.begin_transaction(0, 100, SPI_MODE_1);
    val = spi.transfer8(0x22);
    spi.end_transaction(100);

    printstrln("Done.");
    _exit(0);
}

Results as captured by the Beagle tool:

SPI_MODE_0 code run from AN00160:

Code: Select all

/* This application function sends some traffic as SPI master using
 * the synchronous interface. Since this is run in simulation
 * there is no slave, so the incoming data (stored in the 'val'
 * variable) will just be zero.
 */
void app(client spi_master_if spi)
{
    uint8_t val;
    printstrln("Sending SPI traffic");
    delay_microseconds(30);
    spi.begin_transaction(0, 100, SPI_MODE_0);
    val = spi.transfer8(0x11);
    val = spi.transfer8(0x22);
    val = spi.transfer32(0x33445566);
    val = spi.transfer8(0x77);
    spi.end_transaction(100);

    delay_microseconds(40);
    spi.begin_transaction(0, 100, SPI_MODE_0);
    val = spi.transfer8(0x22);
    spi.end_transaction(100);

    printstrln("Done.");
    _exit(0);
}

Results as captured by the Beagle tool:

Posted: **Thu Nov 10, 2016 10:21 am**

Hi mon2,

Unfortunately this is a known issue with the SPI library that we have not yet had time to resolve:

https://github.com/xmos/lib_spi/issues/8

Are you able to stick with MODE_1?

Regards,

Peter

Posted: **Thu Nov 10, 2016 11:51 am**

Thanks Peter. From our observations while using the Beagle tool,

XMOS SPI_MODE_0 ; is not working correctly but is actually SPI_MODE_1

XMOS SPI_MODE_1 ; is working correctly but is actually SPI_MODE_0

This is slowly reminding us of our testing conducted a few years ago in that we believe that the supplied XMOS code was actually operating in SPI_MODE_0 when the SPI_MODE_1 mode is selected and vice-versa.

Our target is standard SPI serial flash and we recall that working fine once the above relationship is understood.

Summary, we may be just fine to use 'SPI_MODE_1' which is actually SPI_MODE_0 for our immediate requirement.

The confirmation was with:

a) that the SPI memory worked (a few years ago) using XMOS code as 'SPI_MODE_1'
b) that the bus analyzer framed the 'SPI_MODE_1' packets fine as-is but in SPI_MODE_0 (on the Beagle tool setting).

Will review in detail today and post comments to close this raised issue.

Thanks again and bye for now.

Posted: **Thu Nov 10, 2016 12:07 pm**

Aha ! Just found this...

https://github.com/xmos/lib_spi/issues/11

So far, we agree with this comment. Will investigate further. Our coffee does still work :)

Posted: **Thu Nov 10, 2016 12:59 pm**

Not tested but see some red flags here:

https://github.com/xmos/lib_spi/blob/ma ... pi_sync.xc

Lines 225-232

Code: Select all

static void get_mode_bits(spi_mode_t mode, unsigned &cpol, unsigned &cpha){
    switch(mode){
        case SPI_MODE_0:cpol = 0; cpha= 1; break;
        case SPI_MODE_1:cpol = 0; cpha= 0; break;
        case SPI_MODE_2:cpol = 1; cpha= 0; break;
        case SPI_MODE_3:cpol = 1; cpha= 1; break;
    }
}

believe this should be:

Code: Select all

static void get_mode_bits(spi_mode_t mode, unsigned &cpol, unsigned &cpha){
    switch(mode){
        case SPI_MODE_0:cpol = 0; cpha= 0; break;
        case SPI_MODE_1:cpol = 0; cpha= 1; break;
        case SPI_MODE_2:cpol = 1; cpha= 0; break;
        case SPI_MODE_3:cpol = 1; cpha= 1; break;
    }
}

Posted: **Tue Apr 16, 2019 6:24 am**

mon2 wrote:Not tested but see some red flags here:

https://github.com/xmos/lib_spi/blob/ma ... pi_sync.xc

Lines 225-232

Code: Select all

static void get_mode_bits(spi_mode_t mode, unsigned &cpol, unsigned &cpha){
    switch(mode){
        case SPI_MODE_0:cpol = 0; cpha= 1; break;
        case SPI_MODE_1:cpol = 0; cpha= 0; break;
        case SPI_MODE_2:cpol = 1; cpha= 0; break;
        case SPI_MODE_3:cpol = 1; cpha= 1; break;
    }
}

believe this should be:

Code: Select all

static void get_mode_bits(spi_mode_t mode, unsigned &cpol, unsigned &cpha){
    switch(mode){
        case SPI_MODE_0:cpol = 0; cpha= 0; break;
        case SPI_MODE_1:cpol = 0; cpha= 1; break;
        case SPI_MODE_2:cpol = 1; cpha= 0; break;
        case SPI_MODE_3:cpol = 1; cpha= 1; break;
    }
}

Good job！
thx

XCore Exchange

AN00160 using_SPI_master and SPI Library 3.0.2 -possible bug

AN00160 using_SPI_master and SPI Library 3.0.2 -possible bug

Re: AN00160 using_SPI_master and SPI Library 3.0.2 -possible

Re: AN00160 using_SPI_master and SPI Library 3.0.2 -possible

Re: AN00160 using_SPI_master and SPI Library 3.0.2 -possible

Re: AN00160 using_SPI_master and SPI Library 3.0.2 -possible

Re: AN00160 using_SPI_master and SPI Library 3.0.2 -possible