|
| 1 | +# Flashing via HID (CMSIS-DAP) |
| 2 | + |
| 3 | +When the web app has access to a HID connection to the board, it can flash |
| 4 | +the board via the hardware debugger interface. |
| 5 | +The PXT localhost server can proxy HID connections (over a WebSocket), |
| 6 | +and native apps can access HID via various custom APIs (which are |
| 7 | +likely to have lower latency than the HID proxy). |
| 8 | + |
| 9 | +This is generally done via |
| 10 | +writing a little flashing program to the RAM, then writing the page to be |
| 11 | +flashed to the RAM, and then running the program. For next page, one keeps |
| 12 | +the flashing program, but replaces the data. Internally, the DAPLink |
| 13 | +software on the @boardname@ does the same. |
| 14 | + |
| 15 | +The flashing via DAP over HID is quite a bit slower than the regular |
| 16 | +drag&drop kind. This is because of overheads of the DAP protocol |
| 17 | +and the limited throughput of HID (1 packet, of maximum 64 bytes, per millisecond). |
| 18 | +Additionally, the DAP protocol requires every HID packet to be acknowledged |
| 19 | +effectively halving the bandwidth. |
| 20 | +Thus, typical flashing speeds (using HID proxy) are around 14k/s, with a typical |
| 21 | +full flash taking 15s. Theoretical maximum is around 25k/s. |
| 22 | + |
| 23 | +A custom flashing protocol, like [HF2](https://github.com/Microsoft/uf2/blob/master/hf2.md), |
| 24 | +can achieve around 60k/s, however this would require updates of DAPLink software, |
| 25 | +and is still not very fast. |
| 26 | + |
| 27 | +## Partial flashing |
| 28 | + |
| 29 | +Instead, we take care to only flash the pages that have changed. |
| 30 | +In typical software development only a very small fragment of the program |
| 31 | +changes on every re-deployment. Additionally, most of the program is pretty |
| 32 | +much constant (two bootloaders, the softdevice, and the compiled C++ runtime). |
| 33 | + |
| 34 | +This is achieved by first deploying a small program which computes |
| 35 | +checksums of every page. Then, these checksums are read from the device |
| 36 | +and compared with checksums of pages of the `.hex` file to be deployed. |
| 37 | +Only pages which checksums that do not match are flashed. |
| 38 | + |
| 39 | +The particular checksum algorithm used is [Murmur3](https://en.wikipedia.org/wiki/MurmurHash#MurmurHash3). |
| 40 | +The algorithm is simplified by removing checks for unaligned data, or hashing |
| 41 | +the data length, since all blocks hashed are of the same, aligned length. |
| 42 | + |
| 43 | +The Murmur3 hash was chosen since it's very fast (around 4x faster than CRC32 and around |
| 44 | +15x faster than SHA256). Hashing the entire flash takes about 200ms. |
| 45 | + |
| 46 | +In fact, two 32 bit Murmur3 hashes (using different starting seeds) are computed in |
| 47 | +parallel, to produce a 64 bit checksum. |
| 48 | + |
| 49 | +## Hash length analysis |
| 50 | + |
| 51 | +Let's compute the probability of some people running into trouble because |
| 52 | +of hash collisions on pages. Assume: |
| 53 | +* uniform distribution of hashes |
| 54 | +* 10M users |
| 55 | +* each user programming for 50h, and flashing every 2 minutes, i.e., 1500 flashes |
| 56 | +* each flashing changing 10 pages |
| 57 | + |
| 58 | +With 64 bit hashes, the probability that a collision occurs |
| 59 | +`1 - ((2^64 - 1) / 2^64) ^ (1e7 * 1500 * 10)` which is `0.000016` |
| 60 | +(Bing says so; Google wrongly said `0`). |
| 61 | +With 32 bit, even with only 1M users we get `97%` probability of some collisions. |
| 62 | +The uniformity of hashes is questionable, but the `0.000016` |
| 63 | +gives us some wiggle room. |
0 commit comments