# Debugging with Sleep Mode

When an RSL15 device enters Sleep Mode or another low power mode, the device typically disables all digital elements including the debug port to minimize the system current of the device.

IMPORTANT: When a debug port connection has been established, the debug port link remains active in low power modes if the Arm Cortex-M33-Debug power domain is not explicitly disabled. This supports debugging the functionality of an application that uses low power modes across a low power mode-wakeup cycle. For more information, see Keeping the Debugger Connected in Low Power Modes.

NOTE: If the Arm Cortex-M3 processor processor is asleep but the overall system is not in Sleep Mode, the system can still transmit data or respond to a debugger. This common use case does not need special considerations.

If a problem or system being debugged requires current measurements as part of the debug process, the debug port needs to be disabled. If this is required, the following mechanisms can function as potential debug tools:

- The swmTrace module, described in section Printing to a Console with swmTrace, can be used to print data up to the point of sleeping and immediately after wakeup.
- The UART interface can be used both with and without the swmTrace module, to communicate data while not in Sleep Mode.
- Simple techniques, such as setting a GPIO high while in Sleep Mode and low when exiting, can be used to quickly verify operation and whether the device has entered and exited Sleep Mode.

NOTE: UART and swmTrace transfers stop immediately and are truncated if a transfer is in progress when the device goes to Sleep Mode. If UART data truncation is a concern for your debug use case, care must be taken to ensure transfers are complete before going to Sleep Mode.

These debug tools and techniques for working with Sleep Mode are demonstrated in the sleep_mode sample application. See the readme file included in that sample for more information.

NOTE: Breakpoints are still active after waking from Sleep Mode. The breakpoint stops the core—but the debugger on the other side of the debug link might not be notified if the debug connection had not yet reconnected after wakeup.