How Debugging Affects the Operations of MPLAB® X IDE Applications

Last modified by Microchip on 2023/11/09 09:21

Microchip microcontrollers (MCUs) that are being debugged in-circuit operate in a different mode than those running stand-alone. MCUs being debugged communicate with an external programmer/debugger and are able to respond to commands issued from the Integrated Development Environment (IDE). MCUs being debugged typically wait for an instruction from the IDE, execute the instruction then return data to the IDE.

Programming Debugger Functions

Programming Debugger Functions

The ability of the MCU to communicate with the IDE and respond to user-directed tasks during a debug session is accomplished by a combination of hardware and software.  When a debug session is started, the IDE builds a special version of the application which activates the device’s debug circuitry and, in some cases, adds a small amount of code to the application. In stand-alone versions of the application, the debug circuity is not active, and no software is added to the application by the IDE.

Debugging consumes device resources and can impose debugging obstacles.

Back to top

IO Pin Implications

Microchip MCUs communicate with programmers/debuggers using a set of dual-purpose, or shared pins. When the device is being programmed or debugged, these pins connect to the programmer/debugger and are not available to the application program. When the device is in Stand-Alone (production) mode, these pins become general-purpose IO pins and can be accessed by the application.

The IO pin limitation will affect the debugging of pin-constrained applications.  Applications in which all run-time IO pins are used will be unable to fully verify that IO pins are functioning correctly. 

Low Pin Count MCU

Low Pin Count MCU

For some of the smaller MCUs, Microchip offers debug headers with a custom version of the MCU. These custom MCUs contain all the features of the original MCU but add additional memory and IO pins.   

Debugger Header

Debugger Header

Back to top

Memory and Stack Constraints

When a debug version of an application is built, a configuration bit activating the MCU’s debug circuitry is set. For some MCUs, a small amount of code called the debug executive, is added to the application. In Stand-Alone mode, this circuitry is not activated, and no code is added to the application.

Example of a Debug Executive

Example of a Debug Executive

Back to top

Accessing Find Usages

On the MCUs where the debug executive is present and unavailable to the application, some RAM and some stack space are used. The amount of RAM used by the debug executive is device-dependent. To verify the resources your device surrenders during a debug session, from the Learn and Discover tab on the MPLAB® X Integrated Development Environment (IDE) Start Page, select User Guides and Release notes.  When the Support Document page appears in the browser, select Reserved Resources by Device for All Tools.

Finding user guides and release notes

The additional resources needed to debug are not available to the application in Debug mode. For applications running on devices with small amounts of data memory, this limitation can cause problems during debugging.   

Back to top

Operating Speed Not Affected by Debugging

During a debug session, there is no degradation of the device’s clock speed. When the user instructs the MCU to begin executing, the instructions execute at the same speed as those in Stand-Alone mode.

Learn More

Back to top