Embedded Firmware Development Support & Testing for Connected & Implantable Devices

Firmware for a connected or implantable medical device is held to a different standard than firmware for a consumer gadget, for one simple reason: unpredictable behavior can translate directly into patient harm. That's what verification has to confirm: determinism — the same input, and the same fault, always producing the same, predictable behavior — and graceful degradation, where a fault puts the device into a known safe state instead of an undefined one. Interrupt handling, timing guarantees, and memory usage all have to be tested against the bounds defined at design time, because "it worked on the bench" isn't verification evidence.

Almost no embedded medical device is built from scratch — an RTOS, a BLE stack, a cryptography library, a driver from a chip vendor. IEC 62304 has a specific category for exactly this: SOUP (Software of Unknown Provenance) — software not developed for the specific purpose of being incorporated into the medical device, or for which adequate development records don't exist. SOUP items have to be explicitly identified, their known anomalies and limitations documented, and their risk to the system evaluated — a BLE stack or RTOS can't just be dropped in and assumed safe because it's widely used elsewhere. We help teams run that assessment and document it as part of the verification record.

Wearable and implantable devices add constraints that don't show up in mains-powered equipment: battery life measured in months or years, persistent memory that has to survive power loss without corruption, and no technician nearby to power-cycle a frozen device. That's what testing has to specifically target:

• Confirming watchdog timers correctly detect a hung system and force recovery to a known state.
• Verifying wear-leveled, power-fail-safe writes to flash/EEPROM under simulated power loss.
• Exercising state machines against every fault path, not just the happy path — because in an implantable device, a hang isn’t an inconvenience, it’s a hazard.

Firmware verification follows the same IEC 62304 classification logic as the rest of the software: the higher the safety class, the more rigorous the verification has to be. For embedded C/C++ specifically, that means unit testing with hardware abstracted out through mocking — we use Ceedling/CMock for this — so logic can be verified without needing physical hardware in the loop for every test run, and VectorCAST where a project's classification or a client's existing toolchain calls for it.

For Class B and C software, that verification is tied back to documented requirements and produces the coverage and traceability evidence the classification requires; for Class A, the same testing infrastructure is used without the full documentation overhead a higher class would demand. See how classification drives verification depth.