The number that matters is the number of linked bytes assigned to each executable memory region. A successful build proves only that every section fits somewhere; it does not prove that the processor can fetch the first instruction from that region during reset. When an RT1060 image is linked into board SDRAM, SDRAM initialization must finish before the first relocated instruction or data access. A program that burns successfully through QSPI but produces no startup print usually fails in that boot-time interval.
Memory-placement approaches
| Approach | Code location | Boot dependency | Use when |
|---|---|---|---|
| QSPI execution | Flash region | The existing QSPI boot configuration | The linked image fits the configured flash region and the original project already starts correctly. |
| Application linked to RAM | Board SDRAM | SDRAM must be configured before application loading or execution | The IDE must place a larger application in SDRAM and the boot image contains working SDRAM initialization data. |
| Selective SDRAM placement | Startup code remains in its working region; selected large sections use SDRAM | SDRAM must be ready before those sections are accessed | Only particular code or data sections exceed internal-memory capacity. |
Keep QSPI execution when its configured region can hold the complete image. It preserves the boot path already proven by the source project. If code must execute from SDRAM, select the IDE option to link the application to RAM and enable XIP_BOOT_HEADER_DCD_ENABLE=1. A selective placement is often easier to diagnose because the reset path remains independent of SDRAM, but it requires explicit linker-section control.
Boot-time failure mechanism
This is a timing and addressability problem, not an application-logic problem. SDRAM is volatile and cannot accept normal instruction or data traffic immediately after reset. The boot path must establish its controller configuration before the processor branches to SDRAM or copies sections into it. The boot-header DCD setting supplies that early configuration path for the proposed RAM-linked arrangement.
Adding a RAM entry to MCUXpresso changes the linker's view of available space; it does not by itself initialize the physical memory. Likewise, moving the SDRAM entry upward changes placement priority but does not prove that its base address, capacity, attributes, or boot initialization match the board. This explains the characteristic result: the editor accepts the memory configuration, the linker produces an image, QSPI programming succeeds, and execution stops before any print output.
Quantities and configuration sources
| Quantity or limit | Decision it controls | Where to read it |
|---|---|---|
| Total executable image size | Whether the QSPI flash region is large enough | Linker map and build-size report |
| Section sizes and load/run addresses | Which sections overflow or unexpectedly enter SDRAM | Linker map |
| SDRAM base address and usable size | Values entered in the MCUXpresso RAM region | A working SDRAM project for the same board and the board memory documentation |
| Earliest SDRAM access | Whether boot initialization finishes soon enough | Map file, startup flow, and debugger program counter |
| Noncacheable-section placement | Whether the intended special section lands in ITCM | IDE memory configuration and linker map |
| Shareability attribute | Whether the selected SDK SDRAM configuration expects shareable memory | Working SDK SDRAM project and generated linker configuration |
No universal address-and-size pair can be copied into every RT1060 project. Enter the values used by a working SDRAM example for the same board, then confirm that the linker map stays within that range. Never enlarge a linker region beyond installed physical memory merely to clear an overflow; the build may pass while runtime accesses leave valid SDRAM.
Project-base selection
Use the project that already starts the most timing-sensitive subsystem and has the closest working memory configuration. For a combined lwIP, Wi-Fi, emWin, FatFs, and I2C application, the evkmimxrt1060_lwip_dhcp_freertos project is the practical base when its Wi-Fi and network stack already boot correctly. Port the required network-port components from evkmimxrt1060_wiced_iperf_4343W into that known-good startup environment.
Preserve the base project's startup files, boot header, memory-controller setup, linker configuration, and scheduler integration until the imported driver works. Import one subsystem at a time and rebuild after each addition. This separates capacity failures from initialization-order, duplicate-resource, and linker-placement failures.
MCUXpresso configuration procedure
- Build the unmodified base project and save its map file. Program it through the same QSPI path and verify that its original startup print appears.
- Open the project memory configuration. If board SDRAM is absent, use Add RAM and enter the base address and size copied from a working SDRAM configuration for the same board.
- Move the SDRAM entry upward to the position required for RAM-linked placement. Region order affects which eligible memory the managed linker selects.
- Select the option to link the application to RAM when the complete application must execute from SDRAM.
- Assign the noncacheable area to ITCM as specified for this proposed configuration. Confirm the resulting placement in the map rather than relying on the memory-editor display.
- Add
XIP_BOOT_HEADER_DCD_ENABLE=1to the project's defined symbols so the boot image includes the SDRAM configuration path required before RAM execution. - If the SDK SDRAM configuration being followed uses shareable memory attributes, add
SDRAM_IS_SHAREABLE. Treat this as an attribute choice, not as a substitute for the correct address, size, or DCD initialization. - Rebuild and inspect every output section's load and run address. Check that no executable or initialized-data section crosses the end of its configured region.
- Program through QSPI, reset the board, and debug from the reset entry point before enabling all imported middleware.
Verification and fault isolation
Place debugger stops at the reset entry, immediately after early memory initialization, and at the beginning of application startup. If execution never reaches the post-initialization stop, inspect the boot header, the value of XIP_BOOT_HEADER_DCD_ENABLE, and the SDRAM configuration used to construct the image. If execution reaches SDRAM and then faults, compare the current program address with the map file and verify the physical region boundaries.
After reaching application startup, test SDRAM with a bounded write/read pattern before starting lwIP, Wi-Fi, emWin, or FatFs. Test several addresses across the region, including its configured upper boundary without crossing it. A successful first word proves only that one address responds; boundary and pattern checks expose incorrect sizing, address-line problems, and placement beyond usable memory.
Restore middleware one component at a time. After each addition, record flash use, RAM use, SDRAM sections, and the first startup milestone reached. If a change removes all print output, debug the reset path instead of modifying the print subsystem.
Frequently asked questions
What happens if SDRAM is moved to the top of the memory list?
The linker may prefer SDRAM for eligible sections. The image can still fail before startup if SDRAM is not initialized before the first fetch or access.
What happens if XIP_BOOT_HEADER_DCD_ENABLE is missing?
A RAM-linked application can be placed at valid SDRAM addresses but reach them before the boot path configures SDRAM. Set XIP_BOOT_HEADER_DCD_ENABLE=1, rebuild the boot image, and verify execution from reset.
What happens if SDRAM_IS_SHAREABLE is enabled?
SDRAM_IS_SHAREABLE changes the intended memory attributes in configurations that consume that symbol. It does not repair a wrong SDRAM address, size, linker order, or missing early initialization.
What happens if the RT1060 still produces no startup print?
Stop adding middleware when the debugger cannot pass early SDRAM initialization or when the program address disagrees with the linker map. Escalate to official NXP support with the board identity, complete MCUXpresso memory table, defined symbols, linker map, QSPI programming method, and the last debugger address reached.