FW Mem GuardBring two completed builds
Select the baseline Map and matching ELF, then the current pair. Guided setup checks structural agreement and shows region coverage in both builds.
Firmware memory · VS Code · Local processing
Your build grew.
Know by how much.
Compare Flash and RAM between firmware builds. See the change. Check the budgets you choose.
Free pre-release · Windows x64 · Mac Apple Silicon & Intel
Build comparisonBUNDLED DEMO
BUDGET_EXCEEDED
FLASH+51,200 B
720,896 → 772,096 bytes
RAM+27,136 B
176,640 → 203,776 bytes
Flash growth limit · 16,384 BEXCEEDED
RAM growth limit · 4,096 BEXCEEDED
Actual engine results from the bundled example, intentionally over budget. This card illustrates the result; it is not a VS Code screenshot. Bars show current usage against the demo total limits.
Runs on your computerNo FW Mem Guard account or cloud comparison service.
You set the limitsMaximum usage and allowed growth, separately for Flash and RAM.
Sharing is your choiceNo telemetry or automatic report upload.
Real firmware · Independently checked sections
Measured on MicroPython.
MicroPython v1.24.1 on NUCLEO_F411RE: GNU objdump section totals match the FW Mem Guard 0.3.3 source-engine result, including a RAM-resident vector table and heap/stack reservations.
| Memory | GNU objdump delta | FW Mem Guard delta | Difference |
|---|---|---|---|
| Flash | +8,240 | +8,240 | 0 |
| RAM | +4,096 | +4,096 | 0 |
Verified against the supplied Map/ELF pair using GNU objdump 2.44 and the 0.3.3 guided-validation and engine source. This check did not rebuild or execute the firmware, or test the VS Code interface.
See the evidence and try the guided example →From build artifacts to a decision
Set up once. Compare after a build.
Designed for supported GNU Arm firmware layouts: GNU ld Map + ARM ELF32 little-endian, with one active Flash and one active RAM region.
Make growth visible
Confirm your Flash/RAM regions and four budget limits. Compare allocated section bytes and see which limits passed or failed. Repeat using the saved project.
Keep control of the report
Export a reduced JSON snapshot to an unsaved editor tab. Review it before Save As. Paths, filenames, symbols and addresses are excluded; usage and limits remain visible.
See the result before using your firmware
A memory regression, in 20 seconds.
A captioned, illustrated walkthrough of the bundled demo. Numbers come from the actual engine and export functions. No customer files or recorded VS Code interface are used.
Try the same example in VS Code
- Install the pre-release and open a trusted folder.
- Run
FW Mem Guard: Run Demo. - Expect
BUDGET_EXCEEDED: both growth limits fail intentionally. - Run
Export Report for Sharing. Review the new tab before saving.
The demo uses a bundled manual profile. Guided Map/ELF setup is a separate workflow for your supported project.
Public help. Offline help, too.
Get started in your language.
Already installed? Run FW Mem Guard: Open User Guide. English, Hebrew and Support open locally inside VS Code, even offline.
Check the fit
Clear scope. Useful answers.
Which systems and build formats are supported?
Windows x64, macOS Apple Silicon and Intel, and guided WSL input access on Windows. Mac native command-line and package checks passed on macOS 15.7.9; compatibility with macOS 13/14 and interactive VS Code installation on those systems has not yet been validated. The extension needs VS Code 1.85 or later and a trusted workspace. Guided setup supports GNU ld Map + GNU Arm ELF32 little-endian and one active Flash/RAM pair. Linux native, Remote-SSH, Dev Containers, Codespaces, IAR/Keil and multiple active memory banks are not supported.
Why did the Mac instructions say macOS 15+?
The 0.3.3 package metadata and bundled guide use 15.0 as the declared target, matching the build-host policy. Inspection of every bundled Mach-O binary found lower deployment targets: 11.0 for Apple Silicon and 10.13 for Intel. Those headers alone do not establish whole-extension compatibility. Our native CLI/package checks ran on macOS 15.7.9; macOS 13 and 14 remain unverified.
What exactly is being measured?
Allocated output-section bytes, not runtime peak memory. Initialized RAM is counted in RAM and its Flash load image. Heap/stack reservations are not measurements of live heap/stack use. Object and symbol attribution are not available. Structural Map/ELF agreement does not prove common build provenance; select matching completed builds.
Does firmware leave my computer?
FW Mem Guard processes inputs on the local host and has no automatic cloud upload. In WSL mode, full selected Map/ELF files move through VS Code to the Windows host. If you choose to share an export yourself, your chosen service and recipient receive it. Read the privacy details.
Why does the demo fail its budgets?
The bundled example intentionally grows Flash by 51,200 bytes against a 16,384-byte growth limit, and RAM by 27,136 bytes against a 4,096-byte growth limit. Both total-usage checks pass. The resulting BUDGET_EXCEEDED is the expected demonstration, not an installation error.
How can I help improve the pre-release?
Tell us the first step that blocked you or what would make the comparison more useful. The support guide explains what to include. Share only reviewed diagnostics; memory totals and limits can still be sensitive. There is no telemetry.
Try the example. Then your build.
Start with the bundled demo; no firmware files are needed for that first run.
Open FW Mem Guard in Marketplace