A load memory address of 0x2000 of the main code indicates you debugging something that has a bootloader. I’ve seen many instances here where having a bootloader (that uses USB) interfered with the ability to debug correctly, the solution to that being to create a modified board definition file with adapted offset information and linker script. That was also for exactly ATSAMD21 chips by the way. See e.g. Problems starting debug session with jlink on feather M0 - #11 by prototypicalpro
This seems fishy to me when that is what JLink says as one of the first startup messages. Maybe you can ask why that could be on the JLink forums.
Either the connection from GDB to JLink is dead (previous socket issue?) or there’s something wrong with Jlink, or there are too many breakpoints set and it exceeds the hardware capabilities.
If you think that a JLink software update is at fault here, use platform_packages to adapt the version of the tool-jlink package with one of the available versions. The same can be done for the toolchain (which includes GDB as the other side), toolchain-gccarmnoneeabi. For example, add
; revert JLink.exe and friends from 7.20 back to 6.88.1
platform_packages =
tool-jlink@~1.68801.0
You can also revert back the entire platform version fpr Atmel-SAM, see releases in conjuction with documentation.