1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
|
This repository contains [flash programming algorithms][fpa] 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.
[fpa]: https://open-cmsis-pack.github.io/Open-CMSIS-Pack-Spec/main/html/flashAlgorithm.html
[probe-rs]: https://probe.rs
[probe-rs-fork]: https://github.com/mciantyre/probe-rs
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
|
