
#003: Pebble's Code is Free: Three Former Pebble Engineers Discuss Why It's Important (PART 1/2)
Coredump SessionsShow Notes
REGISTER FOR PART 2 OF THE PEBBLE CONVERSATION ON APRIL 15TH
In this episode of Coredump, three former Pebble engineers reunite to dive deep into the technical quirks, philosophies, and brilliant hacks behind Pebble OS. From crashing on purpose to building a single codebase that powered every watch, they share war stories, bugs, and what made Pebble’s firmware both rare and remarkable. If you love embedded systems, software-forward thinking, or startup grit— this one’s for you.
Key topics: Pebble intentionally crashed devices to collect core dumps and improve reliability. All Pebble devices ran on a single codebase, which simplified development and updates. The open-sourcing of Pebble OS is a rare opportunity to study real, commercial firmware. A platform mindset—supporting all devices and apps consistently—shaped major engineering decisions. Pebble’s app sandbox isolated bad code without crashing the OS, improving developer experience. The team built a custom NOR flash file system to overcome constraints in size and endurance. Core dumps and analytics were essential for tracking bugs, deadlocks, and field issues. Collaborations between hardware and firmware engineers led to better debugging tools and smoother development.
Chapters: 00:00 Episode Teasers & Intro01:10 Meet the Team: Pebble Engineers Reunite01:13 Meet the Hosts + Why Pebble Still Matters03:47 Why Open-Sourcing Pebble OS Is a Big Deal06:20 The Startup Firmware Mentality08:44 One OS, All Devices: Pebble’s Platform Bet12:30 App Compatibility and the KEMU Emulator14:51 Sandboxing, Syscalls, and Crashing with Grace20:25 Pebble File System: Built from Scratch (and Why)23:32 From Dumb to Smart: The Iterative Codebase Ethos26:09 Core Dumps: Crashing Is a Feature30:45 How Firmware Shaped Hardware Decisions33:56 Rust, Easter Eggs, and Favorite Bugs36:09 Wear-Level Failures, Security Exploits & Font Hacks39:42 Why We Chose WAF (and Regret Nothing?)42:41 What We’d Do Differently Next Time47:00 Final Q&A: Open Hardware, Protocols, and Part Two?
Join the Interrupt Slack
Watch this episode on YouTube
Suggest a Guest
Follow Memfault LinkedIn Bluesky Twitter
Other ways to listen: Apple Podcasts iHeartRadio Amazon Music GoodPods Castbox Visit our website
More from Coredump Sessions
In this Coredump Session, François Baldassari and Chris Coleman are joined by Torstein Nesse, co-founder and CEO of Monil, to explore the engineering behind solar-powered livestock collars that replace physical fences with virtual boundaries. Torstein shares his path from embedded security to building a connected hardware business, and explains how Monil combines positioning, motion sensors, and sound to guide animals. The conversation covers low-power design, cellular connectivity in rural areas, offline operation, hardware selection, and the field telemetry needed to understand device behavior. They also discuss seasonal firmware updates, a four-month network debugging challenge, and how an animal-health alert helped farmers discover cattle in danger.
In this Coredump Session, François Baldassari and Chris Coleman are joined by Nordic Semiconductor VP of Product Security, Nicolas Schieli, to break down what the EU Cyber Resilience Act (CRA) means for teams building connected products. With the CRA’s first reporting requirements now in effect, they discuss what companies need to do today, how the 24-hour vulnerability reporting window works, which products fall within scope, and what changes when the broader requirements take effect in December 2027. The conversation also covers threat modeling, secure development processes, product classifications, SBOMs, long-term support, OTA updates, secure boot, open source dependencies, and how AI can fit into CRA workflows. Key Takeaways: The CRA’s vulnerability reporting requirements are already in effect, including a 24-hour reporting window for severe incidents or actively exploited vulnerabilities.
In today's Coredump Session, we explore how Elemind is turning cutting-edge neuroscience into a wearable device that helps people fall asleep faster. CTO David Wang joins the show to unpack the engineering behind real-time brainwave sensing, closed-loop audio stimulation, and the embedded systems powering the technology. Along the way, the conversation dives into the challenges of building consumer neurotech, making advanced science effortless to use, and how AI could personalize sleep in the future.
In this Coredump Session, Tyler Hoffman joins us as host and Yoto co-founders Ben Drury and Filip Denker shared how they built one of the fastest-growing brands in kid tech around a simple idea, a screen-free audio player designed for real family life. They discussed how feedback from kids shaped key hardware decisions across multiple generations of devices, and how the team balanced durability, battery life, and connectivity as Yoto scaled globally. The conversation also explored how their approach to device monitoring and updates evolved alongside their growing fleet.
Summary:In today's Coredump Session, we sit down with Noah Pasek-Nelson and Chris Markus, the co-founders of BootLoop: an AI-powered platform purpose-built for firmware teams. The conversation gets into the real mechanics of how AI actually fits into embedded development workflows, from hardware bring-up and driver generation to hardware-in-the-loop testing and field debugging. Noah and Chris bring hard-won perspective from SpaceX, MIT, and FDA-regulated medical devices, and they don't shy away from the messy questions— hallucination, autonomy, trust, and what it actually takes to close the loop when your runtime is physical hardware. Key Takeaways: BootLoop is an AI platform built for the entire firmware lifecycle, from hardware bring-up through field debugging, not just code generation. The two core pillars are hardware understanding (ingesting schematics, data sheets, netlists) and hardware interaction (oscilloscopes, logic analyzers, GDB). Firmware engineers only spend about 20% of their time writing code. The rest is testing, debugging, and validation, which is where BootLoop focuses. Agents do their best work in tight feedback loops. BootLoop builds, flashes, and tests on device automatically so the agent can iterate without human intervention. Hardware understanding eliminates hallucination by grounding the model in your specific chips, register maps, and pin configurations rather than public code averages. Power optimization is a standout use case: feed in the data sheet, connect a power meter, set a target, and come back to optimized code. BootLoop supports C, C++, Rust, Zephyr, bare metal, and embedded Linux. HDL and FPGA support is coming. Sentinel, their field debugging product, automatically kicks off root cause analysis the moment a bug comes in from the field, before an engineer even sits down. Pricing is a flat fee with unlimited usage, intentionally aligned so the incentive is correct code, not more code. New chips are supported as fast as you can upload the documentation. There is no supported chips list. Chapters: 00:00 Intro: AI at the Bench for Firmware Teams02:23 What Is BootLoop? Meet the Founders05:18 What Actually Changes Day-to-Day for Firmware Engineers07:13 The Hallucination Problem and How to Solve It in Hardware09:51 From Data Sheet to Flashed Device: A Live Workflow Demo11:20 Oscilloscopes, GDB, and Natural Language: Hardware Interaction Explained13:34 How Much Babysitting Does an AI Agent Actually Need?45:59 Greenfield vs. Brownfield: Where BootLoop Fits Best47:33 Audience Q&A: Business Model, Security, and Supported Chips57:35 Debugging in the Field: Sentinel, MCP, and Root Cause Analysis1:00:04 Closing Thoughts and How to Get a Demo Join the Interrupt Slack Watch this episode on YouTube [ADD Playlist YT Link from here) Follow Memfault LinkedIn Bluesky Twitter Other ways to listen: Apple Podcasts iHeartRadio Amazon Music GoodPods Castbox Visit our website