Erasing 4kb QSPI ext flash block takes too long 700 - 900 millisec

RE: Erasing 4kb QSPI ext flash block takes too long 700 - 900 millisec

jthmp — Tue, 17 Sep 2024 18:35:23 GMT

ok I'll get that and I'll check

RE: Erasing 4kb QSPI ext flash block takes too long 700 - 900 millisec

Hung Bui — Tue, 17 Sep 2024 06:55:26 GMT

Hi Joshua,
Could you capture longer trace to see how it goes with the erase. I would expect to see the nRF52 continuously poll the external flash for status until the status show it's ready. If it's the case I am not sure what can we do to improve that.
Please check if there is any option in the external flash for example "high performance" more or something ?

RE: Erasing 4kb QSPI ext flash block takes too long 700 - 900 millisec

jthmp — Mon, 16 Sep 2024 17:43:57 GMT

Hi, we just tried that

uint32_t                   start    = xTaskGetTickCount();
    nrf_qspi_addrconfig_conf_t addr_cfg = {
        .opcode = 0xB7, .byte0 = 0, .byte1 = 0, .mode = 0, .wipwait = true, .wren = true};
    nrf_qspi_addrconfig_set(NRF_QSPI, &addr_cfg);
    sys_delay_ms(10);
    nrfx_err_t nrf_err = nrfx_qspi_erase(NRF_QSPI_ERASE_LEN_4KB, 0x00041000);

    while (NRFX_SUCCESS != nrfx_qspi_mem_busy_check())
        ;
    uint32_t end = xTaskGetTickCount();
    NRF_LOG_INFO("Elapsed: %lu addr: %p", end - start, start_address);

but still 920 millisec

Also, we looked on the scope and here are the results when only using nrfx_qspi_erase (no nrf_qspi_addrconfig_set).

It looks like the nrf sdk DOES send the 0x06 wren command during erase automatically

RE: Erasing 4kb QSPI ext flash block takes too long 700 - 900 millisec

Hung Bui — Mon, 16 Sep 2024 08:08:45 GMT

Hi Joshua,
Could you try this:

    nrf_qspi_addrconfig_conf_t addr_cfg = {
        .opcode    = 0xB7,
        .byte0     = 0 ,
        .byte1     = 0,
        .mode      = 0,
        .wipwait   = true,
        .wren      = true
    };
    nrf_qspi_addrconfig_set(NRF_QSPI,&addr_cfg);

As I mentioned, please try to verify the operation using a logic analyzer. It would save you a lot of time.

RE: Erasing 4kb QSPI ext flash block takes too long 700 - 900 millisec

jthmp — Fri, 13 Sep 2024 16:12:57 GMT

Or would it be something like this?

// save current reg value

uint32_t config = QSPI->ADDRCONF;

// add wren

bool wren = true;

config |= (wren ? 1U : 0U) << QSPI_ADDRCONF_WREN_Pos;

// update register

QSPI->ADDRCONF = config;

// send erase

nrfx_err_t nrf_err = nrfx_qspi_erase(NRF_QSPI_ERASE_LEN_4KB, start_address);

// wait for completion code here

RE: Erasing 4kb QSPI ext flash block takes too long 700 - 900 millisec

jthmp — Fri, 13 Sep 2024 16:05:49 GMT

Hi,

Ok so could you provide an example process?

would it be like this?

nrf_qspi_addrconfig_set( WHAT GOES HERE ?);
nrfx_err_t nrf_err = nrfx_qspi_erase(NRF_QSPI_ERASE_LEN_4KB, start_address);

RE: Erasing 4kb QSPI ext flash block takes too long 700 - 900 millisec

Hung Bui — Fri, 13 Sep 2024 09:21:18 GMT

Hi Joshua,
As far as I know by default WREN is not sent. If you want to send WREN you would need to set WREN to 1 in ADDRCONF register. In the code it's done by calling nrf_qspi_addrconfig_set().
I was suggesting that you should use the logic analyzer to verify the QSPI operation is correct. Please consider that.

RE: Erasing 4kb QSPI ext flash block takes too long 700 - 900 millisec

jthmp — Thu, 12 Sep 2024 22:35:48 GMT

ok,

by the way,

using the standard nrf erase method:
nrfx_err_t nrf_err = nrfx_qspi_erase(NRF_QSPI_ERASE_LEN_4KB, start_address);

will the function 'nrfx_qspi_erase' automatically send the wren (0x06) cmd before calling the erase cmd?

RE: Erasing 4kb QSPI ext flash block takes too long 700 - 900 millisec

Hung Bui — Thu, 12 Sep 2024 12:21:03 GMT

Hi Joshua,
As long as you use our library directly you shouldn't have a problem using the nRF52 on the Laird's module.
When you change the QSPI pin, please make sure you follow the guideline on which pin should be used for QSPI.
I can see you are using some pins that clearly noted "low frequency I/O only" please try avoid that. Please check the spec for the detail list:

RE: Erasing 4kb QSPI ext flash block takes too long 700 - 900 millisec

jthmp — Wed, 11 Sep 2024 21:35:02 GMT

I have the nrf52840 dev kit so will try.

also, we are not using the standard nrf qspi pins, does that make a difference?

#define GPIO_SPI_MISO 6u // SIO_6 = NVM SPI MISO input pin (QSPI = IO1)

#define GPIO_SPI_CLK 7u // SIO_7 = NVM SPI CLK output pin

#define GPIO_SPI_MOSI 8u // SIO_8 = NVM SPI MOSI output pin (QSPI = IO0)

#define GPIO_SPI_IO3 9u // SIO_9 = NVM SPI IO3 pin

#define GPIO_SPI_IO2 10u // SIO_10 = NVM SPI IO2 pin

also, not sure if it makes a difference but our nrf52840 core is integrated into the Laird Connectivity BL654 module...

RE: Erasing 4kb QSPI ext flash block takes too long 700 - 900 millisec

Hung Bui — Wed, 11 Sep 2024 07:57:42 GMT

Hi Joshua,
I don't see any issue with the code and the driver for QSPI. It could be that it's the performance issue with the external flash.
Have you tried to test with the external flash on the DK ? From the datasheet it should take less than 240ms for 4kB erase.

RE: Erasing 4kb QSPI ext flash block takes too long 700 - 900 millisec

jthmp — Tue, 10 Sep 2024 17:46:46 GMT

Yeah, I tried checking the nrf_drv_qspi_mem_busy_check every 5 millisec to put some time in between but that didn't change anything.

When I tried 32kb erase it took 7.5 seconds which is way over the spec of the datasheet.

RE: Erasing 4kb QSPI ext flash block takes too long 700 - 900 millisec

Hung Bui — Tue, 10 Sep 2024 09:25:39 GMT

Hi Joshua,

Have you tried to use the logic analyzer to capture how the process goes ?
If the nRF52 is doing it correctly that it sends WREN and then send Block Erase command 0x20 then continuously check the status (nrf_drv_qspi_mem_busy_check) to know when the AT25FF321A finish erasing then I don't see the problem on the nRF52's side here.
You can try to change how often the status bit is checked , there could be a chance that sending too much of that causing a problem ? Or if there is a problem when doing nrf_drv_qspi_mem_busy_check() that it's not called for 900ms ?

Have you tried to do a 32kB erase to see how long it takes ?

RE: Erasing 4kb QSPI ext flash block takes too long 700 - 900 millisec

jthmp — Mon, 09 Sep 2024 21:50:02 GMT

Here is our erase function using the custom transfer command instead of the standard nrf qspi erase.

It still takes 920 millisec even when explicitly calling wren = true

static NVM_ERROR erase_qspi_command(uint8_t cmd, uint32_t address, bool wren)
{
    uint8_t cmd_buffer[3]; //3 bytes for address

    cmd_buffer[0] = (address >> 16) & 0xFF;
    cmd_buffer[1] = (address >> 8) & 0xFF;
    cmd_buffer[2] = address & 0xFF;

    nrf_qspi_cinstr_conf_t cinstr_cfg = {.opcode    = 0x20, //4kb block erase
                                         .length    = 4, // Command + Address
                                         .io2_level = true,
                                         .io3_level = true,
                                         .wipwait   = false,
                                         .wren      = wren};

    nrfx_err_t nrf_err = nrfx_qspi_cinstr_xfer(&cinstr_cfg, cmd_buffer, NULL);
    while (NRFX_SUCCESS != nrf_drv_qspi_mem_busy_check());
    //This takes 920 millisec to finish
    return nrf_err;
}

RE: Erasing 4kb QSPI ext flash block takes too long 700 - 900 millisec

jthmp — Mon, 09 Sep 2024 16:10:31 GMT

I can check the signal on a scope but the other qspi functions write and read work just fine (though I haven't measured the execution time). The qspi speed is set to 16mhz.

Also, the erase does work without us setting the wren bit and just using the default nrf qspi erase function:

nrfx_qspi_erase.

It seems like wren is taken care of by the nrf qspi erase function in the sdk? Is this not the case?

If not, can you show me an example of sending the wren cmd using the 17.1 nrf sdk?

or if possible can you show me an example of using

nrfx_qspi_cinstr_xfer to create a custom erase function? I've tried but same behavior.

RE: Erasing 4kb QSPI ext flash block takes too long 700 - 900 millisec

Hung Bui — Mon, 09 Sep 2024 13:02:06 GMT

Hi Joshua,
Could you try to use a logic analyzer to capture the erase process ? This way we can find what causing the long erase time.
I did a quick look at the datasheet of the AT25FF321A and it seems to be longer than 45ms ?

I would also want to check if the write enable is sent before the block erase command.