Local coverage, firmware and Notebook deliveries
Read LCOV counts, merge sparse Intel HEX addresses and clear Notebook outputs locally. Review complete downloads, supported limits and receiver checks.
Choose the artifact contract that answers your task
Use the LCOV report when a test runner already produced coverage data and you need readable totals. Use HEX address merging when bootloader and application exports must coexist at known addresses. Use Notebook output cleaning when saved display data makes the original difficult to open and you need its code. None of these tools runs the test suite, flashes a device or executes Notebook cells.
Select original files before running. Downloads contain the complete successful result; the table preview shows at most 200 records or segments/cells. Keep the original beside the result so a receiver can repeat the review.
| Task | Supply | Download and receiver check |
|---|---|---|
| LCOV offline report | One complete LCOV 1.x tracefile | HTML/JSON/CSV; compare counts to the test runner |
| Intel HEX merger | Nonoverlapping original HEX files | Canonical HEX/address-map JSON/CSV; compare addresses in the firmware tool |
| Notebook output cleaning | nbformat 4 minor 0–5 .ipynb | Cleaned copy/source manifest/CSV; compare source and attachments in Jupyter |
Read actual coverage and keep unknown branches visible
In the starter trace, DA contains three source lines, one with hits; FN/FNDA define two functions, one with hits. The two BRDA entries include one hit count and one “-”. The report is lines 1/3, functions 1/2 and branches 1/2, with one unknown branch. The missing branch count is not rewritten as zero.
LF/LH and the other declared summary counters are compared with actual coverage points. Stale but structurally valid counters remain visible as declared-versus-recomputed differences. A record with no functions has no function denominator and displays n/a, not 100%.
Source paths and function names are labels. The complete offline HTML escapes them, contains no executable script and never reads the named source files. One record per exact source path is required; duplicate paths and newer FNL/FNA/FN end-line/MC-DC extensions reject. Export a supported trace from the producer rather than deleting meaningful records.
Resolve address ownership before merging firmware exports
A valid HEX record carries count, address, type, data and a record checksum. Every file must end with one EOF. The merger supports records 00–05, extended segment/linear bases and either CS:IP or EIP start metadata. A checksum-valid record can still conflict with another file.
Any repeated stored address rejects the entire merge, even if both bytes are identical. Different start-record kinds or values also conflict. Resolve ownership in the linker/build inputs before retrying; a failed run has no partly merged download.
Sparse storage does not fill address gaps. A byte at 0xFFFFFFFF is a one-byte segment ending exclusively at 0x100000000, not a 4 GiB allocation. The full address-map JSON contains exact segment bytes; its bounds and the receiving firmware tool must agree. The tool does not validate target Flash layout, boot behavior, application CRC or firmware authenticity.
Recover Notebook source without rendering saved outputs
The cleaner parses the Notebook as data, validates supported cells/outputs and removes code-cell outputs plus execution_count. It does not render HTML/JavaScript MIME data or start a kernel. An explicit option controls root metadata.widgets; all other metadata and Markdown/raw attachments remain.
Source string versus string-array representation, cell order, IDs, CRLF and Unicode are retained. Metadata integers and decimals retain their original number tokens, including 123456789012345678901234567890 and 1.2345678901234567890123456789. JSON formatting can change; the original file is never overwritten.
cell-sources.json records every original cell source and a SHA-256 of joined source encoded as UTF-8. Check that the cleaned copy and manifest contain the code you expect before executing it elsewhere. Lone surrogate source code units reject instead of silently changing a UTF-8 hash. Outputs removed does not mean secrets removed: source, attachments and timing/trust/custom metadata may still contain sensitive data.
Use the complete budgets and recover deliberately
A supported input can still exceed computation or combined output limits. Large retained Notebook content, exceptionally many HEX segments or long LCOV names may produce oversized artifacts. Output-limit failure supplies no partial result.
| Tool | Input | Additional limits |
|---|---|---|
| LCOV | One selected/pasted trace ≤5 MiB | 50000 coverage points;1000 records; total output10 MiB |
| Intel HEX | Up to64 files, combined≤2 MiB | 50000 records;1 MiB stored bytes; total output10 MiB |
| Notebook | Selected≤64 MiB; paste≤8 MiB | 200000 JSON values;depth128;10000 cells; total output10 MiB |
- For LCOV syntax problems, match FN/FNDA names and complete every end_of_record; counters are recomputed separately.
- For HEX failure, correct checksums/lengths/EOF or resolve overlapping regions and entry metadata in the producer.
- For Notebook failure, use a complete supported version, valid structural fields and unique minor-5 IDs. After cancellation, rerun the original or a smaller supported file.
- Only partition artifacts if the meaning of the task survives. Renaming a file extension or discarding unknown records is not a format conversion.
References
- Flutter LCOV report question
Task source: an actual exported lcov report needs readable coverage; no demand-scale estimate.
- Bootloader/application HEX merge question
Task source: two firmware exports must merge. Browser output does not automate Eclipse or prove flash suitability.
- Open a Notebook without rendering outputs question
Task source: saved image/DataFrame output makes opening consume excessive memory while code must remain. No performance guarantee inferred.
- Official LCOV project
Correctness source only; supports the scoped 1.x trace contract, not new extensions.
- IntelHex merge reference
Correctness/independent-reader source, not demand evidence.
- Jupyter nbformat description
Correctness source; no cell execution or PII-removal guarantee.
Tools in this category
Expand a tool to see its steps, options and supported formats, then open its workspace.
LCOV offline coverage reportRead one local LCOV 1.x tracefile, recompute coverage totals, retain unknown branches and download a complete offline HTML report.
Review coverage exported by your test runner without reading source paths. Inspect the real line/function/branch counts, compare stale declared counters and keep a standalone HTML report beside the tracefile.
Steps
- Paste or open one complete LCOV 1.x tracefile from the test runner.
- Check recomputed totals, unknown branches and declared-versus-actual summary differences.
- Download coverage.html plus complete JSON/CSV. Open HTML locally and retain the original tracefile.
Available options
- Protect CSV formula-like text
- On by default
Capabilities and limits
- One UTF-8 file or pasted tracefile up to 5 MiB, 50,000 coverage points (DA + FN + BRDA) and 1,000 complete source records. One record per exact source path; duplicate paths reject instead of silently merging test contexts. Selected file takes precedence. Total downloads up to 10 MiB; table preview first 200 records.
- Supports LCOV 1.x TN, SF, FN, FNDA, DA, BRDA, LF/LH/FNF/FNH/BRF/BRH and optional VER. FNDA and FN order may differ; every function needs both location and count. Counts and branch identifiers are nonnegative uint64; source lines are 1–2147483647. DA checksum, when supplied, is 32 hexadecimal characters. New FN end-line, FNL/FNA and MC-DC extensions reject.
- Coverage totals are recomputed from actual points. Declared summary differences stay visible in the report; they do not become the denominator. BRDA “-” remains unknown, contributes to found branches and is never changed into a hit count of zero. A zero denominator is n/a/null rather than 100%.
- Full HTML lists every point and summary difference, escapes all file/test/function text and contains no scripts or links that read source paths. JSON preserves uint64 hit counts as decimal strings. CSV contains every source record; spreadsheet protection may prefix formula-like labels. No source fetching, tracefile merging, test execution or coverage measurement.
Intel HEX address mergerMerge local Intel HEX 00–05 files by sparse 32-bit addresses, checking record checksums, overlaps and entry-point conflicts before output.
Combine bootloader and application HEX exports only when their stored address bytes do not overlap. Review complete segments and entry metadata, then deliver canonical HEX and a sparse address map without filling large address gaps.
Steps
- Select the original bootloader/application HEX files, or paste one complete HEX file for inspection.
- Check stored ranges, segment bounds and retained entry-point kind; any overlap fails before a download.
- Download merged.hex, the complete address-map JSON and segment report. Verify the result with the receiving firmware tool before flashing.
Available options
- Protect CSV formula-like text
- On by default
Capabilities and limits
- Paste one HEX file or select up to 64 UTF-8 files, combined at most 2 MiB. Selected files take precedence. At most 50,000 nonempty records and 1 MiB stored bytes; sparse addresses are independent of their span. Total complete artifacts up to 10 MiB; segment preview first 200.
- Supports records 00 data, 01 EOF, 02 extended segment address, 03 CS:IP start, 04 extended linear address and 05 EIP start. Count, checksum, record address and type-specific length must be exact. Every file needs one EOF; later records, invalid hex/whitespace, duplicate start records and unknown types reject. Empty lines and an optional leading UTF-8 BOM are accepted.
- Addresses range 0x00000000–0xFFFFFFFF. Data that exceeds this range rejects. Any repeated stored address, even with the same byte, rejects the entire merge. One compatible entry-point declaration is retained; different kinds or values conflict. No partial result is supplied on failure.
- Output uses 16-byte data records with extended linear bases and retains the start-record kind. Address-map JSON contains every contiguous segment and its exact hex bytes; report/CSV provide complete segment bounds with exclusive ends (0x100000000 is permitted as an end). No gap filling, hardware flashing, target suitability, firmware-signature authentication or application CRC validation.
Notebook output cleaner and source recoveryRemove outputs and execution counts from a local nbformat 4 notebook while preserving cell source, attachments and precise metadata numbers.
Recover code from a notebook made difficult to open by large display outputs. Remove saved output data without rendering it, choose the root widget-state policy explicitly, and download a cleaned notebook plus an indexed source manifest.
Steps
- Open the original .ipynb without rendering its outputs, or paste a small supported notebook.
- Choose whether root widget state should be removed and check the removed-output and execution-count summary.
- Download cleaned.ipynb and cell-sources.json. Open the cleaned copy in Jupyter and verify source/attachments before executing anything.
Available options
- Remove root metadata.widgets state
- On by default
Other metadata and attachments remain; this is not automatic sensitive-data removal.
- Protect CSV formula-like text
- On by default
Capabilities and limits
- One selected UTF-8 .ipynb file up to 64 MiB or pasted JSON up to 8 MiB. Selected file takes precedence. nbformat 4 minor 0–5, at most 200,000 JSON values, depth 128 and 10,000 cells. All downloads together at most 10 MiB; first 200 cells appear in the table. Large retained source/attachments/metadata can still exceed output limits.
- Supports code, Markdown and raw cells, plus saved stream/error/display_data/execute_result outputs. Structural fields, unique IDs for minor 5, source representation and recognized metadata fields are validated; duplicate JSON keys, future cell/output types, unknown structural extensions and unsupported format versions reject. Arbitrary custom metadata remains data. Lone surrogate code units in joined cell source reject rather than changing its UTF-8 hash.
- Clears every code cell outputs array and sets execution_count to null. The explicit option controls only root metadata.widgets. Source string/array representation, cell order, IDs, CRLF/Unicode, Markdown/raw attachments, other metadata and original large integer/decimal number tokens are preserved. JSON formatting changes; original file is never overwritten.
- No MIME rendering, script/cell execution, kernel start or automatic PII removal. Preserved source, attachments, timing/trust/custom metadata may still contain sensitive information. Cell-source JSON retains exact source representation and SHA-256 of joined source encoded as UTF-8; it does not claim the notebook has run or passed tests.