STM32U5 NOR Flash: Data Not Found After Reset

[Dadigno]

I am currently developing on a custom board based on the STM32U5 microcontroller with the MX25UM512 NOR flash memory. I am following the example provided by the STM32CubeU5 SDK. The example works correctly when I first run it (so data is written correctly), but after I reset the board, the code does not pass through the "if" condition as explained by the comments.

  nor_ospi_status =  fx_file_create(&nor_ospi_flash_disk, "STM32.TXT");

/* Check the create nor_xspi_status.  */
  if (nor_xspi_status != FX_SUCCESS)
  {
    /* Check for an already created nor_xspi_status. This is expected on the
    second pass of this loop!  */
    if (nor_xspi_status != FX_ALREADY_CREATED)
    {
      /* Create error, call error handler.  */
      Error_Handler();
    }
  }

I have already ensured that the memory is not formatted at every time: I have disabled the defines LX_STM32_OSPI_INIT and LX_STM32_OSPI_ERASE. Additionally, if I skip the fx_file_create operation during the second run, the fx_file_open function returns FX_NOT_FOUND.

I am not sure why this is happening. I would appreciate any help you can provide.

[KDJEM.1]

Hello @Dadigno and welcome to the community 🙂,

Please try to enable LX_STM32_OSPI_INIT and LX_STM32_OSPI_ERASE and let me know if the issue is solved or not?

Thank you.

Kaouthar

[Dadigno]

Thank Kaouthar for your valuable feedback.

Enabling LX_STM32_OSPI_INIT and LX_STM32_OSPI_ERASE significantly increases the execution time. This is because (as explained here ) these options trigger the initialization and erasing of the OSPI flash memory, which is computationally intensive operation.

After some thorough debugging sessions, I have observed that FileX seems to fail to restore the previous FX_MEDIA state. This is quite puzzling, as it contradicts the expected behavior of FileX, which is to maintain data persistence across executions.

Any other ideas?

Davide

[KDJEM.1]

Hello @Dadigno ,

Yes, these functions increases the execution time. But, I think that the issue is due to that the flash memory has not been erased properly.

Thank you.

Kaouthar

[Dadigno]

What are the potential problems associated with this and why it happens?

Anyway, lx_stm32_ospi_erase function runs correctly and returns LX_SUCCESS.

#if (LX_STM32_OSPI_ERASE == 1)

    ret = lx_stm32_ospi_erase(LX_STM32_OSPI_INSTANCE, (ULONG)0, (ULONG)0, 1);

    if (ret != 0)
    {
      return LX_ERROR;
    }
#endif

 If your assumption is correct, how can I verify it?

Davide