MIMXRT1160 XIP fails randomly I have multiple boards running XIP from octal flash at 166 MHz. One of them fails occasionally with "undefined instruction" error. I've suspected signal integrity issues but I do not have test points on the PCB, so the only way to check that has been reducing speed from 166 MHz to 133 MHz, which appears to "fix" the problem with that particular board. It's probably telling that the error appears most often when chainloading the application from mcuboot. It is more rare during application runtime. I can't find a reliable way to trigger it too - need to power-cycle the board several times until the fault appears. Is there a way I can diagnose this XIP failure with more precision? Re: MIMXRT1160 XIP fails randomly Hi @tbonkers ,
The behavior you describe is most likely caused by insufficient read-sampling margin (setup/hold) at 166 MHz, due to tight PCB-routing/signal-integrity headroom on the Flash data lines. This also explains both symptoms: dropping to 133 MHz widens the sampling window so the issue "disappears"; and the mcuboot chainload is the first, dense, cache-cold instruction fetch right after a cold reset, where margin is tightest — hence it fails most often there, while runtime fetches mostly hit cache and rarely trigger it.
We suggest the following checks, all software-side and requiring no PCB test points:
Start with dummy cycles. Verify that the dummy-cycle count in the read LUT strictly matches your Octal Flash datasheet spec at 166 MHz. If an auto-generated FCB (e.g., from the provisioning tool) uses a lower value, set it to the datasheet-specified value, and you may add 1–2 extra dummy cycles to widen the data-valid window and increase sampling margin. Insufficient dummy cycles place the first data beat in the turnaround/not-yet-settled region — a classic source of intermittent errors.
Verify the read sample-clock source . 166 MHz is only in-spec when readSampleClksrc=3 (kFlexSPIReadSampleClk_ExternalInputFromDqsPad: read strobe/DQS provided by the Flash device). If it is currently 0 or 1, 166 MHz is out of spec, which is fully consistent with "133 MHz fixes it." Please confirm a real DQS trace exists on the PCB and use this mode.
If intermittent faults persist after these adjustments, you can run at 133 MHz as a safe baseline while isolating the 166 MHz margin bottleneck via steps 1–3 above. And this post may also help: https://community.nxp.com/t5/i-MX-RT-Crossover-MCUs/Octal-flash-IS25WX256-dummy-cycles/m-p/2178828
Best wishes, Gavin
Re: MIMXRT1160 XIP fails randomly Error log or schematics sharing could be helpful, how about the failing rate till now? Re: MIMXRT1160 XIP fails randomly Hi @Gavin_Jia , I've tested the read command with different dummy cycles count, and the failure is still there. I've set the number of dummy cycles in the flash volatile register to 20 so that it can support 166 Mhz. According to the flash datasheet it should support up to 200 MHz with 20 dummy cycles. readSampleClksrc=3 is set by the bootROM, confirmed with debugger connected. The DQS trace does exist. Sometimes the fault happens while application is running, after the first major flash read. Re: MIMXRT1160 XIP fails randomly Hi @tbonkers ,
Thanks for the detailed testing. Based on your findings, this is most consistent with the 166 MHz Octal DDR XIP read path operating at the edge of its sampling / signal-integrity margin.
readSampleClksrc=3 and the DQS trace are necessary but not sufficient conditions: in DDR DQS mode, the RT1160 side still requires the DQS-to-SIO relative skew to stay within ~±1 ns, and 166 MHz is the interface's upper limit, so margin is minimal.
I’ve looked into more resources, and the following solutions may help you resolve the current issue without modifying the PCB:
Apply DLL errata ERR011377. The RT1160 errata states that after the DLL lock-status bit is set, an immediate read/write to the external flash may still return wrong data due to a timing issue; the workaround is to wait at least 512 FlexSPI root-clock cycles after the lock bit is set before accessing flash. Please ensure this delay is applied in every path in the bootloader and application that reconfigures FlexSPI/DLL/clock — this fits well with "most frequent at chainload, intermittent at runtime."
Run a quantifiable RAM-resident stress test (more effective than repeated power-cycling). Place the test code and fault handler in ITCM/OCRAM, repeatedly read large flash blocks from the AHB memory map with CRC comparison, sweeping 166/133/120 MHz. If the error rate drops sharply as frequency decreases, it confirms a timing/SI-margin issue.
For the mcuboot case: if the bootloader ever erased/programmed the external NOR, you must invalidate I/D-cache before jumping to the application; also confirm the application does not re-initialize FlexSPI with different clock/DLL/LUT/pad settings.
If in the end only 166 MHz fails while 133 MHz is stable, we recommend 133 MHz as the safe operating frequency for the current board; if 166 MHz is mandatory for production, the PCB DQS/SCLK/SIO length-matching, impedance, crosstalk, and pad drive strength should be reviewed, with test points added for these signals in the next revision.
Best regards, Gavin
記事全体を表示
