MQX Software SolutionsのトピックVybrid MQX interfacing QSPI1

Vybrid MQX interfacing QSPI1

tfe — Mon, 17 Aug 2015 13:10:00 GMT

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 **************************

Re: Vybrid MQX interfacing QSPI1

alejandrolozan1 — Mon, 24 Aug 2015 17:10:28 GMT

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

Re: Vybrid MQX interfacing QSPI1

tfe — Tue, 25 Aug 2015 06:11:30 GMT

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 **************************

Re: Vybrid MQX interfacing QSPI1

alejandrolozan1 — Mon, 07 Sep 2015 20:21:08 GMT

The GPIO configurations seem to be correct.

Which QSPI memory are you using?

/Alejandro

Re: Vybrid MQX interfacing QSPI1

tfe — Wed, 14 Oct 2015 07:03:00 GMT

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