Design Article
A developer's insight into ARM Cortex M debugging
Mark Kraeling
11/3/2010 1:00 PM EDT
A software developer describes tips and tricks for using the built-in debugging options on the ARM Cortex M microcontroller. (Paper from ARM TechCon 2010.)
This paper focuses on the various hardware debug options that are available on ARM Cortex M microcontrollers. I explain the debug options from a software developer's point of view and demonstrate them using a standard ARM family tool. I also show specific debugging cases such as determining the cause of a reset and how you can find the cause using the different debug options. The paper will provide information that's useful when choosing the right debugging hardware for a project.
The paper provides an overview of the JTAG interface which ARM Cortex M is based, discusses the various interfaces that are available, and provides some tips and tricks to make debugging for the software developer easier.
A shift in understanding
As a software developer dealing with embedded systems, I needed to shift some of my understanding when first working with ARM processors. I was used to the larger scale debugging platforms and chip manufacturer's specific ways to access memory, set breakpoints, and manipulate registers.
After shifting to ARM Cortex M processors, I first used a Cortex M3-based device and then switched to another project using Cortex M0. Both platforms were very different, with the M3 project being a safety-critical multiprocessor design and the M0 project processor serving a more supervisory role to the overall system. In the past I may have had to re-learn an entirely different set of tools, or use a different compiler and debugger. Even with the wide scopes of project, I was able to keep the same base language and understanding of debugging.
I put this paper together to outline many of the things that I had to learn early on before spinning a board for our projects, and things that I wish I would have known as the project moved on. This paper is being written from the standpoint of being a software developer on both safety-critical and smaller scale projects. I hope that the information contained in the paper and presentation is useful to developers.
For the paper, I will outline a brief history of JTAG which the Cortex M debugging is based, discuss the various options and configurations for debugging, and finally provide some tips and tricks that I have learned while developing.
A brief history of JTAG
In the 1980s, processors certainly had a lot less integration and were a lot slower than the processors today--a huge understatement. My earliest debugging experiences involved debugging on 8086 and 68HC11, where in-circuit emulation was prominent. The chip was lifted off the target board, and a variety of sockets and cables were added so a separate hardware device could understand precisely what the processor was doing.
LQFP packaging made this more difficult, and I remember having to use "locator grids" and various other means to be able to seat the emulator around the chip. Development occurred with items like caches turned off, and compiler optimization minimized, so the emulators could keep up with what was going on. As processors got faster and more integrated, something had to change for software debugging.
Next: Page 2
 |
| This article is from class ATC-133 at ARM Technology Conference. Click here for more information about the conference. |
This paper focuses on the various hardware debug options that are available on ARM Cortex M microcontrollers. I explain the debug options from a software developer's point of view and demonstrate them using a standard ARM family tool. I also show specific debugging cases such as determining the cause of a reset and how you can find the cause using the different debug options. The paper will provide information that's useful when choosing the right debugging hardware for a project.
The paper provides an overview of the JTAG interface which ARM Cortex M is based, discusses the various interfaces that are available, and provides some tips and tricks to make debugging for the software developer easier.
A shift in understanding
As a software developer dealing with embedded systems, I needed to shift some of my understanding when first working with ARM processors. I was used to the larger scale debugging platforms and chip manufacturer's specific ways to access memory, set breakpoints, and manipulate registers.
After shifting to ARM Cortex M processors, I first used a Cortex M3-based device and then switched to another project using Cortex M0. Both platforms were very different, with the M3 project being a safety-critical multiprocessor design and the M0 project processor serving a more supervisory role to the overall system. In the past I may have had to re-learn an entirely different set of tools, or use a different compiler and debugger. Even with the wide scopes of project, I was able to keep the same base language and understanding of debugging.
I put this paper together to outline many of the things that I had to learn early on before spinning a board for our projects, and things that I wish I would have known as the project moved on. This paper is being written from the standpoint of being a software developer on both safety-critical and smaller scale projects. I hope that the information contained in the paper and presentation is useful to developers.
For the paper, I will outline a brief history of JTAG which the Cortex M debugging is based, discuss the various options and configurations for debugging, and finally provide some tips and tricks that I have learned while developing.
A brief history of JTAG
In the 1980s, processors certainly had a lot less integration and were a lot slower than the processors today--a huge understatement. My earliest debugging experiences involved debugging on 8086 and 68HC11, where in-circuit emulation was prominent. The chip was lifted off the target board, and a variety of sockets and cables were added so a separate hardware device could understand precisely what the processor was doing.
LQFP packaging made this more difficult, and I remember having to use "locator grids" and various other means to be able to seat the emulator around the chip. Development occurred with items like caches turned off, and compiler optimization minimized, so the emulators could keep up with what was going on. As processors got faster and more integrated, something had to change for software debugging.
Next: Page 2
|
|
|
|
|
Navigate to related information