Coredump Sessions

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.Companies need a documented process for receiving, assessing, and responding to vulnerability disclosures. Checking a security inbox once a week is not enough for the CRA’s reporting timelines.The CRA applies broadly to products with digital elements placed on the European market, including hardware, software, firmware, and some devices that are not connected to the internet.Full compliance requirements take effect in December 2027 and include capabilities such as delivering vulnerability fixes, verifying that code has not been tampered with, protecting interfaces, and securing sensitive data.Threat analysis and risk assessment will need to become a formal part of product development rather than something engineering teams handle informally.Product classification determines how companies demonstrate compliance. Default-class products can generally self-assess, while higher-risk classes require additional third-party assessment or certification.Manufacturers need visibility into the software and hardware components inside their products so they can continuously monitor dependencies for vulnerabilities.Products placed on the market must declare a support period of at least five years, during which manufacturers are expected to track vulnerabilities and provide fixes.Documentation from chip, software, and other technology vendors can support a company’s compliance evidence, but the manufacturer placing the final product on the market remains responsible for that product.⁠⁠Watch this episode on YouTube ⁠Follow Memfault⁠⁠⁠LinkedIn⁠⁠⁠⁠⁠⁠Bluesky⁠⁠⁠⁠⁠⁠Twitter⁠⁠Other ways to listen:⁠⁠⁠⁠⁠Apple Podcasts⁠⁠iHeartRadio⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Amazon Music⁠⁠GoodPods⁠⁠Castbox⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Visit our website

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.Key TakeawaysElemind uses EEG and real-time audio stimulation to influence brain activity and help users fall asleep faster.The system operates as a closed-loop feedback system with approximately two milliseconds of latency between sensing brain activity and delivering audio.Rather than playing relaxing sounds, the device delivers precisely timed audio pulses that interfere with specific brainwave patterns.The team discovered that suppressing alpha brainwaves was more effective for sleep onset than boosting slower brainwave frequencies.Consumer neurotechnology succeeds only if it requires almost no effort or behavior change from users.Audio was selected over electrical or magnetic stimulation because it provides a much less invasive and safer user experience.Early product development relied on rapid nap studies to validate neuroscience hypotheses before investing in longer sleep trials.Elemind is now exploring an AI-driven "sleep tailor" that could personalize stimulation for users who don't initially respond to the device.⁠⁠Watch this episode on YouTube Follow Memfault⁠⁠LinkedIn⁠⁠⁠⁠Bluesky⁠⁠⁠⁠Twitter⁠⁠Other ways to listen:⁠⁠Apple PodcastsiHeartRadio⁠⁠⁠⁠Amazon MusicGoodPodsCastbox⁠⁠⁠⁠Visit our website

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.Key TakeawaysYoto built its product around a deliberately constrained experience: no screens, no ads, no microphones, and controls simple enough for a two-year-old to use independently.The company treated audio content as the core product, combining licensed entertainment, music, podcasts, and interactive experiences to drive long-term engagement.Early prototypes were built with Raspberry Pi hardware to validate real-world usage quickly before investing in custom production hardware.Children became the primary usability test group because their behavior immediately exposed friction points and design flaws.Hardware constraints drove innovation. Limited controls and minimal inputs forced the team to create more intuitive product interactions.Yoto evolved through multiple hardware generations as real-world family usage exposed challenges around durability, connectivity, and battery performance.Device observability and fleet monitoring became increasingly important as Yoto scaled globally and needed visibility into issues occurring in the field.OTA update strategy matured alongside fleet growth, helping the team manage reliability improvements and software iteration remotely.Regulatory complexity around connected kid devices continues to increase, particularly around cybersecurity and children’s data protections.Community became a major product advantage, with parents contributing feedback, creating custom content, and shaping future product improvements.⁠⁠Watch this episode on YouTube [ADD Playlist YT Link from here)⁠⁠Follow Memfault⁠⁠LinkedIn⁠⁠⁠⁠Bluesky⁠⁠⁠⁠Twitter⁠⁠Other ways to listen:⁠⁠Apple PodcastsiHeartRadio⁠⁠⁠⁠Amazon MusicGoodPodsCastbox⁠⁠⁠⁠Visit our website

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 DemoJoin the Interrupt Slack ⁠⁠⁠⁠Watch this episode on YouTube [ADD Playlist YT Link from here)⁠⁠Follow Memfault⁠⁠LinkedIn⁠⁠⁠⁠Bluesky⁠⁠⁠⁠Twitter⁠⁠Other ways to listen:⁠⁠Apple PodcastsiHeartRadio⁠⁠⁠⁠Amazon MusicGoodPodsCastbox⁠⁠⁠⁠Visit our website

Spotify DetailsIn today's Coredump Session, François Baldassari and Chris Coleman sit down with Ross Yeager, VP of Device Platform Software at Skydio, to explore how autonomy is reshaping modern robotics and what it takes to build drones that can truly think for themselves. Ross shares his journey from Boosted Boards to Skydio, unpacking how the company pioneered fully autonomous flight, built a vertically integrated manufacturing operation in California, and created a foundation that blends cutting-edge software and hardware. It’s a conversation about leadership, innovation, and the engineering mindset behind one of the most advanced drone platforms in the world.Key Takeaways:Ross Yeager's journey into embedded engineering began with a passion for electronics and product development.Kickstarter projects provided valuable lessons in scaling production and managing customer expectations.Working at Boosted Boards allowed Ross to experience the challenges of building products from scratch.Safety is a critical concern in drone technology, with high stakes for reliability and performance.Skydio's unique approach involves vertical integration, manufacturing drones in the U.S. for quality control.The embedded engineering landscape has evolved, with new tools and technologies simplifying development.Testing and quality assurance are paramount, with innovative methods to ensure reliability in drone operations.Ross emphasizes the importance of curiosity and problem-solving in engineering roles.Chapters:00:00 Intro & Teasers03:30 Ross's Path to Embedded Engineering07:52 Lessons from Kickstarter and Early Projects12:35 Transitioning to Boosted Boards and Micro-Mobility17:52 Challenges in Embedded Systems and Hardware Development22:45 Skydio's Unique Approach to Drone Technology30:06 Manufacturing Drones in the U.S.35:01 Embedded Engineering Challenges and Safety Considerations39:29 Testing and Quality Assurance in Drone Development46:47 Future of Skydio and Career Opportunities56:18 Closing Thoughts & ReflectionsJoin the Interrupt Slack ⁠⁠⁠⁠Watch this episode on YouTube [ADD Playlist YT Link from here)⁠⁠Follow Memfault⁠⁠LinkedIn⁠⁠⁠⁠Bluesky⁠⁠⁠⁠Twitter⁠⁠Other ways to listen:⁠⁠Apple PodcastsiHeartRadio⁠⁠⁠⁠Amazon MusicGoodPodsCastbox⁠⁠⁠⁠Visit our website