Using Black Magic Probe with nRF52832

RE: Using Black Magic Probe with nRF52832

Benjamin Willis — Tue, 09 Oct 2018 23:45:29 GMT

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!

RE: Using Black Magic Probe with nRF52832

Andre — Thu, 13 Sep 2018 18:26:38 GMT

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)

RE: Using Black Magic Probe with nRF52832

Benjamin Willis — Thu, 13 Sep 2018 18:01:45 GMT

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?

RE: Using Black Magic Probe with nRF52832

Andre — Wed, 12 Sep 2018 07:57:29 GMT

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

RE: Using Black Magic Probe with nRF52832

Benjamin Willis — Tue, 11 Sep 2018 00:47:38 GMT

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.

RE: Using Black Magic Probe with nRF52832

Andre — Mon, 10 Sep 2018 21:57:09 GMT

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.