Firmware requirements, peripheral integration, task coordination, fault diagnosis and verification for microcontroller products. Start from the actual hardware and acceptance conditions before choosing an implementation.
Choose littlefs geometry by reconciling three contracts: the flash chip’s command boundaries, the driver’s accepted requests, and the filesystem’s configuration constraints. A program page, a minimum write unit, and an erase block can have different sizes. Copying one of those numbers into every configuration field can produce a mountable system that later damages data. The…
A small application write can trigger work unrelated to the number of new payload bytes: finding free blocks, compacting metadata, completing consistency work, or waiting for flash operations. Budget the complete storage operation on an aged, occupied filesystem. A timing run immediately after formatting is a useful baseline, but a weak release test. This procedure…
To use littlefs without heap allocation, provide the mount’s read, program, and lookahead buffers, then give every simultaneously open file its own cache and persistent file configuration. Bound the number of open files explicitly. A static mount buffer alone does not make the complete storage path allocation-free. This article targets the upstream littlefs v2.11.2 C…
Check the image’s recognized feature flags against the exact loader build before interpreting a rejection as an authentication failure. MCUboot v2.2.0 has a header-admission gate that rejects unsupported encryption or compression features and certain contradictory flag pairs. Passing that gate only permits further processing. This article examines boot_is_header_valid() in the tagged ordinary loader and the…
Require a complete expected field set and a successful producer result before treating shared boot information as a complete report. A valid-looking prefix can survive a later append failure. In MCUboot v2.2.0’s default in-memory writer, blindly repeating the whole report can then encounter a duplicate entry rather than fill the missing fields. This guide examines…
Compare diagnostic and release builds by the behavior each configuration difference changes, not by their labels. A logging-only difference, an authorization-policy difference and a fault-hardening difference need different evidence. Passing the same ordinary bad-signature test does not establish that two binaries retain the same hardening. This guide pins MCUboot v2.2.0’s Zephyr fault-injection-hardening profiles as a…
Choose the signing boundary from who may change calibration, when it may change and which firmware interprets it. Embedding calibration in a signed firmware image couples every permitted adjustment to that image’s release process. A separate record can support independent service, but its consumer must enforce authorization, applicability and semantic limits. This article provides an…
Treat a previous verification result as stale whenever its assumed image, trust policy or protected state can change without invalidating that result. First establish that the implementation actually reuses approval. A marker that says “checked before” is different from fresh authentication of the current bytes. This guide examines a concrete optional mechanism: MCUboot v2.2.0’s Zephyr…
Match a direct-XIP image’s placement metadata to the exact slot-offset convention used by the deployed MCUboot port. Then qualify executable correctness and authentication separately. A valid signature cannot repair a slot-specific image installed at the wrong execution location. This guide pins MCUboot v2.2.0’s direct-XIP loader and image-tool header generation. It is a placement review, not…
Read both slot trailers, decode their semantic states and apply the selected mode’s rules in order before calling a revert an image failure. An unconfirmed trial can request a revert even when its executable bytes are valid. Conversely, a swap request is not proof that the candidate will pass validation. This guide pins MCUboot v2.2.0,…