S25FL QSPI with NRF52840

[daleye]

I believe I'm following both the Cypress data sheet properly. Yet I'm still having an issue getting the simple QSPI Peripheral example to show data consistency.

Can it be confirmed that "nrf_drv_qspi_write" sends a WREN command before? This is the only thing I can think of..

Here's my modification -- Of note is the part does not need reset enable, it does require a 2 byte write to put the part in Quad IO mode.

 

static void configure_memory()
{
    uint8_t temporary[2] = {0x00,0x02};
    uint32_t err_code;
    nrf_qspi_cinstr_conf_t cinstr_cfg = {
        .opcode    = QSPI_STD_CMD_RST,
        .length    = NRF_QSPI_CINSTR_LEN_1B,
        .io2_level = true,
        .io3_level = true,
        .wipwait   = true,
        .wren      = true
    };

//    // Send reset
    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_3B;
    err_code = nrf_drv_qspi_cinstr_xfer(&cinstr_cfg, &temporary, NULL);
    APP_ERROR_CHECK(err_code);


}

[bjorn-spockeli]

Which SDK version are you using? 

[daleye]

sdk16

I should note the following:

Without writing the Quad IO opcode my read returns all 0x80, with the write, it returns all 0xFF, so I believe the config instruction is going over without an issue; however, I haven't found a way to send a 0x06 (WREN) before erase and flash which appears required by the part.

[bjorn-spockeli]

HI Daleye, 

Apologies for the late reply.

Do you have access to a logic analyzer? It would be useful to see the data sent on the QSPI lines. 

Regarding your question on if nrf_drv_qspi_write sends a WREN, I to hooked up my logic analyzer to the QSPI lines on our nRF52840 DK and see if a WREN command is sent. So it could be that you have to send this using  a custom instruction. 

This is the trace section where nrf_drv_qspi_write() is called and I do not see any WREN command being sent.  Below is the capture of the nrf_drv_qspi_erase operation. 

[daleye]

Great, thank you. I did not have access to this or the pins on our custom hardware... But I was able to get a standard spi interface working.

Good to know wren is not sent on qspi, this should be updated as I think it is required for many common parts.

[bjorn-spockeli]

Ok, so you have opted for the regular SPI peripheral instead of the QSPI?

Will report this feedback in our internal issue tracker database.

[daleye]

Correct, we have some starting code for these devices in 2 wire mode. The existing example you provide for QSPI works on the devkit; however, it is in violation of their datasheet.. MX25R6435F - Macronix Data Sheet

"Write Enable (WREN) command: WREN command is required to set the Write Enable Latch bit (WEL) before issuing other commands to change data. "

"The Write Enable (WREN) instruction is for setting Write Enable Latch (WEL) bit. For those instructions like PP, 4PP, SE, BE32K, BE, CE, and WRSR, which are intended to change the device content WEL bit should be set every time after the WREN instruction setting the WEL bit."

It appears without the WREN this particular chip is forgiving and allows operations, this could be highlighted by their use of "SHOULD" rather than "SHALL".. either way, the spansion, now cypress part is not forgiving and requires this as it is still required in the SPI variant code.

[bjorn-spockeli]

Looking at trace when nrf_drv_qspi_erase is called I see that a WREN instruction is issued

So could it be that since the WREN instruction was sent during the nrf_drv_qspi_erase procedure, then its not needed when nrf_drv_qspi_write is executed?

The first highlighted log line is the WREN instruction sent during the erase procedure and the second highlighted line is the first transaction in the write procedure.