Using Black Magic Probe with nRF52832

[Benjamin Willis]

Hello Community,

I am trying to use Black Magic Probe, an open-source ARM GDB debugger to develop an embedded ARM application using an nRF52832. Here are the parts that I'm using

ARM Embedded toolchain (GNU gdb (GNU tools for Arm Embedded Processor 7-2018-q2-update) 8.1.0.20180315-git)

bumpy0.2 from electronut ->(firmware v1.6.1-50-g7663794-dirty), programs and debugs using SWD. This is basically a cheaper version of the real black magic probe, but they use the same firmware.

BL652 (this is a bluetooth module made by Laird that has an nRF52832 as its machine. It's basically an nRF52832 with an antenna that's certified by the FCC)

I'm having problems getting the bumpy to recognize the BL652 as an nRF52832 device. When I connect to the device while running GDB, Black Magic Probe is only able to detect the architecture of the device. I need it to detect the actual device, nRF52.

Here's a screenshot displaying the problem:

As can be seen, there's a warning after attaching the device, saying that a required memory element is missing.

According to the blog post from this developer (link to the webpage below, look into the comments below the blog post), GDB cannot recognize the device and therefore programming is not possible. He proposes a solution to read the device ID and then update the Black Magic Probe firmware to recognize the new device ID.

https://www.rogerclark.net/dont-buy-this-smartwatch-fitness-tracker/

So I went on the nordic devzone and there was a post describing how to do this:

https://devzone.nordicsemi.com/f/nordic-q-a/22089/specific-unique-id-for-device-detection/86795#86795

The post however only describes how to read this device ID using mechanisms in the nordic SDK. Is there anywhere that I can find the register address of the device ID and read it with GDB?

If anybody has experience using Black Magic Probe with nRF52 and has any advice on how to make this debugger work with it, it would be greatly appreciated!

[Andre]

I have flashed a firmware from http://builds.blacksphere.co.nz/blackmagic/ to a BluePill

I get this when I connect to an nRF52

(gdb) target extended-remote /dev/ttyACM0
Remote debugging using /dev/ttyACM0
(gdb) monitor swdp_scan
Target voltage: ABSENT!
Available Targets:
No. Att Driver
 1      Nordic nRF52
 2      Nordic nRF52 Access Port

Regarding device ids, if your nrf is newer then the bmp firmware can recognise, you can build your own firmware build. In that case, check out the source (github.com/.../blackmagic.git)  and look at src/target/nrf51.c and around line 166 you'll see various IDs for nrf52

	case 0x00AC: /* nRF52832 Preview QFAA BA0 */
	case 0x00C7: /* nRF52832 (rev 1) QFAA B00 */
	case 0x00E3: /* nRF52832 (rev 1) CIAA B?? */
	case 0x0139: /* nRF82832 (rev 2) ??AA B?0 */
		t->driver = "Nordic nRF52";

Where you can add your revision in case it is missing. You might have to remove the -Werror from the Makefile as newer gcc versions give more warnings.

[Benjamin Willis]

That was my suspicion! I tried to update the firmware on the device but I get an error message when I try:(I didn't mention this in the original post because I wanted to focus on the immediate problem first, which was recognizing the device)

dfu-util: Lost devvice after RESET?

Have you ever seen/heard of this Andre? If so, do you know the cause?

I'm running fedora 27 by the way.

[Andre]

Attempting to update the firmware on my BluePill using dfu-util gives me the same message. I have an idea what might be causing it. A hard wired USB pull up resistor might prevent the device from re-enumerating after the bootloader has been entered. For this I suggest to file a bug report at electronut.

At this point I would suggest to use another SWD probe to reprogram your probe with the latest firmware. It seems they've added a new variant to their firmware last July: https://github.com/electronut/blackmagic/commit/0f5e554065eec2b0dd7e61b57889e1ac74f57418 

[Benjamin Willis]

Thank you for the insight Andre. You've been a huge help! I've contacted several individuals about this issue as well as electronut. Regarding your advise in the second paragraph, how would that reprogram work? Would I have to compile a new image for the BMP probe and upload it through the probes SWD ports? If so, I would have to get a device that would know the MCU of the BMP I'm flashing to, right?

[Andre]

On the page https://github.com/electronut/ElectronutLabs-Bumpy there is a header "Bumpy Firmware", where the steps to build the firmware are explained.

Building the firmware produces a number of files. When you flash the blackmagic_dfu.hex into the probe (using SWD), After that you should be able to use dfu-util to flash the blackmagic.bin firmware (using USB)

[Benjamin Willis]

I found the issue. The github page says that we should type

]$ dfu-util -d 1d50:6018, 6017 -s 0x08002000:leave -D <binary>

The issue was being caused by the "...:6018, 6017" bit. The fix was to use either 6018 or 6017, but not both. I used lsusb to find the exact name of the device (it was always either 1d50:6018 or  1d50:6017) and this worked every time. Thank you for your help!