Tag: debugging

  • Diving into JTAG — BSDL (Part 4)

    In the previous article of this series, we briefly touched on how .bsd files written in Boundary Scan Description Language (BSDL) describe the structure of the boundary scan chain and the instruction set. In this article, we will examine this language’s syntax more closely before seeing how .bsd files are leveraged in JTAG testing in the next article.

  • Diving into JTAG — Boundary Scan (Part 3)

    In the third installment of this JTAG deep dive series, we will talk in-depth about JTAG Boundary-Scan, a method used to test interconnects on PCBs and internal IC sub-blocks. It is defined in the IEEE 1149.1 standard. I recommend reading Part 1 & Part 2 of the series to get a good background on debugging with JTAG before jumping into this one!

  • Diving into JTAG — Debugging (Part 2)

    In this second part of a JTAG deep-dive series, we take an in-depth look at interacting with a microcontroller’s memory and engaging with the processor core and debug registers. While the use of JTAG in testing is fairly standardized when it comes to debugging, each processor architecture has its unique nuances. With that in mind, this article will focus on debugging using JTAG on the ARM Cortex-M architecture, specifically with the STM32F407VG microcontroller.

  • Logging on Embedded Devices

    In this article, I discuss some of the problems I’ve encountered in producing and analyzing device logs over the years, on single digit number of devices up to hundreds of thousands, and concepts I’ve applied to manage that complexity. My background is in Android development, so some of the examples may skew towards much more powerful hardware than simple microcontrollers.

  • Debugging Android Devices

    In this article we will explore the different facilities and tools available to debug Android based devices and produce robust systems that can handle a wide range of applications from smart fridges, to payment terminals, and of course mobile phones.

  • Nash's Four Favorite Firmware Debug Tools

    Firmware is an essential part of every modern electronic system. Try as we might to achieve perfection in our firmware, things will, inevitably, start to act funny. And when they do, it’s time for debugging! While a poor craftsman chooses to blame his tools, proper tooling can speed you to a robust diagnosis and an expeditious fix. Here are four of my favorite friends for finding and fixing firmware flaws.

  • Share Your Debugging Scripts

    In this short-form post, I want to share how you can go about keeping a central gdbinit file that you can commit into your project’s repo and automatically source it in the popular editor and IDE environments that firmware engineers find themselves in today.

  • Faster Debugging with Watchpoints

    In this post we will explore how to save time debugging by making the most of watchpoints. We will walk through a few classic use cases of watchpoints by debugging an example application with GDB. Then, we will dive into how watchpoints are implemented for ARM Cortex-M based MCUs with the Data Watchpoint & Trace (DWT) unit and explore some advanced features.

  • Step-through debugging with no debugger on Cortex-M

    This week we explore how to debug running systems with ARM Cortex-M’s DebugMonitor exception handler. We cover how to configure the MCU to operate in this mode and walk through an example of installing breakpoints and single-stepping on a running device!

  • How do breakpoints even work?

    In this article, we will discuss the basic types of breakpoints (hardware and software) and how they are utilized by the GNU Project Debugger, GDB. We will then explore how to configure hardware breakpoints on an ARM Cortex-M MCU using the Flash Patch and Breakpoint Unit (FPB) and examine a real-world configuration with an example application.

  • Hunting Bugs with Git Bisect

    This article is a personal story of a time I had to run a bisect on a repository, and the thoughts that went through my mind as it happened. I touch on how to find a bug using git’s bisect feature and go over some easy strategies to narrow your search space as much as possible. Lastly, I detail some ways of speeding up that search through git bisect’s automation options.

  • gdbundle - GDB and LLDB's Missing Plugin Manager

    GDB and LLDB desperately need a way for developers to share scripts, user-interface improvements, and utilities with their peers. This would enable building upon existing work and debugging techniques, progressing the entire community and preventing developers from reinventing the wheel. GDB and LLDB need a plugin manager, and I’d like to introduce to you gdbundle.

  • How to debug a HardFault on an ARM Cortex-M MCU

    In this article, we explain how to debug faults on ARM Cortex-M based devices. In the process, we learn about fault registers, how to automate fault analysis, and figure out ways to recover from some faults without rebooting the MCU. We include practical examples, with a step by step walk-through on how to investigate them.

  • Using Asserts in Embedded Systems

    By using asserts proactively in embedded systems on debug and production builds, developers can both prevent more bugs before shipping and quickly surface and fix them after shipping. Proper assert handling is also the safest way to handle issues and undefined behavior that occur in production. In this post, we’ll go over best practices with asserts, when to use asserts, and then come up with a production ready custom assert implementation for an ARM Cortex-M device, all while keeping the code size usage to a minimum.

  • A Deep Dive into ARM Cortex-M Debug Interfaces

    In this article we will walk up through the hardware and software stack that enables debugging on ARM Cortex-M devices, demystify what is actually happening and go through a step-by-step example, tracing a basic debugger operation end to end using a logic analyzer.

  • Debugging Firmware with GDB

    If I had to choose one significant aspect that I was not aware of before starting my career as a firmware developer, it would be how much time is spent not actually developing, and instead debugging firmware!