• State Verified Answer
  • Replies 5 replies
  • Subscribers 68 subscribers
  • Views 964 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 324773
Options

spi_flash is not running on nRF5340DK out of box

bbbakke

I wanted to get external qspi flash working for the current project I am working on. We are developing on the nRF5340DK currently while waiting for custom boards. So my current case is as simple as you can get, execute the spi_flash sample app on the nRF5340DK. Here is what I have done:

  • Open VSCode, select the nRF Connect Extension, and select: Create new application -> Copy a sample -> find and select SPI Flash Sample
  • In the nRF Connect Extension I selected Add build configuration, selected the nRF5340dk_nrf5340_cpuapp board, selected the prj.conf configuration, added the nRF5340dk_nrf5340_cpuapp.conf Kconfig fragment, and built the app without error (see attached image). (NOTE: I did not see a device tree overlay for the nrf5340 in the pull down menu (image attached image). Should there be one?)
  • Then I flashed the nRF5340DK board.

I have with a terminal window connected at power up. I get the following output:

*** Booting nRF Connect SDK v3.5.99-ncs1 ***
mx25r6435f@0: device not ready.

Other information that might be helpful:

  • My development environment is on a MacBook Pro (apple silicon)
  • My VSCode is Version: 1.87.2
  • My nRF Connect for VS Code is v2024.3.25
  • My tool chain and active sdk are v2.6.0

Besides the above steps, I have not made any changes to the sample code. Can you please provide any insight as to why this is not working out of the box.

BR, 

BBB

  • 0

    Hi,

    Try to do "nrfjprog --family NRF53 --qspieraseall" before programming the sample.

    Regards,
    Sigurd Hellesvik

  • 0 in reply to Sigurd Hellesvik

    This did fix the issue, but raises a few more questions. For me, and others that may run into this problem, can you answer each of these please:

    1. What was the problem or state of the flash that caused the original issue I had?
    2. How, in product code, can I detect this issue (short of the flash driver initialization failing)?
    3. What does nrfprog do to recover the external flash to a good state (since the flash drive fails initialization I assume this is being done at a lower level utilizing the QSPI driver), and is there reference code available that I can incorporate into my production code to recover it if it occurs in the field?

    Thanks for your help,

    BBB

  • 0 in reply to bbbakke

    We have an issue with our drivers here and we are looking into this internally.
    I hope a PR with a fix will come within days, and I will let you know at that point.

  • +1 in reply to Sigurd Hellesvik
    bbbakke said:
    What was the problem or state of the flash that caused the original issue I had?

    The QSPI NOR drivers in v2.6.0 and v2.5.2 do not properly initialize the external flash. Specifically, because of a bug (unexpected reset of external flash), it fails to set the external flash into Quad mode.

    bbbakke said:
    How, in product code, can I detect this issue (short of the flash driver initialization failing)?

    Communication with the external flash over QSPI NOR fails.

    bbbakke said:
    What does nrfprog do to recover the external flash to a good state (since the flash drive fails initialization I assume this is being done at a lower level utilizing the QSPI driver), and is there reference code available that I can incorporate into my production code to recover it if it occurs in the field?

    "nrfjprog -f NRF53 --qspieraseall" loads a custom RAM driver for the QSPI that enables Quad mode on the external flash.
    Then next time you flash the app, the external flash is in quad mode, and will work.
    Similarly flashing a v2.5.1 or earlier application that sets up the external flash with QSPI NOR will also be a workaroud.
    To fix the bug causing the misconfiguration, you can configure pull-up on the SIO3 line, as this should  prevent the reset, thus allowing the v2.6.0 drivers to properly configure Quad-mode. I have not tested this one.

    We are working on a Known Issue to describe the best workaround on this, and I will edit this comment to post to add that when it is out.

    EDITED:

    Not known issue yet, but here are PRs

    Fix posted upstream: https://github.com/zephyrproject-rtos/zephyr/pull/71373
    Cherry-pick into NCS: https://github.com/nrfconnect/sdk-nrf/pull/14812

    EDIT 2024-04-26:

    v2.6.1 anv 2.5.3 has been released, containing the fix for this bug.

  • 0 in reply to Sigurd Hellesvik

    Thanks for the update. That is good news. We will pull in v2.6.1 as soon as we can.

Related