AN00160 using_SPI_master and SPI Library 3.0.2 -possible bug

Sub forums for various specialist XMOS applications. e.g. USB audio, motor control and robotics.
User avatar
mon2
XCore Legend
Posts: 1337
Joined: Thu Jun 10, 2010 11:43 am
Contact:

AN00160 using_SPI_master and SPI Library 3.0.2 -possible bug

Postby mon2 » 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:

Image


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:

Image
peter
XCore Addict
Posts: 230
Joined: Wed Mar 10, 2010 12:46 pm

Postby peter » 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
User avatar
mon2
XCore Legend
Posts: 1337
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Postby mon2 » 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.
User avatar
mon2
XCore Legend
Posts: 1337
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Postby mon2 » 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 :)
User avatar
mon2
XCore Legend
Posts: 1337
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Postby mon2 » 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;
    }
}

Who is online

Users browsing this forum: No registered users and 29 guests