Embedded Firmware Development & BSP Engineering
JUZHITECH develops embedded firmware alongside board-level hardware — from board Support Packages (BSPs), peripheral drivers, and RTOS integration to bootloaders and production test firmware. Our hardware–firmware co-design approach helps streamline board bring-up, debugging, and manufacturing validation.
Architecture-Agnostic
We write firmware at the register level. The ISA and peripheral architecture determine feasibility — not the logo on the chip.
ARM Cortex-M
ARM Cortex-A / MPU
RISC-V & Xtensa
Specialized & FPGA-SoC
The Gap
Pure software teams fail at the hardware boundary. They assume a perfect board that doesn't exist.
When a pure software firm ports an application to a custom board, they write against the MCU reference manual. But if the physical board uses a different external crystal load capacitance than the dev kit, the clock tree initialization locks up on 10% of units at cold boot. If the OTA update partition isn't aligned with the physical sector size of the substituted flash chip, devices brick in the field.
These are not coding errors. They are hardware-firmware boundary disconnects. When the prototype hangs during an interrupt, the software team blames the hardware, the hardware team blames the code, and your project stalls in a debugging loop.
How We Close It
Hardware-firmware co-design. We debug with oscilloscopes, not just printf().
Our firmware engineers sit next to the hardware layout team. Clock tree configuration is validated with an oscilloscope against the actual crystal on the physical board. Pin-muxing constraints are negotiated before the PCB is routed. Flash partition tables are verified against the exact flash chip lot code that sourcing procured.
By owning both the schematic and the Board Support Package (BSP), we eliminate the hardware-firmware boundary. When a bootloader fails to hand off on 3% of units, we don't file a Jira ticket — we walk to the lab bench and scope the reset vector. We isolate the bug to the code or the copper.
Are you an AI team deploying models to edge devices, or a SaaS company building a companion hardware product? In a JDM engagement, you own the proprietary application layer and IP. We own the PCB design, the BSP, low-level drivers, and manufacturing. We hand you a clean API and a flashing board. You ship a physical product without building an internal hardware division.
How Joint Design (JDM) Works →Co-Design
Hardware-software co-design — the firmware review that happens before the PCB is routed, not after.
Most firmware-blocking hardware issues are preventable at the schematic stage. Our firmware engineers audit every schematic before layout freeze.
Pin muxing and boot strapping — reviewed before copper.
The most common bring-up failure is a pin conflict: assigning a peripheral function to a pin that the boot ROM uses for strapping. Our firmware engineers review the pin mux table alongside the schematic, verifying that every required interface (UART for console, SWD for programming, SPI for flash) is routable. Boot configuration pins — BOOT0, BOOT1 — are checked against the silicon reference manual, not just a dev kit schematic.
Programming and debug access — designed in, not hacked on.
A board that cannot be reliably programmed is a brick. We ensure every PCB includes a dedicated programming header — SWD for ARM Cortex-M, JTAG for complex SoCs — with the physical reset line exposed. For mass production, we specify gang-programming interfaces and ICT test point locations that mate perfectly with our factory's pogo-pin fixtures.
RTOS Selection
Bare-metal or RTOS — the decision that shapes your firmware architecture.
The choice between bare-metal, FreeRTOS, and Zephyr is dictated by task concurrency, RAM footprint, and hardware abstraction requirements — not developer preference.
| Approach | Scheduler | RAM Footprint | Driver Model | Best For |
|---|---|---|---|---|
| Bare-Metal C | Super-loop + ISRs | ~2–8 KB | Register-level, manual | Single-function MCUs, sensor nodes, LED drivers, simple state machines under 3 concurrent tasks |
| FreeRTOS | Preemptive, priority-based | ~8–20 KB | Vendor HAL + custom drivers | Multi-peripheral IoT devices, BLE/Wi-Fi gateways, HMI controllers, industrial sensor aggregators |
| Zephyr RTOS | Preemptive, tickless | ~20–60 KB | Device Tree + unified driver model | Multi-protocol wireless, complex BLE mesh, products requiring portable code across silicon vendors, safety-critical applications |
The RTOS decision is made during architecture — not after schematic capture. FreeRTOS on an MCU with 16 KB of RAM leaves nothing for your application stack. Zephyr on a product that only reads a temperature sensor and blinks an LED is 40 KB of scheduler you didn't need. We match the RTOS to the product specification, not to the engineer's resume.
BSP Development
Board Support Package — from first power-on to a stable API.
The BSP is the physical abstraction layer. Done correctly, your application logic remains entirely decoupled from the underlying silicon revision.
Clock tree and power sequencing — the first code that runs.
Before main() executes, the startup assembly configures the clock tree and enables power domains. We methodically verify this sequence: external crystal frequencies are confirmed via CLKOUT pins, PLL lock times are measured against the datasheet, and the power-up sequence of each PMIC rail is checked with a logic analyzer.
Peripheral drivers — abstracted for supply chain resilience.
We write drivers against a Hardware Abstraction Layer (HAL). If a component shortage forces a swap from an STM32F4 to a GD32F4, the application's I2C calls do not change — only the underlying HAL implementation changes. This is supply chain resilience implemented directly in the firmware architecture.
Board-level validation — firmware that tests the hardware.
Every BSP includes a built-in self-test (BIST) routine. GPIOs are tested for input leakage, ADCs are verified against known voltage references, and buses are loopback-tested. This validation firmware proves the prototype and immediately translates into the Functional Test (FCT) sequence for mass production.
Bootloader & System Architecture
System architecture — the foundation that determines field reliability.
Secure boot — trust begins at the reset vector.
A bootloader that executes unverified code is a critical vulnerability. We implement cryptographic signature verification (Secure Boot) using hardware crypto accelerators (AES/RSA/ECC) to prevent latency penalties. Public keys are burned into one-time programmable (OTP) memory. For OTA (Over-The-Air) updates, we utilize dual-bank A/B flash partitions with automatic rollback if the new image fails to boot.
Memory map and linker scripts — controlling the physical boundaries.
We manually architect the memory map via custom linker scripts. We define specific Memory Protection Unit (MPU) guard regions to catch stack overflows instantly. Tightly Coupled Memory (TCM) is strictly allocated to critical interrupt service routines, not wasted on initialization code.
A stack that reaches 90% utilization under normal operation leaves no margin for the deepest call path in your interrupt nesting sequence. We measure worst-case stack depth with hardware breakpoints on the stack pointer during stress testing — not with a static analyzer's estimate. The difference is the margin between a product that runs for three years and one that resets randomly every two weeks.
Reliability mechanisms — independent watchdogs.
A watchdog fed from a software timer is a false sense of security. We deploy Independent Watchdogs (IWDG) clocked from a physically separate low-speed internal oscillator. If a hard fault occurs, a custom fault handler saves the core register context (PC, LR, stack pointer) to non-volatile memory before triggering a reset, enabling post-mortem crash analysis on field returns.
Production Firmware
Production test firmware — code engineered for the factory floor.
Development firmware proves the concept; production test firmware guarantees the yield.
FCT firmware — optimized for cycle time.
Functional test (FCT) firmware must be ruthless about speed. On a line producing 1,000 units a day, a 5-second test delay destroys throughput. Our FCT firmware boots in milliseconds, communicates with automated test fixtures via UART or CAN, and outputs structured measurement telemetry — not just binary pass/fail signals — allowing our process engineers to detect voltage drift before it becomes a yield failure.
Calibration routines — baked into the test sequence.
ADC offsets and internal oscillator trims vary per silicon wafer. Our FCT firmware executes automated calibration routines on the FCT fixture. The fixture injects a golden reference signal, the firmware calculates the offset, and burns the calibration values into EEPROM or Flash.
Common Questions
Embedded firmware development FAQ
Do you write bare-metal firmware or use an RTOS ?
Both — the decision is dictated by the hardware budget and concurrency requirements. We use Bare-metal C for single-function endpoints with strict timing loops and under 4 KB of RAM. We deploy FreeRTOS for general IoT gateways and wearables. We utilize Zephyr for multi-protocol environments demanding a unified device tree.
How do you ensure firmware reliability in production ?
Reliability is architected, not just tested. We implement independent hardware watchdogs (IWDG) running on separate oscillators, deploy MPU guard regions to catch stack overflows, and write hard-fault handlers that dump register context to flash prior to a system reset for field debugging.
What happens if the firmware team finds a hardware issue during bring-up ?
They walk to the hardware engineer’s desk — they don’t open a Jira ticket. Because our firmware and hardware teams share a lab, a clock tree that won’t lock is scoped with an oscilloscope within the hour. If a PCB layout revision is required, the feedback loop takes hours, not weeks.
Do you develop production test firmware for the factory line ?
Yes, and this is where software-only studios fail. We write dedicated FCT firmware that executes lightning-fast self-tests and communicates directly with our factory’s automated test fixtures. It handles ADC calibration, GPIO leakage testing, and writes the test results to the factory database.
Which MCU platforms do you support ?
We have delivered production firmware on STM32 (Cortex-M0 through M7), i.MX RT (Cortex-M7), ESP32 / ESP32-S3 (Xtensa LX6/LX7), nRF52 / nRF53 (Cortex-M4/M33), TI CC26xx / CC13xx, RISC-V (GD32V / BL602), and NXP LPC / Kinetis families. If your design uses a different MCU, we evaluate the platform during the architecture phase — the peripheral set, toolchain maturity, and SDK quality determine feasibility, not the brand on the chip.
How We Deliver
Firmware engineering available through two engagement models — from co-development to full turnkey.
Joint Design (JDM)
Your application team + our BSP and driver engineers — co-develop the firmware with hardware bring-up support. Source code transfers to you.
Explore JDM →Full Turnkey ProductTurnkey ODM
You define requirements — we own the full firmware development, hardware integration, production test, and lifecycle under one roof.
Explore ODM →Already have a complete schematic and BOM? Send your design files for manufacturing — DFM review, sourcing, and SMT assembly without design work.