Embedded Firmware & Security

Over-the-air (OTA) firmware updates are often presented as a feature. In practice, they are an architectural commitment. Almost every IoT roadmap includes OTA updates early on. During prototyping, the mechanism appears straightforward: push a new binary, reboot the device, and move on. For small fleets and controlled environments, this approach seems sufficient. The problems begin after deployment—when devices are distributed, connectivity becomes unreliable, versions diverge

If you’ve ever deployed an IoT product in the real world — not a prototype, not a dev kit, but a real commercial device installed inside walls, mounted on poles, stuck inside machines, or screwed into ceilings — you know the feeling. The moment the device leaves your lab, a clock starts ticking. Something will change. Something will drift. Something will need updating. Maybe it’s a bug you didn’t notice. Maybe it’s a sensor offset you couldn’t predict. Maybe it’s a machine-le

There’s a strange tension you feel the first time someone asks,“Can our IoT product be quantum-safe?” On one hand, it sounds like a marketing question.A buzzword tossed around by people who haven’t spent a day in firmware development.Quantum computers, cryptanalysis, lattice problems — these things feel oceans away from a microcontroller that’s struggling to fit a LoRaWAN stack and a couple of timers. But on the other hand, something deeper kicks in — a quiet awareness that t

A EurthTech Deep Technical Narrative There is a moment, early in every IoT project, when the product feels invincible.The firmware boots.The radio connects.The device sends its first packets.You see the structured JSON in the cloud, and it feels beautiful — clean, orderly, obedient. And then one day, someone asks the question you’ve been avoiding: “What happens if someone tries to break it?” At first, you think about obvious things.Someone sniffing the radio packets.Someone r

Most teams believe they understand security. They enable encryption.They add authentication.They pass a basic penetration test. From the outside, the product looks “secure enough”. The real problem is that security in connected devices does not fail loudly or immediately. It fails quietly, often long after the product has shipped, scaled, and embedded itself into business operations. When it finally surfaces, it does so not as a technical inconvenience, but as a business cris

Every connected product team eventually hears the same request. “It’s almost perfect. We just need one small change.” The request sounds harmless. The customer is important. The deal feels close. Engineering estimates are optimistic. The change looks isolated. So the team agrees. The product ships with a small deviation, barely noticeable in the codebase. Everyone moves on, satisfied that flexibility has won over rigidity. And then it happens again. Another customer. Another

A hardware secure element like NXP's EdgeLock SE050 shows up on a BOM, and the assumption that follows — sometimes unstated, sometimes stated directly in a client conversation — is that the product is now meaningfully more secure, full stop. That's not wrong exactly, but it's dangerously incomplete. A secure element protects a specific, narrow set of things extremely well, and does nothing at all for a much larger set of things a product's overall security posture also depend

An edge gateway running Linux — the tier between microcontroller sensor nodes and the cloud, typically the box actually doing local inference, protocol translation, and store-and-forward buffering — reboots overnight with no crash log, no panic trace, nothing in the application logs indicating what happened. The service just stops appearing, and a new process with a new PID shows up after supervisor restart. Nine times out of ten on field-deployed gateways, this is the OOM ki

For most of embedded systems' history, firmware engineers and network engineers could work in adjacent lanes without much friction. Firmware owned the device; the network was a pipe it wrote bytes into. That separation is breaking down, and not because either discipline changed — it's breaking down because the constraints each discipline was built to solve now interact directly, and neither side's default mental model accounts for the other's failure modes. Two concrete cases

“Real-time” gets used as a synonym for “fast,” and that confusion is the root of most scheduling bugs that show up months after a firmware ships to the field. Real-time means deterministic — a guarantee that a given task completes within a bounded time, every time, not most of the time. A system can be blazing fast on average and still fail a real-time requirement if its worst case is unbounded, and the place that unboundedness usually creeps in is the interrupt service routi

Three months after deployment of a 120-node IoT network, the engineering team discovered a timing bug in the transmission scheduler. Under specific load conditions, nodes would collide on the shared RF channel, causing packet loss that cascaded into data gaps. The fix was 12 lines of firmware code. Review, test, and validation took two days. The field update took eight days, two engineers, and travel across three districts. Because there was no OTA mechanism in the firmware.

The Blame Always Goes to the Wrong Place When an RTOS-based embedded system starts behaving unpredictably — tasks missing deadlines, watchdog resets appearing in production, intermittent hard faults that the development team cannot reproduce on the bench — the first instinct is always the same. The scheduler. Someone adjusts task priorities. Someone lowers a tick rate. Someone adds a delay. The symptom disappears for a few days. Then it comes back. This is one of the most exp

The Hook: Stepping Out of the Codebase You’ve mastered C/C++. You can write interrupt service routines in your sleep, and you know exactly how to squeeze that last byte of RAM out of an ARM Cortex-M4. When a hard fault occurs, you dive into the disassembly and register dumps with the confidence of a seasoned detective. You are a highly effective firmware developer. But lately, you’ve noticed a shift. The challenges that excite you aren't just about optimizing a single driver

Reading Time: 25 mins Topic: IoT Architecture & Scalability Bridging the gap between academic projects and industry reality. Global IoT Network The Hook: Why Your MVP SDK Won't Survive Production Building an IoT device that connects to the cloud and sends telemetry is easy. Doing it for one device is a weekend project. Doing it for a hundred devices is a manageable pilot. But what happens when you need to deploy 1,000,000 devices across 50 countries, spanning three major clou

Reading Time: 25 mins Topic: Reliability Engineering & Field Debugging Bridging the gap between academic projects and industry reality. It is the universal firmware engineering experience: The code compiles without warnings. The unit tests pass. It runs flawlessly on your dev board for a continuous 48-hour soak test. High-fives are exchanged, the PR is merged, and the fleet is flashed. Three weeks later, the field reports start trickling in. Devices are locking up in Minnesot

Reading Time: 25 mins Topic: Compiler Engineering & Optimization Bridging the gap between academic projects and industry reality. Compiler Toolchain Concept The Hook: Why We Are Rethinking the Compiler in 2026 For decades, if you were building firmware for an embedded C project, your compiler choice was made for you: GCC (GNU Compiler Collection). It was the unquestionable industry standard. ARM shipped `arm-none-eabi-gcc`. The open-source community rallied behind it. It work

Reading Time: 25 mins Topic: Embedded AI Bridging the gap between academic projects and industry reality. 1. The Hook: The Illusion of Compiled Safety There is a dangerous myth that persists in the embedded systems industry: “Once the C code is compiled into a binary and flashed onto the microcontroller, our intellectual property is safe.” Nothing could be further from the truth. Every day, competitors, security researchers, and malicious actors are ripping firmware straight

Reading Time: 25 mins Topic: RTOS Selection & AI Scheduling Bridging the gap between academic projects and industry reality. Visualizing Circuit board with glowing ai chip. Photo via Unsplash. The Hook: When Determinism Meets the Black Box Imagine a drone navigating a dense forest at 50 km/h. Its flight controller needs hard real-time guarantees—motor updates every 1 millisecond, with sub-microsecond jitter. Simultaneously, a neural network is processing 30fps video feeds to

Author: Srihari Maddula Reading Time: 25 mins Topic: Safety-Critical Engineering & ISO 26262 In a safety-critical world, the cost of failure is measured in lives, not logs. Photo via Unsplash. Imagine you are driving at 100 km/h and you step on the brake. In a modern vehicle, that pedal might not be connected to a hydraulic cylinder—it's connected to a sensor, an MCU, and a motor. Now imagine that MCU has a "Null Pointer Exception" or a "Bit Flip" caused by a cosmic ray. The

Author: Srihari Maddula Reading Time: 25 mins Topic: Flash Management & Firmware Reliability A broken device is a design failure, not an accident. Photo via Unsplash. Imagine you’ve just shipped 1,000 smart sensors to a client in another country. A week later, you find a small bug in the WiFi stack. No problem, you think—I’ll just push an Over-The-Air (OTA) update. You click "Send," the progress bar hits 50%, and then... nothing. The device disconnects. It never comes back on