mckero
1364d46e97
assets/flash.img was gitignored, so the only copy of the never-booted image lived on one disk. The emulator writes to that image, so a session can leave edited settings or a damaged EEPROM behind with nothing to restore from. assets/pristine/ now holds the image as first generated, gzipped and checksummed, and is tracked deliberately. Gzip takes it from 2 MiB to 2.3 KiB because the image is nearly all 0xFF, which is what makes keeping it in git reasonable. The live image and its .bak-* files stay ignored. Two checksums are recorded, for the archive and for its contents, so a corrupted archive is distinguishable from one that was replaced. tools/restore_flash.sh verifies, diffs, or restores. Restore backs up the current image first, then re-checks the result, since a restore that silently half-worked would be worse than none. Verified by deliberately corrupting the live image: --diff reported 32 differing bytes, restore backed up and rewrote it, and --diff then reported no change. The image is currently byte-identical to what make_flash.py produces, so this is the genuine original rather than a copy of something already used.
Simulator assets
calibration.bin — 512 bytes
A calibration dump from the user's own radio. Loaded into the virtual SPI flash
at physical 0x010000, which is where App/driver/eeprom_compat.c maps the
512-byte calibration block (_MK_MAPPING(0x010000, 0x00B000, 0x00B200)).
Without it the firmware takes error branches in the frequency and power paths, so the machine would boot into a state that does not represent the real radio.
Verified contents
Checked against the offsets SETTINGS_LoadCalibration() actually reads:
| Offset | Field | Value | Sanity |
|---|---|---|---|
| 0x000–0x0BF | per-band TX power curves | 10 ascending bytes per row, 0xFF padding | plausible power steps |
| 0x0C0 | gEEPROM_RSSI_CALIB[3] |
110, 120, 130, 140 | ascending |
| 0x0C8 | gEEPROM_RSSI_CALIB[0] |
180, 190, 200, 210 | ascending |
| 0x140 | gBatteryCalibration (6×u16) |
1426, 1978, 2125, 2155, 2271, 2600 | strictly ascending, matches a Li-ion curve |
47% of the file is 0xFF, consistent with a real dump: each power row uses 10 of its 16 bytes and the remainder is erased flash.
The file name the user supplied said "not necessarily accurate"; the structure above is self-consistent, so it is being treated as usable. If the emulated radio later shows implausible power or battery readings, this is the first thing to re-dump.
How to refresh
Export from a real radio with UV Studio (Dump Calib), then replace this file.