using xflash -spi-spec with several types of flash Topic is solved

[cl-b]

Hello,

I have a question about the xflash command. Potentially we risk having 2 flash equivalent in size that can be mounted according to their disponibility at the time of manufacture.
I can use

xflash --spi-spec <flash spec file>

and I wonder if I can define the 2 flashes structures in the same file (one after the other) and if I can include the 2 IDs in the xn file of the project

Code: Select all

          <Boot>
            <Source Location="SPI:bootFlash1"/>
            <Source Location="SPI:bootFlash2"/>
          </Boot>
....
    <Device NodeId="0" Tile="0" Name="bootFlash1" Class="SPIFlash" Type="AT25DF16">
    <Device NodeId="0" Tile="0" Name="bootFlash2" Class="SPIFlash" Type="W25Q16">

flash spec file

Code: Select all

    50,                      /* libflash device ID */
    256,                    /* page size */ 
    8192,                   /* num pages */ 
    3,                      /* address size */ 
    8,                      /* log2 clock divider */ 
    0x9f,                   /* SPI_RDID */ 
    0,                      /* id dummy bytes */ 
    3,                      /* id size in bytes */ 
    0xEF4015,               /* device id */ 
    0x20,                   /* SPI_SE */ 
    0,                      /* full sector erase */ 
    0x06,                   /* SPI_WREN */ 
    0x04,                   /* SPI_WRDI */ 
    PROT_TYPE_SR,           /* SR protection */ 
    {{0x1c,0x0},{0,0}},     /* no values */ 
    0x02,                   /* SPI_PP */ 
    0x0b,                   /* SPI_READFAST */ 
    1,                      /* 1 read dummy byte */ 
    SECTOR_LAYOUT_REGULAR,  /* sane sectors */ 
    {4096,{0,{0}}},         /* regular sector size */ 
    0x05,                   /* SPI_RDSR */ 
    0x01,                   /* SPI_WRSR */ 
    0x01,                   /* SPI_WIP_BIT_MASK */ 

    51,                        /* libflash device ID */
    256,                    /* page size */
    8192,                   /* num pages */ 
    3,                      /* address size */ 
    8,                      /* log2 clock divider */\
    0x9f,                   /* SPI_RDID */
    0,                      /* id dummy bytes */ 
    3,                      /* id size in bytes */ 
    0x1F8601,               /* device id */ 
    0xD8,                   /* SPI_SE */ 
    0,                      /* full sector erase */
    0x06,                   /* SPI_WREN */ 
    0x04,                   /* SPI_WRDI */ 
    PROT_TYPE_SR,           /* SR protection */ 
    {{0x1c,0x0},{0,0}},     /* no values */ 
    0x02,                   /* SPI_PP */ 
    0x0b,                   /* SPI_READFAST */ 
    1,                      /* 1 read dummy byte */ 
    SECTOR_LAYOUT_REGULAR,  /* sane sectors */ 
    {65536,{0,{0}}},        /* regular sector size */ 
    0x05,                   /* SPI_RDSR */ 
    0x01,                   /* SPI_WRSR */ 
    0x01,                   /* SPI_WIP_BIT_MASK */ 
}

Claire

[Redeye]

Good question - we've been doing exactly this for a couple of years but I'd completely forgotten that the flash type was specified in the XN file!!

So, I'd conclude that the Type="" part in the XN file is ignored. I've just tried removing this from our XN file and it compiles fine, so that seems to confirm that theory. So I think all you need in the XN file is :

Code: Select all

<Device NodeId="0" Tile="0" Name="bootFlash" Class="SPIFlash" >

You need the 2 different flash spec files, then just use the --spi-spec argument with the appropriate file when you program using xflash.

If you're using libflash in your code, don't forget to include both flash spec files, then libflash will automatically figure out which one is fitted so you can do firmware upgrades and write to flash without needing to know.

We've been doing this for a couple of years - we've shipped the same board with different flashes fitted running the same firmware with no problems at all.

[cl-b]

Many thanks for your explanations.

It would be grate if someone from XMOS can confirm that Type="" in XN file is ignored