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

AN00160 using_SPI_master and SPI Library 3.0.2 -possible bug

Post by mon2 »

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

Post by peter »

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: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

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: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

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: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

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;
    }
}
User avatar
bear118
Active Member
Posts: 37
Joined: Wed Jan 09, 2019 10:57 am

Post by bear118 »

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
Post Reply