Hi,
Stepping through code on Nordic devices could be tricky due to the built-in watchdog that would reset the CPU each time it is stopped for a non-trivial amount of time, although it should not lead to the behavior you are describing.
From a quick look at the log file you attached, it looks that the Segger gdb stub fails to read the CPU registers shortly after the reset command:
Received monitor command: reset
Resetting target
Connected to 127.0.0.1
Read 2 bytes @ address 0x000003B4 (Data = 0xF107)
Read 2 bytes @ address 0x000003E2 (Data = 0x1D3B)
Read 4 bytes @ address 0x2000DFFC (Data = 0x4B642F0A)
Downloading 4 bytes @ address 0x2000DFFC
Reading all registers
ERROR: Can not read register 0 (R0) while CPU is running
ERROR: Can not read register 1 (R1) while CPU is running
ERROR: Can not read register 2 (R2) while CPU is running
ERROR: Can not read register 3 (R3) while CPU is running
This might affect the initial breakpoints or could cause other weird behavior.
Please try updating the Segger J-Link software and/or try adding delays (e.g. mon sleep 1000) before and after the reset command under VisualGDB Project Properties -> Debug Settings -> Advanced Settings.