nrf_qspi.h error in nrf_qspi_cinstr_long_transfer_continue() function

[kpreiss]

Hi,

The below code I believe is in error.  The below write operation overwrites the LIO2, LIO3, WIPWAIT, and WREN settings in the CINSTRCONF register by only writing the length, LFEN and LFSTOP fields.  Do you know if there are new updates to the drivers?  We did a pull from the repo a week ago.

 

NRF_STATIC_INLINE void nrf_qspi_cinstr_long_transfer_continue(NRF_QSPI_Type *       p_reg,

                                                              nrf_qspi_cinstr_len_t length,

                                                              bool                  finalize)

{

    uint32_t mask = (((uint32_t)length << QSPI_CINSTRCONF_LENGTH_Pos) | (QSPI_CINSTRCONF_LFEN_Msk));

    mask |= (finalize ? QSPI_CINSTRCONF_LFSTOP_Msk : 0);

 

    p_reg->CINSTRCONF = mask;

}

Kurt

[ovrebekk]

Hi Kurt

There hasn't been any recent changes to this function, and this is by design. 

A long transfer sequence will start by a call to nrf_qspi_cinstr_long_transfer_start(..), where all these fields are set. 

To continue a transfer it is not necessary to write to these fields, and it is OK to only set the length, LFEN and LFSTOP fields. 

Are you having any issues getting custom long transfers to work?

Best regards
Torbjørn

[kpreiss]

We have the RESET# and WP# signals of the Quad SPI flash connected to IO3 and IO2.  When the flash device is in "standard" SPI mode, IO2 and IO3 need to be driven high by setting .io2_level = true and .io3_level = true, in order to erase and write flash memory.  If using the "long" transfer functions to send standard SPI flash commands from the QSPI peripheral, a call to the nrf_qspi_cinstr_long_transfer_continue() function will clear the .io2_level and .io3_level settings in the CINSTRCONF register and not allow a erase or write operation to occur.

Thanks

[ovrebekk]

Hi Kurt

You mean you have actually measured the lines and found them to be cleared?

Do you have a scope trace you can share showing this behavior?

Only the first write to CINSTRCONF should affect the state of IO2 and IO3 (until the command is finalized), so if this is not the case it points to an issue with the hardware implementation or the documentation. 

Best regards
Torbjørn