![]() ![]() ![]() Running an example from the nRF5 SDK (version 15.3.0), specifically the UART example application.A macOS machine as the development environment.In this post, we’ll walk through setting up GDB for the following environment: developing on a Windows machine for an ARM-based target).īecause of these reasons, we believe it is extremely helpful for a firmware developer to at least get some exposure to using GDB. This is crucial for embedded systems where the development environment resides on an architecture different from the target system (e.g. This became especially true with the release of the Python API for GDB in GDB’s release version 7.0 (in 2011). GDB is command-line based which gives it high flexibility and usability in debugging tasks that require some level of automation.Because of this, a firmware developer’s knowledge and expertise with GDB is potentially transferrable across many projects. GDB supports a vast number of architectures including: ARM, x86, MIPS, and many more.It is one of the most popular debuggers out there, and for many good reasons! GDB was developed by Richard Stallman in 1986 as part of the GNU system. High cost of some debugging hardware tools.There is a variety of visual IDEs and integrated debuggers available, but for some scenarios you may need an automated debugging setup and this can prove to be a challenging task. Challenges in setting up the debugging environment (cross-platform development environment).If a bug is timing-related, then the debugging process may even cause the bug to disappear! For example, setting breakpoints can interfere with the timing of operations. Time-dependency in real-time/time-critical applications.This makes debugging complex bugs a challenging task. In those scenarios, you would rely on hardware breakpoints and usually there is a limited number of hardware breakpoints for a specific architecture. For example, some bugs are very difficult to diagnose using software breakpoints. Limited availability of resources for debugging.This is due to a few factors, some of which are: I’ll leave you with a few figures taken from the 2017 Embedded/EETimes Embedded Markets Study survey which showcase the significance of debugging in the professional life of a firmware developer.ĭebugging is generally difficult, and it gets even more difficult for firmware applications and has more limitations compared with a mobile or web application. 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! ![]()
0 Comments
Leave a Reply. |