This repository contains flash programming algorithms for i.MX RT MCUs. The algorithms are designed for use in probe-rs. They're written in Rust and support a variety of MCUs and flash parts.

These flash programming algorithms compete with NXP's flash programming algorithms, which are distributed in device family packs (DFPs). NXP's algorithms also work with probe-rs, so prefer those if you want something official (and probably better tested).

I've found these algorithms can program flash 2x to 3x faster than NXP's offerings. These algorithms definitely support page crossings; meaning, if the debug probe wants to program 4KiB into flash, the algorithm will automatically chunk it into pages of 256 bytes. This trick reduces I/O overhead between host and debug probe. (Admittedly, NXP's algorithms might support this, but I never tried. It's fun writing these algorithms!)

Supported boards include

• IMXRT1010EVK
• IMXRT1040EVK
• IMXRT1160EVK
• IMXRT1170EVK

You'll find the algorithms in their respective top-level directories. These four boards sport four different MCUs, which you'll also find in the top-level directories. Furthermore, those four boards have three different flash parts; the flash part implementation is in src/ as part of the core package.

Before attempting to generate the flash programming algorithms for probe-rs, install the target-gen tool. It's available in the probe-rs repository.

Use target-gen test to test each algorithm on its EVK. For convenience, there are dedicated Cargo configurations you can use. For example, to test the algorithm on a 1010EVK, run

cargo --config .cargo/1010evk.toml run --release --package=imxrt1010evk

To test on a different EVK, change the Cargo configuration and the package.

Here's how to generate the algorithm, represented as YAML, for the 1010EVK:

cargo --config .cargo/flash_algo.toml run --release --package=imxrt1010evk

To generate the algorithm for a different EVK, change the --package selection.

Each flash algorithm should know how to work with all supported flash parts. The algorithm figures out which flash part you're using and varies some configs based on the part.

Despite being somewhat dynamic, all flash parts are expected to support quad I/O for both reads and writes. The algorithm doesn't vary the kind of sequence its using. If your circuit doesn't use the additional I/O signals, you'll need to change the algorithm's source.

FlexSPI pin muxing assumes you're using the boot ROM's primary FlexSPI1 interface. In fact, all algorithms assume you're using FlexSPI1! If your board is doing something different, then you'll need to manually change the pin muxing / FlexSPI instance.

I should eventually change the way the sequences are represented and how the IP commands work. Right now, sequences that need a "write enable" have them in the sequence itself. (That might be expected; see the way NXP's boot ROM encodes the sequences.) Another approach is to have a dedicated "write enable" sequence that software issues before the erase / program / write status IP command. That would reduce sequence usage in the LUT. I haven't been LUT constrained, so no need to do this right now.

What to contribute? Send questions, thoughts, and commits via email.

License: APACHE-2.0