Flashing nRF5832 using only ST-LINK V2 and OpenOCD

[beginner]

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...

Thanks!

[wpaul]

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"

[awneil]

wpaul said:

The ST-LINK V2 is ... designed specifically for programming/debugging ARM chips

To be precise, it is designed by ST specifically for programming their own chips (not just their ARM ones) - it was never designed nor intended nor supported for programming 3rd-party chips; eg, Nordic.

The clue is in the name: ST-Link !

It is just by luck - because of the common ARM core & SWD interface - that it happens to (mostly) work with other manufacturers' chips

beginner said:

This should be part of a tutorial for beginners

Not really.

If you want support, then you need to use the supported tools.

If you choose to use unsupported tools, then you are on your own!

For a beginner, I would strongly recommend that you stick to supported tools - until you have gained sufficient experience to be able to work these things out.