Hi,
I cannot locate any QPI sample code in the example. Was it possible for anyone to share me the sample code?
Thanks a bunch.
Hi,
I cannot locate any QPI sample code in the example. Was it possible for anyone to share me the sample code?
Thanks a bunch.
Do you mean QSPI? If so: QSPI Example.
Hi haakonsh
Thanks for the quick feedback. But when I checked the solutions, I think QPI and Quad SPI is different solutions.
Quad SPI
While dual SPI re-uses the existing serial I/O lines, quad SPI adds two more I/O lines (SIO2 and SIO3) and sends 4 data bits per clock cycle. Again, it is requested by special commands, which enable quad mode after the command itself is sent in single mode.
SQI Type 1: Commands sent on single line but addresses and data sent on four lines
SQI Type 2: Commands and addresses sent on a single line but data sent/received on four lines
QPI/SQI
Further extending quad SPI, some devices support a "quad everything" mode where all communication takes place over 4 data lines, including commands.[19] This is variously called "QPI"[18] (not to be confused with Intel QuickPath Interconnect) or "serial quad I/O" (SQI)[20]
This requires programming a configuration bit in the device and requires care after reset to establish communication.
https://en.wikipedia.org/wiki/Serial_Peripheral_Interface#QPI/SQI
Hi haakonsh
Thanks for the quick feedback. But when I checked the solutions, I think QPI and Quad SPI is different solutions.
Quad SPI
While dual SPI re-uses the existing serial I/O lines, quad SPI adds two more I/O lines (SIO2 and SIO3) and sends 4 data bits per clock cycle. Again, it is requested by special commands, which enable quad mode after the command itself is sent in single mode.
SQI Type 1: Commands sent on single line but addresses and data sent on four lines
SQI Type 2: Commands and addresses sent on a single line but data sent/received on four lines
QPI/SQI
Further extending quad SPI, some devices support a "quad everything" mode where all communication takes place over 4 data lines, including commands.[19] This is variously called "QPI"[18] (not to be confused with Intel QuickPath Interconnect) or "serial quad I/O" (SQI)[20]
This requires programming a configuration bit in the device and requires care after reset to establish communication.
https://en.wikipedia.org/wiki/Serial_Peripheral_Interface#QPI/SQI
Ahh, maybe. I've got to check with the developers.
-Update:
It depends on the memory chip. If it just ignores invalid commands and addresses then maybe. Do you have a datasheet for the memory chip?
Thanks a bunch haakonsh, kindly refer to the attached link. Besides that, may I know how to support this chip using the quadspi sample? The reason I turn to QPI is because the quadspi sample just don't works with this chip.
http://www.cypress.com/file/316661/download
Model:S25FL064LABNFI010
Well, we should be able to interface with this memory chip via standard QSPI. Do you have a logic analyzer scope of the communication when using the SDK example?
Will nrf_drv_qspi_init(&config, qspi_handler, NULL) trigger the SPI to sent out data? I notice my logic analyzer capture some data (0x500) when the nrf_drv_qspi_init is executed. I forget to add on, the yellow 1 is CS, blue 2 is SCK, purple 3 is SI/SI0 and green 4 on the scope is refer to SO/SI1
Here is the test configure code.
#define QSPI_STD_CMD_WRSR 0x01 #define QSPI_STD_CMD_RSTEN 0x66 #define QSPI_STD_CMD_RST 0x99 static void configure_memory() { uint8_t temporary[2] = {0x02,0x02}; uint32_t err_code; nrf_qspi_cinstr_conf_t cinstr_cfg = { .opcode = QSPI_STD_CMD_RSTEN, .length = NRF_QSPI_CINSTR_LEN_1B, .io2_level = true, .io3_level = true, .wipwait = true, .wren = false }; // Send reset enable err_code = nrf_drv_qspi_cinstr_xfer(&cinstr_cfg, NULL, NULL); APP_ERROR_CHECK(err_code); // Send reset command cinstr_cfg.opcode = QSPI_STD_CMD_RST; err_code = nrf_drv_qspi_cinstr_xfer(&cinstr_cfg, NULL, NULL); APP_ERROR_CHECK(err_code); // Send WREN cinstr_cfg.opcode = 0x71; err_code = nrf_drv_qspi_cinstr_xfer(&cinstr_cfg, NULL, NULL); APP_ERROR_CHECK(err_code); // Switch to qspi mode cinstr_cfg.opcode = QSPI_STD_CMD_WRSR; cinstr_cfg.length = NRF_QSPI_CINSTR_LEN_2B; err_code = nrf_drv_qspi_cinstr_xfer(&cinstr_cfg, &temporary, NULL); APP_ERROR_CHECK(err_code); }
And I tried capture the reset enable command send when configure_memory function is called, the I notice there is extra data in front of the 0x66 command is that correct? What are those data for?
Here is the capture for RST command 0x99
Here is the capture for WRAR command 0x06
Here is the capture for WRR (0x01) + SR1NV (0x02) + CR1NV (0x02), it seem tgat CR1NV is not written