MPLAB.X / SEGGER / reset line interactions?

[fearless]

I don't know if this is an ARM question, an MPLAB.X question or a SEGGER J-Link question, so bear with me!!

I have a custom board with the SAML21 Cortex M0+ microcontroller.  Its programmed via the SEGGER J-Link via SWD interface, controlled by the MPLAB.X v6.10 IDE.

The test app simply toggles an LED.

When I compile / load / run the app under the debugger, the app runs as expected.
When I leave the J-Link connected and try to run the app without the debugger, it does not run.
When I disconnect the J-Link (i.e. disconnect the SWD interface) and pull down and release the reset line, the app starts running.

ALSO:
If I then reconnect the J-Link/SWD, the app continues to run.
But if I then pull down and then release the reset line, the app stops.

AND ALSO if I launch J-Link COMMANDER and connect to the device:
Typing R (reset) makes the app stop.
Typing G (go) makes the app run again, even while connected to the J-Link.

I assume there must be something about the state of the other SWD lines (SWDCLK, SWDIO, SWO) that's preventing the app from running, but only when the J-Link is controlled by MPLAB.X.  Is it possible MPLAB.X is putting the J-Link into some state that's causing this?  It isn't a huge deal since there are workarounds (I can run under the debugger, I can disconnect the SWD lines and twiddle RESET, I can launch J-Link Commander and type r then g), but those slow down development.

Any idea what's going on?   Or what to look for?

[ajb]

In addition to the reset line, the debugger can use CPU control registers to start/stop program execution.  There should be options for this somewhere in your debug settings (I don't use MPLAB so not sure where they would be), and you may be able to configure what exactly happens when you start/stop a debug session--if you dig into the J-Link configuration, you can create relatively complex scripts that do all sorts of things.  Aside from that, there are several conditions that look like "app stops" or "app doesn't run", including hardfaults or application lockups/jumps to non-code sections, etc, and there are a lot of factors in terms of the debug toolchain, reset modes, the state of the surrounding PCB when the target is halted, etc, that make it hard to say with any certainty what the problem might be.  If changing debug settings doesn't fix it, it wouldn't hurt to probe the debug lines, or start a debug session without resetting ("connect to running target" or similar command in the IDE) and see what's going on in the target.