MCU Firmware Development Services

Bare-metal and RTOS firmware for ARM Cortex-M, RISC-V, and 8/16-bit MCUs. Industrial protocols, secure bootloaders, and ultra-low-power designs — built to last.

Discuss Your Firmware →

Firmware Development Advantages

Firmware Architecture and Design Philosophy

Good firmware is invisible — it just works, year after year, across thousands of deployed units. Achieving this requires a disciplined design philosophy that prioritizes correctness, maintainability, and defensive programming over cleverness. At InnovChip, every firmware project begins with a software architecture document that defines the module hierarchy, data flow, state machines, interrupt priorities, and inter-task communication mechanisms before a single line of code is written. This up-front investment pays massive dividends during integration, testing, and future maintenance — especially when the original developers are no longer on the project.

Our firmware is organized into four distinct layers. The Board Support Package (BSP) layer contains all MCU-specific initialization: clock tree configuration, pin muxing, peripheral clock gating, and memory protection unit (MPU) setup. The Hardware Abstraction Layer (HAL) wraps every peripheral with a consistent, documented API — regardless of whether the underlying implementation uses vendor HAL libraries, CMSIS direct register access, or a custom LL driver. The Middleware layer houses protocol stacks, filesystems (FatFS, LittleFS), and encryption libraries (mbedTLS, wolfSSL). The Application layer implements your business logic as a collection of cooperating state machines or RTOS tasks with explicit entry/exit conditions and error handlers.

A critical architectural decision is the choice between bare-metal superloop and RTOS. For simple products with under 3-4 concurrent responsibilities, a well-structured superloop with interrupt-driven I/O is often the right choice — it has zero context-switching overhead, no RAM penalty for task stacks, and simpler debugging. For products with concurrent networking, UI, sensing, and control tasks, we recommend an RTOS with preemptive priority-based scheduling. We default to FreeRTOS for its maturity, extensive documentation, and safety certifications (SafeRTOS for IEC 61508 SIL 3). For projects requiring functional safety certification, we can work with ThreadX (now Eclipse ThreadX, certified to IEC 61508/62304/50128) or SAFERTOS.

Bootloaders and OTA Update Systems

Every connected product needs a secure, reliable way to receive firmware updates in the field. We design custom bootloaders that balance security, robustness, and flash footprint constraints. A typical implementation includes: a primary bootloader (4-8 KB) in the first flash sector with read-out protection enabled, which validates the application firmware’s CRC-32 / SHA-256 checksum before jumping to it. The OTA update client runs as an application task, downloading new firmware via MQTT or HTTPs with TLS 1.3, writing it to a secondary flash partition, verifying the signature, and setting a boot flag. On next reset, the primary bootloader copies the new image and boots it — with automatic rollback to the previous version if the new image fails to boot within a configurable watchdog window.

For memory-constrained MCUs without space for dual images, we implement delta/differential updates using bsdiff or custom binary patching algorithms that transmit only the changed bytes. This can reduce OTA payload size by 80-95% for typical firmware revisions, enabling updates over LPWAN links (LoRaWAN, NB-IoT) where bandwidth is measured in bytes per day.

Code Quality and Testing Discipline

Firmware bugs in deployed industrial products are expensive — they may require on-site technician visits, product recalls, or safety incidents. We invest heavily in prevention. All code is developed to MISRA-C:2012 guidelines (Mandatory + Required rules) with static analysis via PC-lint orcppcheck integrated into our CI pipeline. Unit tests execute on-target using Unity/CppUTest with mocked hardware peripherals. Integration tests run on real hardware in an automated test rack that simulates sensor inputs, communication traffic, and fault conditions. We also perform fuzz testing on protocol parsers to ensure they gracefully handle malformed packets without crashing or corrupting memory. Every firmware release includes a test report mapping each requirement to its verification method (analysis, test, or inspection).

Technologies We Master

Let’s Write Your Firmware

Send us your product spec or block diagram. We deliver clean, documented, and tested firmware — on time and on budget.

Contact Us Today →