I've been debugging over the serial port up until now, but want to dig deeper with JTAG debugging.

I've purchased the recommended Teknic ClearCore ATMEL-ICE JTAG debugger and cable from Teknic in the USA. I've connected to the JTAG header and plugged into the debugger SAM port as described in the ClearCore manual. 

The ClearCore powers up ok and the debugger red and green leds come on too.

In Visual Studio, under the Visual Micro menu, I've selected hardware debugger, ATMEL-ICE and No Project + Libraries Optimisation. I've selected the Debug build configuration.

When I try to start debugging, I get the following error:

"Unable to start debugging. Unexpected GDB output from command "-target-select remote localhost:3333", Remote connection closed"

I've attached the verbose output of the micro build window.

I'd appreciate guidance as to how to solve this issue!

Sorry! I missed the pre-issue logging instructions at the top of this forum page.

I've attached the requested compiler output.

Thanks - I've recompiled and attached again (I'm having to switch between serial debugging to be able to continue work, and hardware debugging to work out the jtag issue)

Thanks - I've done as instructed and still get the same error - build output attached.

I hope the attached shows what you need.

Please can I check: does the localhost:3333 entry imply I need an ethernet cable connected from the ClearCore to my laptop? As I understand it, I only need the debugger USB cable.

Thanks for the information, it seems the overrides are not being applied for some reason, which is why the errors occur in the OpenOCD log.

The localhost:3333 connection is the port OpenOCD is serving for GDB to connect to, beneath VS when debugging, and it is normal when debugging via USB with our current configuration.  The OpenOCD log provided shows these layers are connecting up, but OpenOCD has been told it is the wrong chip is the root issue so far.

An alternative approach (which gives full manual configuration):
1) Click vMicro > Add Code > Add Custom GDB Debugger (Advanced)
2) Open the "ARM_ClearCore.Debug.debugger_launch.json" file and paste in the attached files' contents and save it
3) Change the vMicro > Debugger > Hardware Debugger: Manual/Custom

If you then try attaching the debugger again it should use the correct OpenOCD cfg file (atsame5x.cfg) when debugging.

Glad to hear you are up and running, we will implement this and update this thread when this is available.

Thanks for working with us on this to reach this point.

I've got a continuous 5 kHz ISR running with some code in it - what's the expected behaviour whilst GDB debugging? I've set a single breakpoint in the main program, but it doesn't halt at it. The only debug options are to stop the process, nothing shows paused, as one would expect at a breakpoint, awaiting the usual step into etc. input.

I disabled the ISR and set a definite breakpoint in the main program loop. The debugging session runs, but doesn't pause at the breakpoint. The only options in the debug menu are to end the session. I get the following debug output:

openocd: Open On-Chip Debugger 0.10.0+dev-01058-g853a05287 (2020-02-13-16:41)
openocd: Licensed under GNU GPL v2
openocd: For bug reports, read
openocd:      http://openocd.org/doc/doxygen/bugs.html
openocd: debug_level: 2
openocd: 
=thread-group-added,id="i1"
GNU gdb (GNU Tools for Arm Embedded Processors 7-2017-q4-major) 8.0.50.20171128-git
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>;
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-w64-mingw32 --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
=cmd-param-changed,param="pagination",value="off"
0x0000059c in ?? ()
Warning: Exceptions are not supported in this scenario.
Note: automatically using hardware breakpoints for read-only addresses.

Breakpoint 1, main () at \arduino\main.cpp:42
42          delay(1);

I took at look at main.cpp, and see the following:

/*
* \brief Main entry point of Arduino application
*/
int main(void) {
    // - - - - - - - - - - - - - - - - - - - - - -
    // Perform C++ initializations before sketch
    // - - - - - - - - - - - - - - - - - - - - - -
    delay(1);
    // Start sketch "setup"
    setup();

    for (; {
        // sketch "loop"
        loop();
        if (serialEventRun) {
            serialEventRun();
        }
    }

    return 0;
}

I tried attaching to the process again, leaving main.cpp open, in the hope that debug execution halted at delay(1), but nothing happens. The only option is to halt the session.