Vybrid MQX interfacing QSPI1

[tfe]

I am attempting to access QSPI1 on my twrvf610gs10 development kit running MQX 4.0.1.

After searching through the BSP, I have found that the IOMUX is not set for this device, neither is the chip settings in "init_qspi.c".

I have tried to copy the settings from QSPI0_A in SDR-mode, neglecting QSPI0_B since it doesn't exist. As a result, I have nulled QSPI1_A1, QSPI1_B0 and QSPI1_B1 devices (see "_bsp_quadspi1_flash_device" below) in the same fashion as with the existing QSPI0 device.

I ahve also added the "BSPCFG_ENABLE_QUADSPI1" flag to "user_config.g", and added the following lines to "_bsp_init(void)" in "init_bsp.c":

#if BSPCFG_ENABLE_QUADSPI1 && !BSPCFG_ENABLE_FLASHX_QUADSPI1

    _io_qspi_install("qspi1:", &_bsp_quadspi1_init);

#endif

My question is: What am I doing wrong? Are there any special considerations I have to make when accessing QSPI1?

**************************** C-Code ****************************

static QuadSPI_FLASH_INFO_STRUCT _bsp_quadspi1_flash_device[] = {

  {

  0, /** Start address */

  64, /** Number of sectors */

  0x40000 /** Sector size */

  }, {

  0x1000000, /** Start address */

  0, /** Number of sectors */

  0 /** Sector size */

  }, {

  0x1000000, /** Start address */

  0, /** Number of sectors */

  0 /** Sector size */

  }, {

  0x1000000, /** Start address */

  0, /** Number of sectors */

  0 /** Sector size */

  }

};

static QuadSPI_FLASH_CMD_STRUCT _bsp_quadspi1_flash_cmd =

{

    .READ_CMD = {0x0403, 0x0818, 0x1c80},

    .DUAL_READ_CMD = {0x04BB, 0x0918, 0x0D04, 0x1D80},

    .QUAD_READ_CMD = {0x04EB, 0x0A18, 0x0E06, 0x1E80},

    .DDR_READ_CMD = {0x040D, 0x2818, 0x2CFF, 0x0C02, 0x3880},

    .DDR_DUAL_READ_CMD = {0x04BD, 0x2918, 0x2DFF, 0x0C04, 0x3980},

    .DDR_QUAD_READ_CMD = {0x04ED, 0x2A18, 0x30FF, 0x0E06, 0x3A80},

};

static const QuadSPI_INIT_STRUCT _bsp_quadspi1_init_data = {

    1,                                  /* QSPI controller id */

    QuadSPI_CLK_SDR_MODE,               /* Clock Mode */

    QuadSPI_SINGLE_MODE,                /* IO Mode */

    33000000,                           /* Serial Clock: Read */

    33000000,                           /* Serial Clock: Write */

    QuadSPI_PAGE_256,                   /* Page size */

    _bsp_quadspi1_flash_device,         /* flash device information */

    &_bsp_quadspi1_flash_cmd,           /* flash command */

    FALSE,                              /* Parallel mode */

    3,                                  /* flash CS hold time */

    3,                                  /* flash CS setup time */

};

const QSPI_INIT_STRUCT _bsp_quadspi1_init = {

    &_qspi_quadspi_devif,               /* Low level driver interface */

    &_bsp_quadspi1_init_data,           /* Low level driver init data */

};

************************** C-Code end **************************

[tfe · Accepted solution]

The problem appeared to be hardware related. Once fixed, the GPIO configuration proved correct.

[alejandrolozan1]

Hi,

What kind of error are you getting? Does the open or install function of the driver throw an error? Or you just do not see the signals in the pins?

I noticed that you did not share the mux of the QSPI pins, this must be done in the init_gpio.c file.

_mqx_int _bsp_quadspi_io_init function.

/Alejandro

[tfe]

I do not receive any error messages except that a timeout occurs the first time a "waitWhileBysy"-function is called. This function can be regarded as near-exact as the one provided with the MQX examples (qspi example project). The only difference is that my implementation has an ad-hoc timeout implementation

uint32_t stat = 0x1;

uint16_t tmout = 0xffff;

while((stat & 0x1) && --tmout)

{

    if(qspi_rd_status1(QSPI_DEV_1, &status) < 0)

        stat = 0x1;

}

I am able to make reads and writes to the chip, but readbacks of a page that was just written give a different byte-string that the one that was just written (typically 0xff). The memory view of ARM DS5 (using the ULINKpro D debugger) shows 0xff before write, and 0x00 after the block has been invalidated, regardless of the pattern that was just written. After a stepping a few steps through the code, the memory view resets to 0xff as if the write never happened.

Following is the IOMUX from init_gpio.c (apologies for not including this in the previous post):

**************************** C-Code ****************************

/* IOMUX settings for QSPI1 */

/* QSPI1_A_SCK */

IOMUXC_RGPIO(9) =

  IOMUXC_SW_MUX_CTL_PAD_PAD_OBE(1) |

  IOMUXC_SW_MUX_CTL_PAD_PAD_IBE(0) |

  IOMUXC_SW_MUX_CTL_PAD_PAD_PKE(0) |

  IOMUXC_SW_MUX_CTL_PAD_PAD_PUS(2) |

  IOMUXC_SW_MUX_CTL_PAD_PAD_DSE(7) |

  IOMUXC_SW_MUX_CTL_PAD_PAD_SRE(0) |

  IOMUXC_SW_MUX_CTL_PAD_PAD_PUE(0) |

  IOMUXC_SW_MUX_CTL_PAD_ODE(0) |

  IOMUXC_SW_MUX_CTL_PAD_PAD_HYS(0) |

  IOMUXC_SW_MUX_CTL_PAD_PAD_SPEED(3) |

  IOMUXC_SW_MUX_CTL_PAD_PAD_MUX_MODE(7); // PTA19.QSCK_A

  /* QSPI1_A_CS0 */

  IOMUXC_RGPIO(22) =

    IOMUXC_SW_MUX_CTL_PAD_PAD_OBE(1) |

    IOMUXC_SW_MUX_CTL_PAD_PAD_IBE(0) |

    IOMUXC_SW_MUX_CTL_PAD_PAD_PKE(0) |

    IOMUXC_SW_MUX_CTL_PAD_PAD_PUS(2) |

    IOMUXC_SW_MUX_CTL_PAD_PAD_DSE(7) |

    IOMUXC_SW_MUX_CTL_PAD_PAD_SRE(0) |

    IOMUXC_SW_MUX_CTL_PAD_PAD_PUE(0) |

    IOMUXC_SW_MUX_CTL_PAD_ODE(0) |

    IOMUXC_SW_MUX_CTL_PAD_PAD_HYS(0) |

    IOMUXC_SW_MUX_CTL_PAD_PAD_SPEED(3) |

    IOMUXC_SW_MUX_CTL_PAD_PAD_MUX_MODE(7); // PTB0.QPCS0_A

/* QSPI1_A_DATA[3] */

IOMUXC_RGPIO(23) =

  IOMUXC_SW_MUX_CTL_PAD_PAD_OBE(1) |

  IOMUXC_SW_MUX_CTL_PAD_PAD_IBE(1) |

  IOMUXC_SW_MUX_CTL_PAD_PAD_PKE(0) |

  IOMUXC_SW_MUX_CTL_PAD_PAD_PUS(2) |

  IOMUXC_SW_MUX_CTL_PAD_PAD_DSE(7) |

  IOMUXC_SW_MUX_CTL_PAD_PAD_SRE(0) |

  IOMUXC_SW_MUX_CTL_PAD_PAD_PUE(0) |

  IOMUXC_SW_MUX_CTL_PAD_ODE(0) |

  IOMUXC_SW_MUX_CTL_PAD_PAD_HYS(0) |

  IOMUXC_SW_MUX_CTL_PAD_PAD_SPEED(3) |

  IOMUXC_SW_MUX_CTL_PAD_PAD_MUX_MODE(7); // PTB1.QSPI_IO3_A

/* QSPI1_A_DATA[2] */

IOMUXC_RGPIO(24) =

  IOMUXC_SW_MUX_CTL_PAD_PAD_OBE(1) |

  IOMUXC_SW_MUX_CTL_PAD_PAD_IBE(1) |

  IOMUXC_SW_MUX_CTL_PAD_PAD_PKE(0) |

  IOMUXC_SW_MUX_CTL_PAD_PAD_PUS(2) |

  IOMUXC_SW_MUX_CTL_PAD_PAD_DSE(7) |

  IOMUXC_SW_MUX_CTL_PAD_PAD_SRE(0) |

  IOMUXC_SW_MUX_CTL_PAD_PAD_PUE(0) |

  IOMUXC_SW_MUX_CTL_PAD_ODE(0) |

  IOMUXC_SW_MUX_CTL_PAD_PAD_HYS(0) |

  IOMUXC_SW_MUX_CTL_PAD_PAD_SPEED(3) |

  IOMUXC_SW_MUX_CTL_PAD_PAD_MUX_MODE(7); // PTB2.QSPI_IO2_A

/* QSPI1_A_DATA[1] */

IOMUXC_RGPIO(25) =

  IOMUXC_SW_MUX_CTL_PAD_PAD_OBE(1) |

  IOMUXC_SW_MUX_CTL_PAD_PAD_IBE(1) |

  IOMUXC_SW_MUX_CTL_PAD_PAD_PKE(0) |

  IOMUXC_SW_MUX_CTL_PAD_PAD_PUS(2) |

  IOMUXC_SW_MUX_CTL_PAD_PAD_DSE(7) |

  IOMUXC_SW_MUX_CTL_PAD_PAD_SRE(0) |

  IOMUXC_SW_MUX_CTL_PAD_PAD_PUE(0) |

  IOMUXC_SW_MUX_CTL_PAD_ODE(0) |

  IOMUXC_SW_MUX_CTL_PAD_PAD_HYS(0) |

  IOMUXC_SW_MUX_CTL_PAD_PAD_SPEED(3) |

  IOMUXC_SW_MUX_CTL_PAD_PAD_MUX_MODE(7); // PTB3.QSPI_IO1_A

/* QSPI1_A_DATA[0] */

IOMUXC_RGPIO(26) =

  IOMUXC_SW_MUX_CTL_PAD_PAD_OBE(1) |

  IOMUXC_SW_MUX_CTL_PAD_PAD_IBE(1) |

  IOMUXC_SW_MUX_CTL_PAD_PAD_PKE(0) |

  IOMUXC_SW_MUX_CTL_PAD_PAD_PUS(2) |

  IOMUXC_SW_MUX_CTL_PAD_PAD_DSE(7) |

  IOMUXC_SW_MUX_CTL_PAD_PAD_SRE(0) |

  IOMUXC_SW_MUX_CTL_PAD_PAD_PUE(0) |

  IOMUXC_SW_MUX_CTL_PAD_ODE(0) |

  IOMUXC_SW_MUX_CTL_PAD_PAD_HYS(0) |

  IOMUXC_SW_MUX_CTL_PAD_PAD_SPEED(3) |

  IOMUXC_SW_MUX_CTL_PAD_PAD_MUX_MODE(7); // PTB4.QSPI_IO0_A

************************** C-Code end **************************

[alejandrolozan1]

The GPIO configurations seem to be correct.

Which QSPI memory are you using?

/Alejandro