Flashing nRF5832 using only ST-LINK V2 and OpenOCD

Hello everyone,

I am refering to https://devzone.nordicsemi.com/f/nordic-q-a/29029/programming-nrf52-with-openocd/126175#126175

Is there any complete tutorial out there which solves the issue regarding the memory protection bit using only open-ocd and an ST-LINK V2?

The problem with all the posts here on the forum is, that I am not able to reproduce them since they are either really old or don't include the exact versions of the used libraries...


  • I can't really help you with the ST-Link tutorial, I'm just here to tell you to use an nRF52DK. It already has a debug on-board that can be use with external boards. 

  • Regarding the protection bit, one thing to be aware of is that the ST-LINK V2 (and its various clones) are what OpenOCD calls a "high-level adapter." What does that mean?

    The ST-LINK V2 is basically an ST Micro ARM chip running some special firmware which is designed specifically for programming/debugging ARM chips that support the Serial Wire Debug (SWD) interface and protocol. (SWD is a variant of JTAG that uses fewer pins.) The firmware accepts commands from a host computer via USB and then issues the corresponding SWD transactions to the device under test.

    By contrast, you have things like the Olimex ARM-OCD-USB-H debugger which is considered a low-level adapter. This device contains an FTDI serial chip, which is basically a dumb device whose pins can be twiddled via host software. It doesn't know anything about SWD or JTAG protocols: the intelligence for that is all in the host software (in this case OpenOCD) and the software twiddles the pins to produce the correct signal patterns that correspond to the SWD transaction protocol.

    The ST-LINK V2 is considered a high-level adapter because it accepts high-level commands from the host, and its functionality is limited by whatever the firmware developers decided to implement in it. The Olimex is a low-level debugger because you can basically do anything with it: it can support SWD, JTAG or custom protocols.

    The SWD protocol is defined by ARM Ltd. and is the same for all ARM-based devices that implement it. (This is why the ST-LINK V2 can work with other chips besides the ones ST Micro manufactures.) However some chip vendors also implement some custom functionality in addition to the standard SWD commands. One common example of this is a mass erase command. Nordic supports a mass erase function for the nRF52. (And I happen to know that NXP supports a mass erase command for its ARM Kinetis chips too.)

    If you have an nRF52 chip where someone has set the access port protection bit, the only easy way to recover it is with a mass erase.

    And because the ST-LINK V2 is a high-level adapter and it doesn't support the vendor-specific Nordic mass erase command, I'm pretty sure you can't use it for this recovery procedure. (If you try to do the mass erase, OpenOCD will return an error message saying it's not supported for high-level adapters.)

    I have been able to issue a mass erase command with OpenOCD using the Segger J-Link debugger that's built into the nRF52840 DK board, so obviously it does work there.

    I ran into a problem like this once with an NXP Kinetis (KW01) board. The Kinetis flash driver in OpenOCD doesn't get along well with the ST-LINK V2, and it failed to reset the flash protection words after erasing them, which resulted in my locking myself out of the chip until I was able to mass erase it with my Olimex debugger. (I eventually patched it to fix that.) The nRF52 doesn't use the same flash driver so I don't think it would have the same problem.

    Recent versions of OpenOCD (like, within the last year at least), support the nRF52832 and nRF52840 out of the box. So I think the ST-LINK V2 should work with it for regular debug and flash as long as you don't need to do a mass erase. You'll probably want to use something like:

    openocd -f interface/stlink.cfg -f board/nordic_nrf52_dk.cfg -c "gdb_flash_program enable" -c "gdb_breakpoint_override hard"

  • Thank you very much for this thorough explanation. This should be part of a tutorial for beginners, since it not only explains the different methods but also the implications!

    If I understand correctly for example a Raspberry Pi should be able to be used as a low level adapter, given the correct software, since I could configure it however I like in theory?

  • That's correct. In fact OpenOCD supports this configuration (see interface/raspberrypi-native.cfg and interface/raspberrypi2-native.cfg). It uses the GPIO driver to control the pins, so in effect you can turn your RPi into a multi-purpose debugger. You need to rig up a cable to connect your device under test to the RPi's GPIO header, but as long as the voltage levels are compatible it should work with anything.