Inzwischen hab eich eine Lösung gefunden.

VisualGDB hat mir permanent folgendes an den Kopf geworfen:
Code:
Error erasing flash with vFlashErase packet


Zunächt einmal habe ich OpenOCD heruntergeladen und per Windows 10 SuperShell über meinen Programmer (jTag Lock-Pick Tiny2, ein ebenfalls günstiger ST-Link v2 müste aber genau funktionieren, entsprechend Interface in der Kommandozeile anpassen) auf den nRF51422 zugegriffen:
Code:
.\openocd.exe -s /openocd010/scripts/ -f interface/ftdi/jtag-lock-pick_tiny_2.cfg -c "transport select swd" -f target/nrf51_stlink.tcl


Nun kann man per telnet auf den Mikrokontroller zugreifen.
Hierzu habe ich Putty genutzt:
telnet auswählen, als
Code:
IP 127.0.0.1 und Port: 4444
eine nRF51822-Testplatine habe ich sofort per
Code:
nRF51 mass_erase
löschen und über VisualStudio mit VisualGDB neu beschreiben können.

Meine nRF51422-Platine hingegen spuckte mir den Fehler aus
Code:
Open On-Chip Debugger > nrf51 mass_erase
nRF51822-CEAA(build code: C0) 256kB Flash
Target not halted

> halt
Halt timed out, wake up GDB.
timed out while waiting for target halted
Kurzes Ausprobierer ergab hiermit Erfolg:
Code:
> reset halt
nrf51.cpu: target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0xc1000000 pc: 0x000006d0 msp: 0x000007c0
> nrf51 mass_erase
>

Und nun kann ich per VisualGDB auch auf meinen nRF51422 zugreifen.


Bei mikrokontroller.net wurde ich auf ein Video aufmerksam gemacht, das die Beschreibung des Chips in Zusammenhang zum verbauten Speicher aufschlüsselt:
https://www.youtube.com/watch?v=Nuh7qKAanyM&t=1m24s

Daher konnte ich nun den richtigen Chip in der nRF51-Familie auswählen und meine Test-LED blinkt nun