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"

[wpaul]

I finally had the chance to try my ST-LINK V2 with my nrf52 boards, and I want to make a couple of clarifications.

First, the correct command to use is actually this:

openocd -f interface/stlink.cfg -f target/nrf52.cfg -c "gdb_flash_program enable" -c "gdb_breakpoint_override hard"

Note the "target/nrf52.cfg" instead of "board/nordic_nrf52_dk.cfg." The latter is specifically for the J-Link debugger on the DK board.

You need to connect the debugger to the "Debug In" port on the nRF52 board. The SWDIO, SWDCLK and GND pins must be connected correctly. Below is a photo of the adapter connected to my nRF52832 board:

If all goes well, you should see this:

Open On-Chip Debugger 0.10.0+dev-00581-g1b864d6e-dirty (2018-11-25-00:21)
Licensed under GNU GPL v2
For bug reports, read
openocd.org/.../bugs.html
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 1000 kHz
force hard breakpoints
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : clock speed 950 kHz
Info : STLINK v2 JTAG v21 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.234166
Info : nrf52.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : Listening on port 3333 for gdb connections

I tested both my nRF52832 DK and nRF52840 DK boards and was able to debug and flash both of them with GDB.

Second, regarding mass erase, I tried the "nrf5 mass_erase" command with the ST-LINK debugger and it actually worked, however I took a closer look at the nRF52832 documentation and the OpenOCD source code and I think I understand why.

The Debug and Trace section of the manual states that there are actually two debug ports: the DAP and CTRL-AP. The former is what's used for standard ARM SWD, and this is what OpenOCD uses to talk to the chip. The CTRL-AP is separate from that and implements a few special commands only.

There are two ways to do a mass erase:

1) Use the ERASEALL register in the NVMC controller block.

2) Issue an ERASEALL command via the CTRL-AP port.

The ST-LINK V2 can do 1), but it can't do 2).

OpenOCD implements flash support for the nRF52 by accessing the NVMC registers via SWD. Basically, it performs the necessary NVMC register accesses to initiate a flash sector erase and write and then just uploads the data into place. To issue a mass erase command, OpenOCD also just uses the ERASEALL register in the NVMC. Currently it does not have support for sending an ERASEALL via the CTRL-AP port.

But if the APPROTECT bit is set, this won't work anymore: access to the DAP/SWD port would be blocked, and you'd no longer be able to debug or flash the device. (You'd only want to do this for deployed devices so that people can't reverse-engineer your code.) The only way to recover from this is to issue an ERASEALL via the CTRL-AP port instead, which blanks out everything except for the factory info area. In theory it should be possible for someone to patch OpenOCD to implement support for this with low-level debuggers, but it would never be possible to do it with the ST-LINK V2.

Regarding what's suitable for beginners: even if a beginner might have an easier time with the supported tools, that doesn't mean they're not entitled to a good explanation of how things work when they ask. Just telling someone "don't do that" is not as useful as explaining why it's bad to do that.

Another thing to bear in mind is that it's often the case that each ARM SoC manufacturer has their own preferred debug tools. That's nice and all, if you assume that a given customer is only ever going to produce one ARM product using parts from just one vendor. Often that's not the case. It can be frustrating if you buy one set of tools for vendor A's parts, and are then faced with potentially having to buy another set of tools for vendor B's parts, especially if vendor A and B both use Cortex-M cores which both speak SWD. In effect you're being told to buy a second tool that's 99% the same as the first one. So if there's a chance you can use one set of tools for both vendors' parts, why not try?