Analyzing the Linker Map file with a little help from the ELF and the DWARF
Running out of Flash or RAM is a familiar pain for firmware engineers, and the linker map only tells part of the story. This post shows how to combine the linker MAP with ELF symbol tables and DWARF debug info to recover static symbols, sizes, and source files that the map omits. It also describes a C# WinForms viewer that automates the parsing with binutils and helps you spot module and symbol-level memory waste.
Short Circuit Execution vs. Unit Testing
Short-circuit evaluation in C can make perfectly logical code behave differently than you expect, especially during unit testing. Stephen Friederichs walks through a simple if statement where a conditional function is never called because of short-circuiting, causing surprising test failures and hidden side effects. He shows why stubs reveal the issue and recommends using a temporary variable to ensure the call always occurs.
Unit Tests for Embedded Code
Unit tests are one of the most effective ways to catch logic bugs early and protect embedded firmware against regressions. Stephen Friederichs explains why unit testing matters for microcontroller code, when to test, and the trade-offs between on-target and hosted approaches, with practical advice on stubbing, using the Check framework, simulators, and coverage tools to make testing realistic for embedded projects.
Delayed printf for real-time logging
Yossi Kreinin demonstrates delayed printf, a technique that records printf format pointers and raw argument words into a compact buffer so logging does not disturb real-time timing. He walks through a small C++11 writer using variadic templates and an atomic buffer plus a gdb Python reader that reconstructs formatted messages from executables or core dumps. The result is readable post-processed logs with minimal runtime overhead.
Debugging with Heartbeat LEDs
Heartbeat LEDs are one of the simplest and most effective debugging tools for embedded systems. Stephen Friederichs explains how a visible 1Hz blink from your main loop or RTOS idle task proves the MCU is executing and quickly highlights problems like failed programming, watchdog resets, infinite loops, or clock misconfiguration. He also explains why using hardware timers instead of delay loops keeps the blink nonblocking and accurate.
The Hardest Bug I Never Solved
A single overlooked sentence in the STM32 datasheet turned intermittent startup resets into a major time-leach. Senior engineers chased DMA buffers and overflows for hours until Unni discovered the ISR vector table had been relocated to RAM with only 256 byte alignment while the MCU required 512 bytes. The misalignment caused interrupts to jump to the reset handler, and fixing the alignment stopped the reboot loop for good.
Introduction to Deep Insight Analysis for RTOS Based Applications
Debugging can consume over 40% of a development cycle, and Jacob Beningo argues RTOS projects need more than breakpoints and assertions. He presents deep insight analysis as a trio of techniques—RTOS-aware debugging, run-time analysis, and profiling with coverage—that expose what the system is actually doing. These methods help engineers cut guesswork and speed verification of complex embedded applications.
Is it a Bug or an Error?
The famous moth-in-the-relay story helped 'bug' and 'debugging' become everyday terms, but this piece questions whether that cozy label softens accountability. It argues software failures usually come from human mistakes in requirements or implementation, not literal insects, and asks whether using words like 'error' or 'mistake' would push engineers to treat safety and reliability more seriously. Join the conversation.
Debugging DSP code.
Strange sinusoidal confidence scores from an HTM neural model revealed a familiar class of DSP bugs. Drawing from forum troubleshooting, the post maps common root causes: signed versus absolute value errors, wrong intermediate references, scaling mistakes, and sampling/stride problems in integer math. Embedded engineers will recognize the diagnostic clues and practical suspects to check first when DSP outputs vary with the input.
Short Circuit Execution vs. Unit Testing
Short-circuit evaluation in C can make perfectly logical code behave differently than you expect, especially during unit testing. Stephen Friederichs walks through a simple if statement where a conditional function is never called because of short-circuiting, causing surprising test failures and hidden side effects. He shows why stubs reveal the issue and recommends using a temporary variable to ensure the call always occurs.
Introduction to Deep Insight Analysis for RTOS Based Applications
Debugging can consume over 40% of a development cycle, and Jacob Beningo argues RTOS projects need more than breakpoints and assertions. He presents deep insight analysis as a trio of techniques—RTOS-aware debugging, run-time analysis, and profiling with coverage—that expose what the system is actually doing. These methods help engineers cut guesswork and speed verification of complex embedded applications.
The Hardest Bug I Never Solved
A single overlooked sentence in the STM32 datasheet turned intermittent startup resets into a major time-leach. Senior engineers chased DMA buffers and overflows for hours until Unni discovered the ISR vector table had been relocated to RAM with only 256 byte alignment while the MCU required 512 bytes. The misalignment caused interrupts to jump to the reset handler, and fixing the alignment stopped the reboot loop for good.
Short Circuit Execution vs. Unit Testing
Short-circuit evaluation in C can make perfectly logical code behave differently than you expect, especially during unit testing. Stephen Friederichs walks through a simple if statement where a conditional function is never called because of short-circuiting, causing surprising test failures and hidden side effects. He shows why stubs reveal the issue and recommends using a temporary variable to ensure the call always occurs.
Is it a Bug or an Error?
The famous moth-in-the-relay story helped 'bug' and 'debugging' become everyday terms, but this piece questions whether that cozy label softens accountability. It argues software failures usually come from human mistakes in requirements or implementation, not literal insects, and asks whether using words like 'error' or 'mistake' would push engineers to treat safety and reliability more seriously. Join the conversation.
Debugging DSP code.
Strange sinusoidal confidence scores from an HTM neural model revealed a familiar class of DSP bugs. Drawing from forum troubleshooting, the post maps common root causes: signed versus absolute value errors, wrong intermediate references, scaling mistakes, and sampling/stride problems in integer math. Embedded engineers will recognize the diagnostic clues and practical suspects to check first when DSP outputs vary with the input.
