MIMXRT1064 custom PCB not booting - firmware programmed via SWD but no execution from 0x70000000

[Anushka_SS]

Hi,

I have a custom PCB with MIMXRT1064DVL6B chip.
I followed Teensy 4.1 schematic to design my custom PCB.

BOOT_MODE pin configuration (following Teensy 4.1 schematic):
- GPIO_AD_B0_05 (BOOT_MODE1) = connected to GND
- GPIO_AD_B0_04 (BOOT_MODE0) = originally connected to
Teensy bootloader chip, but since I am using DAPLink
probe for programming instead, I connected this to GND.
- So BOOT_MODE = 00 = Boot From Fuses

Current fuse values read via pyOCD:
- BOOT_CFG0 (0x400D8450) = 0x00000000
- BOOT_CFG1 (0x400D8460) = 0x00000012
- BOOT_CFG2 (0x400D8470) = 0x00011006
- SRC_SBMR2 (0x400F8020) = 0xfa43fce4

Programming method: DAPLink probe + pyOCD via SWD
Firmware base address in hex file: 0x70000000
Firmware size: ~1.1MB

I did NOT solder any external QSPI flash chip because
MIMXRT1064 already has 4MB internal flash on chip.
I want to use this internal flash for booting.

Problem: After programming via pyOCD, chip does not boot.
Reading 0x70000000 via pyOCD shows all zeros.
Reading 0x60000000 shows data (0x4fee7cff pattern).

Questions:
1. Is connecting GPIO_AD_B0_04 to GND correct when
not using Teensy bootloader chip?
2. How to correctly program and boot MIMXRT1064 using
its internal 4MB flash via DAPLink probe?
3. What fuse settings are needed to boot from
internal flash at 0x60000000?

Thank you!

[mayliu1]

Hi @Anushka_SS ,

Thank you so much for your interest in our products and for using our community.

Q1. Is connecting GPIO_AD_B0_04 to GND correct when not using Teensy bootloader chip?

A1: Yes, but please note that  in Boot From Fuses mode, whether the ROM actually performs normal boot or instead jumps to serial downloader depends on BT_FUSE_SEL .

Q2. How to correctly program and boot MIMXRT1064 using its internal 4MB flash via DAPLink probe?

A2:  For MIMXRT1064, the bootable image must be linked/programmed for the on-chip flash at 0x70000000, not 0x60000000. AN12290 explicitly states that RT1064 boots through FlexSPI2 and that the linker base address must be updated from 0x60000000 to 0x70000000 when migrating from RT1060 to RT1064.

https://www.nxp.com/docs/en/application-note/AN12290.pdf

I suggest you can refer to this application note for reference.

Q3. What fuse settings are needed to boot from internal flash at 0x60000000?

A3: The RT1064 on-chip QSPI flash boot address space is 0x70000000. So if your goal is to boot from the embedded flash, 0x60000000 is not the correct image base address for RT1064. 

Best Regards

May Liu

[Anushka_SS]

Hi,

Thank you for your previous response. I have made progress
based on your advice.

Current Status:
- BOOT_MODE = 00 (Boot From Fuses)
- BT_FUSE_SEL = 1 (programmed via pyOCD)
- Firmware successfully programmed at 0x70000000 via DAPLink/pyOCD
- Linker script base address = 0x70000000

Problem:
After programming, the chip does not boot correctly.
The code crashes immediately after startup.

Evidence:
- GDB debugger connects successfully
- After pressing F5 (Continue), code runs but crashes immediately
- When pressing Pause, GDB shows crash at random addresses:
0x0020e35a and 0x0020e358 (both in ITCM RAM region)
- The crash address is NOT fixed - it changes randomly each time
- Serial output (UART6 at 115200) shows nothing in Tera Term
- Ethernet LED stays ON continuously (not blinking)
- pyOCD confirms firmware is at 0x70000000

Framework:
- Using Teensy 4.1 Arduino framework via PlatformIO
- Chip is MIMXRT1064DVL6B (replaced from RT1062)
- First line in setup() is Serial6.begin(115200)
- Code crashes before any Serial6 output appears

Questions:
1. Is the Teensy 4.1 Arduino framework compatible with
MIMXRT1064DVL6B for booting from internal FlexSPI2 flash?
2. Could the random crash at ITCM addresses (0x0020e35a,
0x0020e358) be caused by incorrect startup/vector table
for RT1064 vs RT1062?
3. Is there any additional linker script or startup code
changes needed when migrating from RT1062 to RT1064?
4. Could the IVT header value 0x432000D1 (found at 0x70001000)
vs expected 0x402000D1 be causing the boot failure?

Thank you!

[mayliu1]

Hi @Anushka_SS ,

From NXP’s official support scope, the Teensy 4.1 Arduino framework is part of a third‑party ecosystem.

NXP does not provide official support or validation services for third‑party software frameworks

Thanks for your understanding and cooperation.

Best Regards

May Liu

[Anushka_SS]

Hi May Liu,

Thank you for your response. I understand NXP does
not support third-party frameworks like Teensy Arduino.

However, I want to clarify that this is NOT only a
Teensy/PlatformIO issue.

I also tested NXP's official hello_world example
from MCUXpresso SDK on my custom PCB with
MIMXRT1064DVL6B and it also crashes in Flash XIP mode.

Key observations:
- hello_world runs perfectly from RAM
- hello_world crashes from Flash XIP
- Crash address: 0x0020E360 (ITCM RAM region)
- Error: "Debug port inaccessible after access
at location 0x0020E360"
- Both Teensy framework AND MCUXpresso SDK crash
at same address

This confirms the issue is hardware related, not
framework related.

My hardware setup:
- MIMXRT1064DVL6B custom PCB
- 24MHz crystal on XTALI/XTALO
- All power pins connected correctly
- BOOT_MODE = 00, BT_FUSE_SEL = 1

Question: What hardware issues could cause Flash XIP
boot to fail while RAM execution works perfectly on
MIMXRT1064DVL6B?

Thank you!

[MultipleMonomials]

Hmm... fwiw, 0x0020e35a is not an ITCM address, it's in the bootrom. I have seen behavior like what you describe sometimes in situations where (I think):

• the debugger connects and resets the chip
• Your program doesn't run correctly and doesn't disable the RTWDOG (enabled at boot)
• The RTWDOG triggers and forces a reset back to bootrom code, or perhaps your program doesn't run correctly and triggers a fault back to bootrom code
• The bootrom code crashes as it's not in a state to continue executing

This seems kinda like somehow you are not correctly writing to the internal flash. Personally I'd recommend using either an MCU-Link + MCUXpressoIDE or a J-Link instead of pyocd. I have successfully used pyocd with RT1062 before but not RT1064, and I consider it by far the buggiest of the available flash tools, so I'd be very suspicious.

I recommend you switch to MCU-Link or J-Link and then, if flashing with one of those doesn't work, try dumping the flexspi2 flash and verifying that it contains the desired contents. Another option would be to force the chip into bootrom via the boot mode pins and then use MCU Boot Utility + a USB or UART connection to connect to the chip. This will let you both dump the existing flash contents and program it with your own elf file (though it's slow).