nrf_qspi.h error in nrf_qspi_cinstr_long_transfer_continue() function

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

Parents
  • 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

Reply
  • 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

Children
  • 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

Related