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

[jthmp]

NRF52840 running 17.1 SDK and using QSPI interface to erase a block of memory from AT25FF321A external flash IC.

When we call erase it takes 930 millisec to finish erasing a 4kb block. The IC datasheet says it should only take 45 millisec or something like that. 

Why is it taking so long?

 

nrfx_err_t nrf_err = nrfx_qspi_erase(NRF_QSPI_ERASE_LEN_4KB, start_address);
if (NRFX_SUCCESS == nrf_err)
{
    while(NRFX_SUCCESS != nrf_drv_qspi_mem_busy_check());
}

// this usually takes 770 - 930 millisec to finish
// but the datasheet for the ext falsh says it should only take 45 ms at most

[Hung Bui]

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:

[jthmp]

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?

[Hung Bui]

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. 

[jthmp]

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);

[jthmp]

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

[Hung Bui]

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. 

[jthmp]

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

[Hung Bui]

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 ? 

[jthmp]

ok I'll get that and I'll check