QSPI still times out on 32F769IDISCOVERY

[Jookia]

Describe the set-up

I'm using the 32F769IDISCOVERY board and Mbed OS 6.17.

Describe the bug

The HAL_QSPI_Transmit sometimes times out instead of returning data.

How To Reproduce

Run this using Mbed CLI1:

mkdir project1
cd project1
mbed new .
wget https://github.com/ARMmbed/mbed-os/files/7233465/main.cpp.txt
wget https://github.com/ARMmbed/mbed-os/files/7233470/target.json.txt
mv main.cpp.txt main.cpp
mv target.json.txt mbed_app.json
mbed compile -t GCC_ARM -m DISCO_F769NI -f

Watch on serial (115200 baud) for an error. This took half an hour for me, and an hour for a friend.

Additional context

I've reported this bug before as #52 . There was a release afterwards but this didn't fix it. I decided to give it some time and try again to see if the issue still happens.

I'm confident the fix is still the same: Clear the busy bit like some other chip variants do.

Edit: I have backported the v1.17 QSPI driver to Mbed and have the same results.

[icis4]

I observed similar effect with -O3 gcc flag. First operation sometimes fails with timeout, but second is successful. Set optimisation for size -Os fixes the problem. STM32F777, QSPI Nor Flash MX25L12833F at 108MHz/54MHz clock. arm-none-eabi toolchain version 7q2 works fine even with -O3, but others fails with -O3 and -O2

[Jookia]

Are you sure it fixes it, or it just doesn't reproduce the issue?

…

On Sun, May 07, 2023 at 01:23:28AM -0700, Ivaylo Iltchev wrote: I observed similar effect with -O3 gcc flag. First operation sometimes fails with timeout, but second is successful. Set optimisation for size -Os fixes the problem. -- Reply to this email directly or view it on GitHub: #82 (comment) You are receiving this because you authored the thread. Message ID: ***@***.***>

[icis4]

Jookia, everything works just fine. I have a lot Robot Framework tests about this, customers stop complain and finally I removed workaround code about this. This code is used by the bootloader, external flash loader for Stm32CubeProgrammer and 4 application firmwares.

[Jookia]

Could you show me how to reproduce this? I would like to compare assembly output.

…

On Mon, May 08, 2023 at 02:03:48AM -0700, Ivaylo Iltchev wrote: [Jookia](https://github.com/Jookia), everything works just fine. I have a lot Robot Framework tests about this, customers stop complain and finally I removed workaround code about this. -- Reply to this email directly or view it on GitHub: #82 (comment) You are receiving this because you authored the thread. Message ID: ***@***.***>

[icis4]

This is a pretty big project > .5 mil of lines, FreeRTOS, RNDIS, LwIP, Ethernet. I have FatFs on the half of this QSPI NOR Flash memory, another half is used for recovery application, FPGA image etc. First I hit this problem when checking crc32 of the file. Normally this takes around a second, but when read fails (not all, but up to 5 from 2000 blocks) it is takes more than 5 sec (5 sec for every timeout). If block fails, I had a workaround to read again - only one repeat was enough.

[icis4]

  * @brief  Reads Sector(s)
  * @param  pdrv: Physical drive number (0..)
  * @param  *buff: Data buffer to store read data
  * @param  sector: Sector address (LBA)
  * @param  count: Number of sectors to read (1..128)
  * @retval DRESULT: Operation result
  */
static DRESULT qspiflash_read (
	BYTE pdrv,      /* Physical drive nmuber to identify the drive */
	BYTE *buff,     /* Data buffer to store read data */
	DWORD sector,   /* Sector address in LBA */
	UINT count      /* Number of sectors to read */
)
{
	  if(BSP_QSPI_Read(buff,  FLASH_DEVICE_OFFSET + sector * BLOCK_SIZE, BLOCK_SIZE * count) != HAL_OK)
	  {
		  /* Error, try to reset QSPI and read one more time */
		  BSP_QSPI_Init();
		  if(BSP_QSPI_Read(buff,  FLASH_DEVICE_OFFSET + sector * BLOCK_SIZE, BLOCK_SIZE * count) != HAL_OK)
		  {
			  return RES_ERROR;
		  }
	  }

	  return RES_OK;
}

[icis4]

/**
 * @brief  Reads an amount of data from the QSPI memory.
 * @param  pData: Pointer to data to be read
 * @param  ReadAddr: Read start address
 * @param  Size: Size of data to read
 * @retval QSPI memory status
 */
uint8_t BSP_QSPI_Read(uint8_t* pData, uint32_t ReadAddr, uint32_t Size)
{
    QSPI_CommandTypeDef s_command;

    /* Initialize the read command */
    s_command.InstructionMode = QSPI_INSTRUCTION_4_LINES;
    s_command.Instruction = 0xEB;     //QPI_READ_4_BYTE_ADDR_CMD;
    s_command.AddressMode = QSPI_ADDRESS_4_LINES;
    s_command.AddressSize = QSPI_ADDRESS_24_BITS;
    s_command.Address = ReadAddr;
    s_command.AlternateByteMode = QSPI_ALTERNATE_BYTES_NONE;
    s_command.DataMode = QSPI_DATA_4_LINES;
    s_command.DummyCycles = MX25L128_DUMMY_CYCLES_READ_QUAD_IO;
    s_command.NbData = Size;
    s_command.DdrMode = QSPI_DDR_MODE_DISABLE;
    s_command.DdrHoldHalfCycle = QSPI_DDR_HHC_ANALOG_DELAY;
    s_command.SIOOMode = QSPI_SIOO_INST_EVERY_CMD;

    /* Configure the command */
    if (HAL_QSPI_Command(&QSPIHandle, &s_command, HAL_QPSI_TIMEOUT_DEFAULT_VALUE) != HAL_OK) {
        return QSPI_ERROR;
    }

    /* Set S# timing for Read command */
    MODIFY_REG(QSPIHandle.Instance->DCR, QUADSPI_DCR_CSHT, QSPI_CS_HIGH_TIME_1_CYCLE);

    /* Reception of the data */
    if (HAL_QSPI_Receive(&QSPIHandle, pData, HAL_QPSI_TIMEOUT_DEFAULT_VALUE) != HAL_OK) {
        return QSPI_ERROR;
    }

    /* Restore S# timing for nonRead commands */
    MODIFY_REG(QSPIHandle.Instance->DCR, QUADSPI_DCR_CSHT, QSPI_CS_HIGH_TIME_4_CYCLE);

    return QSPI_OK;
}