MIMXRT685-AUD-EVK stuck in boot-up

[anubiradar-adi]

I am trying to get samples/hello_world and samples/kvss/nvs working on the NXP MIMXRT685-AUD-EVK. I am able to get both examples building with the following commands:

The aud-evk is not supported out of box so I made the following modifications to get the examples building:

zephyr/boards/nxp/mimxrt685_evk/board.yml

board:
  name: mimxrt685_evk
  full_name: MIMXRT685-EVK
  vendor: nxp
  socs:
    - name: mimxrt685s
+  revision:
+    format: "custom"
+    default: "evk"
+    revisions:
+      - name: "evk"
+      - name: "aud-evk"

zephyr/boards/nxp/mimxrt685_evk/revision.cmake

+if (NOT DEFINED BOARD_REVISION)
+  set(BOARD_REVISION "evk")
+else ()
+  if (NOT (BOARD_REVISION STREQUAL "evk") AND NOT (BOARD_REVISION STREQUAL "aud-evk"))
+    message(FATAL_ERROR "Invalid board revision, ${BOARD_REVISION}, valid revisions are: evk, aud-evk")
+  endif()
+endif()

zephyr/boards/nxp/mimxrt685_evk/CMakeLists.txt

if(CONFIG_BOARD_MIMXRT685_EVK_MIMXRT685S_CM33)
  zephyr_library()
  zephyr_library_sources(cm33/init.c)
elseif(CONFIG_BOARD_MIMXRT685_EVK_MIMXRT685S_HIFI4)
  zephyr_library()
  zephyr_library_sources(hifi4/init.c)
endif()

if(CONFIG_NXP_IMXRT_BOOT_HEADER)
  if(NOT DEFINED CONFIG_BOARD_MIMXRT685_EVK_MIMXRT685S_CM33 AND NOT DEFINED CONFIG_BOARD_MIMXRT685_EVK_MIMXRT685S_HIFI4)
    message(WARNING "It appears you are using the board definition for "
      "the MIMXRT685-EVK, but targeting a custom board. You may need to "
      "update your flash configuration block data")
  endif()
+if (${BOARD_REVISION} STREQUAL "evk")
+  set(RT685_BOARD_NAME "evkmimxrt685")
+elseif (${BOARD_REVISION} STREQUAL "aud-evk")
+  set(RT685_BOARD_NAME "mimxrt685audevk")
+endif()
  # This flash configuration block may need modification if another
  # flash chip is used on your custom board. See NXP AN13386 for more
  # information.
+  set(RT685_BOARD_DIR
+    "${ZEPHYR_HAL_NXP_MODULE_DIR}/mcux/mcux-sdk/boards/${RT685_BOARD_NAME}")
  zephyr_library_sources(flash_config/flash_config.c)
  zephyr_library_include_directories(flash_config)
endif()

The commands below were used to build the examples:

west build -p -b mimxrt685_evk/mimxrt685s/cm33 samples/subsys/kvss/nvs -- -DBOARD_REVISION=aud-evk -DCONFIG_FLASH_BASE_ADDRESS=0x18000000

west build -p -b mimxrt685_evk/mimxrt685s/cm33 samples/hello_world -- -DBOARD_REVISION=aud-evk -DCONFIG_FLASH_BASE_ADDRESS=0x18000000

Both examples seem to get stuck at address 0x0001c04a. What other changes do I need to make to get these examples running on this board?

[ZhaoxiangJin]

@lucien-nxp

[lucien-nxp]

I had created PR to support aud board for cm33 core only few days ago. #107614
Could you switch to the branch I supported and try again?

[anubiradar-adi]

Thanks for sharing this PR Lucien, I was able to get the basic examples you listed (button/blinky/hello world) working on your branch.

I tried building the NVS example (samples/subsys/kvss/nvs) as well but am not able to hit main on that example. From your PR it looks like there is support for external flash and there is a storage partition defined. Is there any more support that needs to be added on the NXP side before the NVS example is functional?

This is the command I used to build the NVS example:

west build -p -b mimxrt685_aud_evk/mimxrt685s/cm33 samples/subsys/kvss/nvs

[anubiradar-adi]

@lucien-nxp wanted to follow up here, is there any support pending to enable the NVS example? Or do you recommend trying out another example to be able to test access to external flash?

[lucien-nxp]

Hi @anubiradar-adi
NXP has more features planned for the MIMXRT685-AUD-EVK in Zephyr — additional peripheral enablement including external flash is on the roadmap and is targeted to land before the v4.5 release, but not in the immediate.

For the NVS sample, the likely reason it doesn't reach main: under XIP the ROM has already initialized the FlexSPI/flash so that code can execute from it, but when NVS starts up the flash driver re-initializes the same FlexSPI controller. The two initializations can conflict, which prevents the system from running past driver init. If you'd like to keep moving in the meantime, the quickest workaround is to build and run the sample from SRAM instead of XIP, then attach a debugger.

Is this blocking you on a near-term milestone?

[anubiradar-adi]

Hi @lucien-nxp
Thank you for the update! I will have to get back to you on a timeline.

I am trying to configure the NVS sample to run out of SRAM instead of Flash but I seem to keep entering the lockup state. I am adding my most recent modifications below:

overlay file for NVS sample

/ {
	chosen {
		/* Run from SRAM instead of XIP flash */
		zephyr,flash = &sram0;
		/* Remove code partition to prevent boot from flash */
		/delete-property/ zephyr,code-partition;
		/* Keep flash controller for NVS access, but code doesn't run from it */
		zephyr,flash-controller = &mx25u51245g;
	};
};

/* FlexSPI will be initialized by the flash driver, not for XIP */
&flexspi {
	status = "okay";
};

/* Flash device for NVS storage */
&mx25u51245g {
	status = "okay";
};

/* Storage partition for NVS */
&storage_partition {
	status = "okay";
};

conf file for NVS sample

# Disable boot header - load via debugger
CONFIG_NXP_IMXRT_BOOT_HEADER=n

# Don't initialize FlexSPI for XIP at boot (but allow flash driver to init it later)
CONFIG_MEMC_MCUX_FLEXSPI_INIT_XIP=n

# Disable SOC reset hook to skip SystemInit when running from SRAM
CONFIG_SOC_RESET_HOOK=n

It looks like the program is being loaded to SRAM and reaches z_prep_c during initialization but goes into lockup when trying to go past that. What do you suggest?

[anubiradar-adi]

@lucien-nxp Just following up, do you have any suggestions on how to modify the configurations above to get the NVS example running out of SRAM?

[lucien-nxp]

Apologies for the very late reply.

Good news — you can drop the run-from-SRAM workaround. We root-caused the hang and fixed it; NVS now runs from flash (XIP) normally.

Cause: the FlexSPI NOR driver reinstalls the MX25U51245G read with a 10 dummy-cycle 0xEC quad read during init, but the board's FCB had the flash set to a shorter read latency. The mismatch corrupted XIP fetches once the flash driver came up, so the CPU locked up before main() — which is why hello_world/blinky worked but NVS didn't.

Fix: the board FCB now matches the latency the driver expects (board-only change). Verified on the AUD-EVK: NVS and LittleFS both reach main(), read/write, and persist across reboots; hello_world/blinky still fine. No SRAM/overlay needed.

It's in #111144 (draft, builds on #107614 — merges after it). To try it:

west build -p -b mimxrt685_aud_evk/mimxrt685s/cm33 samples/subsys/kvss/nvs
west flash

[anubiradar-adi]

Thank you, Lucien, I am able to successfully run the NVS example now.