nRF51822 (Core51822) - first connection on Windows
Core51822 is a cheap Chinese electronics module (printed circuit board with components) with a Bluetooth Low-Energy enabled ARM Cortex-M0 chip NRF51822 (from Nordic Semiconductor).
For connecting, I used an also cheap “ST-Link v2” clone “pendrive” programmer.
Wiring
As found on some tutorial, for connecting the board to the programmer, the following pins should be wired together:
Core51822 <-> ST-Link/v2 ------------------------ GND <-> GND VDD <-> 3.3V SCLK <-> SWCLK SDO <-> SWDIO
A quick rough image (pin locations on the programmer differ in mine):
ST-Link USB driver
First, I had to install STLink from STMicroelectronics website. It seemed to require giving them my email even when I clicked “Download as a guest”. I got the whole “STLink tool” but it should be enough to get just the USB driver at: www.st.com/en/…/stsw-link009.html
I tried using the open-source alternative (?): github.com/stlink-org/stlink but it didn’t seem to work for me. (Maybe I should also install a USB driver they mention somewhere in the docs?)
probe-rs
Next, I installed probe-rs: probe.rs
First try running probe-rs
Running probe-rs 0.27, I got the following output:
c:> probe-rs info Probing target via JTAG ←[33m WARN←[0m ←[2mprobe_rs::probe::stlink←[0m←[2m:←[0m send_jtag_command 242 failed: JtagUnknownJtagChain Error identifying target using protocol JTAG: An error with the usage of the probe occurred Probing target via SWD ARM Chip with debug port Default: Debug Port: DPv1, MINDP, DP Designer: ARM Ltd └── 0 MemoryAP (AmbaAhb3) └── Error during access: The debug probe encountered an error. Debugging RISC-V targets over SWD is not supported. For these targets, JTAG is the only supported protocol. RISC-V specific information cannot be printed. Debugging Xtensa targets over SWD is not supported. For these targets, JTAG is the only supported protocol. Xtensa specific information cannot be printed.
This was not super encouraging (noting the “error”), but still somewhat so: it seemed to correctly detect that it’s some kind of an ARM Chip.
Second try via openocd
I then also tried installing openocd (from github releases), version 0.12.0.
I wrote the following file openocd.cfg
(via):
source [find interface/stlink-v2.cfg] transport select hla_swd set WORKAREASIZE 0x4000 source [find target/nrf51.cfg]
Then, in one cmd window, run:
c:> openocd.exe -f openocd.cfg Open On-Chip Debugger 0.12.0 (2023-01-14-23:37) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html WARNING: interface/stlink-v2.cfg is deprecated, please switch to interface/stlink.cfg Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD Info : Listening on port 6666 for tcl connections Info : Listening on port 4444 for telnet connections Info : clock speed 1000 kHz Info : STLINK V2J37S7 (API v2) VID:PID 0483:3748 Info : Target voltage: 3.260227 Info : [nrf51.cpu] Cortex-M0 r0p0 processor detected Info : [nrf51.cpu] target has 4 breakpoints, 2 watchpoints Info : starting gdb server for nrf51.cpu on 3333 Info : Listening on port 3333 for gdb connections Info : accepting 'telnet' connection on tcp/4444
This again seemed to correctly detect an ARM chip,
this time with some more details (Cortex-M0) -
though I’m not super sure if that’s “detected”
or rather just known because nrf51.cfg
was explicitly listed in the openocd.cfg file…
The following command stops and waits for connections, so I needed to open another cmd window. The OpenOCD server can take telnet connections, so I installed telnet first with:
c:> pkgmgr /iu:"TelnetClient" c:> telnet localhost 4444
Note: if too much time passed,
commands may error out,
and restarting openocd may be needed -
I got errors like below first when trying to run some commands:
Info : Halt timed out, wake up GDB. Error: timed out while waiting for target halted
After restarting, telnet worked again and my session looked like below (via):
Open On-Chip Debugger > halt [nrf51.cpu] halted due to debug-request, current mode: Thread xPSR: 0x61000000 pc: 0x0000fe3e msp: 0x20003390 > nrf5 mass_erase nRF51822-QFAA(build code: CA/C0) 256kB Flash, 16kB RAM Mass erase completed. A reset or power cycle is required if the flash was protected before. > reset
This seemed to detect for me that I got a QFAA version of the chip in the module, that is a version with 256kB Flash and 16kB RAM (as also printed).
For completeness, the output in the openocd window looked like below after the full telnet session above:
c:> openocd.exe -f openocd.cfg Open On-Chip Debugger 0.12.0 (2023-01-14-23:37) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html WARNING: interface/stlink-v2.cfg is deprecated, please switch to interface/stlink.cfg Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD Info : Listening on port 6666 for tcl connections Info : Listening on port 4444 for telnet connections Info : clock speed 1000 kHz Info : STLINK V2J37S7 (API v2) VID:PID 0483:3748 Info : Target voltage: 3.260227 Info : [nrf51.cpu] Cortex-M0 r0p0 processor detected Info : [nrf51.cpu] target has 4 breakpoints, 2 watchpoints Info : starting gdb server for nrf51.cpu on 3333 Info : Listening on port 3333 for gdb connections Info : accepting 'telnet' connection on tcp/4444 [nrf51.cpu] halted due to debug-request, current mode: Thread xPSR: 0x61000000 pc: 0x0000fe3e msp: 0x20003390 Info : nRF51822-QFAA(build code: CA/C0) 256kB Flash, 16kB RAM Info : Mass erase completed. Info : A reset or power cycle is required if the flash was protected before.