Are there J-Link alternatives?

[karwosts]

Hi, just wanted to say I love the idea behind this project, and hope to someday obtain some of these for myself.

I wanted to know if you've ever explored any alternatives to jlink debuggers for programming? Given that these devices aren't really available for sale anywhere (cheaply), if we're expecting everyone to fabricate their own devices, obtaining the debugger is a pretty high hurdle to clear.

The suggested devices seem to be essentially sold out everywhere, what ones available on ebay look to be $50, and they also come with the annoying EDU restriction that sounds like it makes it essentially illegal to turn around and sell any products you make from it.

Given that most end users don't really need "debugging" since we aren't developing the firmware, we just need a way to bit-bang in the boot code. Are there other devices or techniques that could achieve this? I see some cheap ARM debuggers on Ali for ~$8 shipped, any idea if something like those work? Is there any way to just bit-bang the interface with a RPI or ESP32 gpio?

Just wondering if you've ever thought about this, to drive more adoption of this project. For a typical user who might like a handful of these devices (~5?), once you have to acquire your own expensive debugger, it probably becomes cheaper to just buy some MiFlora or something rather than spending the expense to make your own.

Thanks!

[JoelWise]

This could be what you are looking for: https://devzone.nordicsemi.com/nordic/nordic-blog/b/blog/posts/flashing-and-debugging-nrf5152-with-a-cheap-blackm

[drspangle]

I'm working on getting boards brought up using the SINKR unit, which you can find on Amazon for relatively cheap (compared to the commercial units) here: https://www.amazon.com/gp/product/B09KXSJ31D/

I wasn't able to find any of the similarly priced educational models of the suggested device anywhere. The key requirement for an alternative seems to be support for the ARM processor specified in the current design, and not much else. Note that this is my assumption, I haven't had a chance to populate and attempt to program any of the boards yet, so I can't confirm that the unit I suggested will work.

As far as other alternatives, I can't imagine it would be a fun time trying to develop that by bitbanging the interface yourself. You might have some luck with the cheap AliExpress units, but I can't say for sure.

[rbaron]

For hobbyists and makers, the best solution in my opinion is a J-Link EDU Mini. It's around $20, when it's available (I see a couple on digikey, Adafruit & Mouser are sold out). It just works. You can't use it for anything commercial.

I can't recommend cheap clones from Ali express. In my experience they are only cheaper if you don't value your time.

Some open source alternatives I'm interested in but haven't tested yet:

1. Using a Raspberry Pi + OpenOCD. This does bit-banging and I'm sure it works. This is an official method of programming the Raspberry Pi Pico (see section 5.2)
2. Using an ESP32 + Web browser (hackaday article)
3. Using a Black Magic Probe. This is more expensive but looks really interesting with the built-in debugger

[drspangle]

Got the first board soldered up just now, so I'm one step away from testing the SINKR (it's really a ULINK-2). Once I get a pogo pin clip set up I'll let everyone know how it goes.

[ryanmillerwork]

For hobbyists and makers, the best solution in my opinion is a J-Link EDU Mini. It's around $20, when it's available (I see a couple on digikey, Adafruit & Mouser are sold out). It just works. You can't use it for anything commercial.

I can't recommend cheap clones from Ali express. In my experience they are only cheaper if you don't value your time.

Some open source alternatives I'm interested in but haven't tested yet:

1. Using a Raspberry Pi + OpenOCD. This does bit-banging and I'm sure it works. This is an official method of programming the Raspberry Pi Pico (see section 5.2)
2. Using an ESP32 + Web browser (hackaday article)
3. Using a Black Magic Probe. This is more expensive but looks really interesting with the built-in debugger

I'm working on using option 2 from this list. Things have gone well except I'm unclear on how to flash the 2 files (SoftDevice and b-parasite). I think I need to use an offset for the flash address but I'm not sure what that offset should be. I tried specifying an offset of 0x2700 for the SoftDevice as per https://devzone.nordicsemi.com/guides/short-range-guides/b/getting-started/posts/adjustment-of-ram-and-flash-memory but that doesn't seem to be working. I'm also not clear if I should be using the .bin or .hex files?

[chucknorris101]

For hobbyists and makers, the best solution in my opinion is a J-Link EDU Mini. It's around $20, when it's available (I see a couple on digikey, Adafruit & Mouser are sold out). It just works. You can't use it for anything commercial.
I can't recommend cheap clones from Ali express. In my experience they are only cheaper if you don't value your time.
Some open source alternatives I'm interested in but haven't tested yet:

1. Using a Raspberry Pi + OpenOCD. This does bit-banging and I'm sure it works. This is an official method of programming the Raspberry Pi Pico (see section 5.2)
2. Using an ESP32 + Web browser (hackaday article)
3. Using a Black Magic Probe. This is more expensive but looks really interesting with the built-in debugger

I'm working on using option 2 from this list. Things have gone well except I'm unclear on how to flash the 2 files (SoftDevice and b-parasite). I think I need to use an offset for the flash address but I'm not sure what that offset should be. I tried specifying an offset of 0x2700 for the SoftDevice as per https://devzone.nordicsemi.com/guides/short-range-guides/b/getting-started/posts/adjustment-of-ram-and-flash-memory but that doesn't seem to be working. I'm also not clear if I should be using the .bin or .hex files?

Im pursuing the same thing - and i re-read the softdevice detail again - that 0x27000 is where the softdevice expects the program to be! Im still trying to work out where the softdevice needs to go - per another doc it looks like 0x1B000, but i havent gotten a chance to test it.

Per rbaron, its just the hex file we need to flash. so flash the soft device to 0x1B000? then flash _xxaa.hex to 0x27000 is my plan once I get my shipment of NRFs and assembled in the next few days

[rbaron]

I haven't messed with any of these alternative flashing methods, but here are some tricks we can use to determine the flash addresses:

The SoftDevice is the first thing that runs, and should live at address 0x0 (see datasheet, docs from Adafruit). They will eventually hand over control to our own application, and different SoftDevice versions expect the application to live at different address. In our case, S140 7.2.0, it's 0x27000.

We can verify this by taking a look at our linker script (FLASH (rx) : ORIGIN = 0x27000) and also the the two Intel HEX .hex files:

1. SoftDevice from the SDK:

$ head -n 5 $SDK_ROOT/components/softdevice/s140/hex/s140_nrf52_7.2.0_softdevice.hex
:020000040000FA
:1000000000040020810A000015070000610A0000BA
:100010001F07000029070000330700000000000050
:10002000000000000000000000000000A50A000021
:100030003D070000000000004707000051070000D6

The first line :02 | 0000 | 04 | 0000 | FA means the initial offset is 0x0000. The following lines contain the actual SoftDevice data, 16 bytes each line.

2. Our own application

$ head -n 5 _build/nrf52840_xxaa.hex
:020000022000DC
:1070000000000420B5720200DD720200DF7202008F
:10701000E1720200E3720200E5720200000000006B
:10702000000000000000000000000000E772020005
:10703000E972020000000000EB720200ED72020033

The first line :02 | 0000 | 02 | 2000 | DC means the initial address is 0x20000 (0x2000 * 16), but note how the following lines data lines have an 0x7000 offset, which confirms that the application offset for this SoftDevice is 0x27000.

I hope this helps.

[drspangle]

It's been a while since I've chimed in on this thread but I'll just say that I agree with @rbaron that the J-Link seems to be the best way to do this. I have yet to experiment with using bitbanging or an ESP32 to program the device, but my experiments so far with the Sinkr ARM programmer have been a failure. Even getting the tools working is a challenge. I hope folks have success with alternative methods but I'm going to give up on what I'm doing and just try to get a J-Link.

[ryanmillerwork]

I haven't messed with any of these alternative flashing methods, but here are some tricks we can use to determine the flash addresses:

The SoftDevice is the first thing that runs, and should live at address 0x0 (see datasheet, docs from Adafruit). They will eventually hand over control to our own application, and different SoftDevice versions expect the application to live at different address. In our case, S140 7.2.0, it's 0x27000.

We can verify this by taking a look at our linker script (FLASH (rx) : ORIGIN = 0x27000) and also the the two Intel HEX .hex files:

1. SoftDevice from the SDK:

$ head -n 5 $SDK_ROOT/components/softdevice/s140/hex/s140_nrf52_7.2.0_softdevice.hex
:020000040000FA
:1000000000040020810A000015070000610A0000BA
:100010001F07000029070000330700000000000050
:10002000000000000000000000000000A50A000021
:100030003D070000000000004707000051070000D6

The first line :02 | 0000 | 04 | 0000 | FA means the initial offset is 0x0000. The following lines contain the actual SoftDevice data, 16 bytes each line.

2. Our own application

$ head -n 5 _build/nrf52840_xxaa.hex
:020000022000DC
:1070000000000420B5720200DD720200DF7202008F
:10701000E1720200E3720200E5720200000000006B
:10702000000000000000000000000000E772020005
:10703000E972020000000000EB720200ED72020033

The first line :02 | 0000 | 02 | 2000 | DC means the initial address is 0x20000 (0x2000 * 16), but note how the following lines data lines have an 0x7000 offset, which confirms that the application offset for this SoftDevice is 0x27000.

I hope this helps.

Thanks rbaron and chucknorris101. I had actually tried putting the s140_nrf52_7.2.0_softdevice.hex at 0x0 and nrf52840_xxaa.hex at 0x27000 but either (a) it wasn't actually flashing because it was in sleep mode or something similar mentioned in the docs here or (b) it actually did work and I didn't realize it. What's the easiest way to confirm it's working?

I modified prst_config.h to:

#define PRST_BLINK_LED 1
#define PRST_LED_PIN NRF_GPIO_PIN_MAP(0, 28)
#define PRST_DEEP_SLEEP_IN_SECONDS 10

Hoping to see blinks but...no lights. Maybe I'll try to solder up a fresh one and see if it works.

[rbaron]

@ryanmillerwork I believe if you want to flash the raw firmware data directly, you'd need a .bin file, not an .hex. The hex files are text files and contain extra data that gets processed before being written to flash. There are tools to convert an .hex to .bin - we have the .bin for our application as an additional output in _build/, but we don't have it for the SoftDevice.

[chucknorris101]

The SWD esp32 guy just uses a hex2bin exe type program to convert files to bin type if there isnt extraneous information. NRF forum seems to imply thats possible with the softdevice, but it also discusses a separate bootloader in that post, is the bootloader included with the .bin in parasite makefile?

[rbaron]

@chucknorris101 no, the .bin is just the b-parasite firmware, that like we saw, needs to be flashed after the SoftDevice (which itself contains the bootloader).

[chucknorris101]

my first attempts at soldering the nrf on did not go well (not recognized by the flasher so im missing some connections on the solder end...fat fingers) and havent had a chance to fix to trial these options.

But i did find this: https://infocenter.nordicsemi.com/index.jsp?topic=%2Fsds_s140%2FSDS%2Fs1xx%2Fmbr_bootloader%2Fmbr_bootloader.html

NRF doesnt see the softdevice as a bootloader per se, but it does provide the MBR with a separate bootloader being optional

The esp-32 SWD guy in his examples seems to only flash .bin files, i plan to convert the softdevice from .hex to .bin (though im not sure it is necessary, i feel like its worth a shot), and then use the makefile generated .bin.

[chucknorris101]

I think the nrfjprog is calling the nrfutil functions. trying to get those installed was a pain, but i think that im close - just running into flags with what it asked me to input. @ryanmillerwork if you want to poke around a bit. It seems to be the function that combines the soft device and firmware and creates the bootloader...or so it seems. the output is a zip that would then be able to be flashed...maybe?

edit: still no joy. got nrfutil to compile a zip for me, but flashing the individual bins doesnt seem to do anything. there are .dat files that might be critical that im leaving out so far, and still tbd on whether a specific bootloader is generated by the utils- the documentation seems to imply for SD + Application setups it creates a bootloader for it

edit part 2: still no luck, but i did find this today: https://www.youtube.com/watch?v=d6toH-qJbOI which is maybe another path forward for pursuing, short of getting a debugger. I think other than the flash values, NRF seems to imply the RAM values need to be set properly as well, which at least to me doesnt make sense if the RAM is supposed to be wiped/reset every power cycle? but im not a RAM expert...

[chucknorris101]

@rbaron it seems nrfjprog can read the flash memory of a chip as well and dump to a file, would you be able to read a completed chip file and post here for comparison? maybe can see what addresses to load in the nrfutil outputs from the other pokings around.

I have an ESP-Prog on the way from sparkfun, which might just be the only link we need, since nrfjprog/nrfutils do all the work, not the embedded studio, we just need a way for the PC to connect directly

[rbaron]

@chucknorris101, this is the firmware dump from a working b-parasite that was compiled with the default prst_config.h.

Command I used:

$ nrfjprog -f nrf52 --readcode firmware-dump.bin

I zipped it so GitHub lets me upload it: firmware-dump.bin.zip

Hint: Run hexdump -C firmware-dump.bin | less and correlate the start of the SoftDevice and the application with the addresses and .hex files I mentioned in #43 (comment).

[chucknorris101]

Thank you! I will review tonight sometime.

In the meantime, the ESP-PROG option wasnt working, or at least was beyond my beginner level approach, in theory the FTDI chip should be able to be recognized/passthrough NRF contact with the right drivers/firmware update?, but i wasnt able to get the PC or any of the debugger software to recognize as such.

For those struggling to get a j-link - i posted a question on the NRF forum, and they indicated that the DevKit boards can be used as a debugger! So i am going to try that. I think the DK are a bit more pricy in the $50 range but not astronomical and seemingly readily available.

[chucknorris101]

The DevKit works! at least, it works because it IS a j-link. after setting up the nrf connect desktop (maybe not necessary), jlink toolchain (.dlls, etc), and setting up the nrfjprog toolchain on my cmd line, i was able to flash consistently with this setup, which uses the j-link OB interface, that has minimal at best documentation on connections online:
(Note, VDDnRF is next to a VDD nRF' pin. use Pin1 of the row, the non ' version)

Without these connections the pc wouldnt recognize the board as j-link (instead everything works flawlessly, but targets the DK itself).

And even with it I have had some issues where it wont register as connected to the 'target' bparasite. still working on those, If the make commands do not work/throw error you may need to run nrfjprog -f NRF52 --recover first to wipe it/remove write protection.

[chucknorris101]

@chucknorris101, this is the firmware dump from a working b-parasite that was compiled with the default prst_config.h.

Command I used:

$ nrfjprog -f nrf52 --readcode firmware-dump.bin

I zipped it so GitHub lets me upload it: firmware-dump.bin.zip

Hint: Run hexdump -C firmware-dump.bin | less and correlate the start of the SoftDevice and the application with the addresses and .hex files I mentioned in #43 (comment).

This bin file can be directly flashed to 0x0 with the esp32 swd flasher and result in a working bparasite!!!

I havent been able to pull it apart yet, but when ive been tinkering with the sdk, the jlink/nrfDK seem to know that the softdevice has a MBR associated, that gets generated when the nrfjprog gets called, at least when i point the nrfconnect to the DK, it shows a soft device sector and a MBR sector. the SWD flasher just sends the hex/bin to the location, and doesnt have a conversion or 'implementation' setup.

Following that logic, we should be able to flash the 'standard' MBR-SD file and then flash program to x27000. So far i havent been able to get that to work flashing any of the .bin/hex files as output from the makefile. But maybe someone else knows a better way? this was my download from a workingbparasite of the 0x0 - 0x26FFF (which should be everything up to x27000?
mbrsd.zip

[Atomicbeast101]

Is there a guide on getting the softdevice firmware compiled? I suspect the way to do this with the ESP32 option is first flash the softdevice firmware using 0x0 address and then flash the b-parasite firmware on 0x27000?

[chucknorris101]

Thus far the only guide is that the softdevice can be flashed to 0x0 but it needs to be the 0x0-0x26FFF file above. The softdevice bin alone doesn't seem to flash with esp32.

Even then getting the softdevice loaded doesn't seem to let you load program straight to 0x27000 but maybe someone more technical might know why. Something the nrfjprog command does seems to modify the output bin to something else on the chip

[Atomicbeast101]

Thus far the only guide is that the softdevice can be flashed to 0x0 but it needs to be the 0x0-0x26FFF file above. The softdevice bin alone doesn't seem to flash with esp32.

Even then getting the softdevice loaded doesn't seem to let you load program straight to 0x27000 but maybe someone more technical might know why. Something the nrfjprog command does seems to modify the output bin to something else on the chip

Makes sense. You mentioned earlier you had success with the devkit, mind sharing what model that is and possibly a guide on how to work with it?

[chucknorris101]

Thus far the only guide is that the softdevice can be flashed to 0x0 but it needs to be the 0x0-0x26FFF file above. The softdevice bin alone doesn't seem to flash with esp32.
Even then getting the softdevice loaded doesn't seem to let you load program straight to 0x27000 but maybe someone more technical might know why. Something the nrfjprog command does seems to modify the output bin to something else on the chip

Makes sense. You mentioned earlier you had success with the devkit, mind sharing what model that is and possibly a guide on how to work with it?

Yea, the one I have is the NRF52840-DK But I suspect any dev kit from them with the embedded jlink would work. It's all about getting the jlink.

As far as a guide, I can try to lay it out including things that may not be necessary but may have solved some background dependencies without me knowing. I had previously set up nrfutils toolchain, but not sure it's needed. I also installed the nrf connect software and programmer but again not sure if needed, but should give a good idea if your connections are set up correctly per my picture above. If not correct it will not show up to the system as a jlink but will be just an nrf52840 (don't be fooled thinking this is the parasite)... I haven't gotten nrfs tools to see the parasite memory/etc but segger studio works

The segger embedded studio set up direct from segger is useful and has the drivers needed, and also will have the viewer and other things for debugging as if it were just a jlink device. You'll also need to set up the nrfjprog toolchain. I'm running windows and set up powershell with choco to simulate the Linux commands.

Once you have the tools, and pathed to your file locations, you should be all set with the code provided. Enter: Make to get the code makefile to compile at any point in the process belowThis isn't dependent on connecting the device.

Connect the device, and run nrfjprog - f nrf52 - - recover. This should give you a connecting type message or that it could take some time, if not connected properly it will throw an error that it can't find a jlink, try jiggling or repositioning. Same thing if it says can't recover. I've found devices may repeatedly not recover if soldering isn't accurate. I think once I got it to work by using the esp32 to erase the protection and then it would recover, but maybe just poor connections...

Then, you can run: make flash soft_device and make flash per rbarons instructions and it should give a few lines and resolve with a run and back to cmd. Otherwise it will throw similar errors to the above. I've found once I've gotten a device to recover the rest is smooth sailing. Others may not have issue with recovery if they're better at soldering.

[oleo65]

I have been following this project for years now and have been successful in flashing the parasite with an inexpensive nanoDAP module from MuseLab.

In my understanding, every DAP compatible debugging probe should work.

As I am more familiar with python, I chose the way of flashing the .hex files with the awesome pyocd library.

It comes down to one simple command after setting the library up. No drivers or anything are needed for the debugging probes, at least with Windows 11. So there is no need to install any of the other tools or software just for flashing. (For compiling you still need the nRF SDK and a gcc toolchain from ARM)

I would be happy to contribute some more detailled instructions to some sort of documentation in this project.

[kzyapkov]

I was able to use a blackmagic probe on a cheap "Black Pill v2" to flash a Zephyr-based firmare on the b-parasite. The BMP even supports RTT which works as a log backend.

There isn't much to it -- just follow the official instructions. I can do a short writeup if there's interest.

[jrhbcn]

Hi @oleo65,

I am in the process of ordering some b-parasites and looking how to flash it. I am not sure which specific module you refer to. I hope it is OK to post AliExpress links here (if not let me know @rbaron and I will just remove them). Do you refer to this one?

• Mini DAPLink Debug Probe TYPE-C STM32 NRF51/52 ARM Cortex-M MCU JTAG/SWD/CDC Serial Port/Drag and Drop Program Keil/MDK OpenOCD

Also, I looked at the pyocd library and it seems compatible with the CMSIS-DAP emulator so cheaper ones such as this one might work.

• STM32 develops DAP downloader emulator module CMSIS debugger Keil SWD/serial port CMSIS-DAP Emulator Downloader Emulator Module

Do you think it might work with pyocd? Regards,

[chucknorris101]

@kzyapkov i think there definitely would be interest, though i know when i was looking even black magic probes were harder to come by. 'zephyr based firmware' is over my head, im sure others may feel the same

@jrhbcn I think the first link references 'jtag' which should hopefully allow it to use the 'jlink' ecosystem setup which is pretty seamless once setup. I think other options SWD/etc have been attempted but havent shown results...though likely due to lack of determined approach ... i think i posted some of my tries and fails above, but the jlink programming process seems to modify the code somehow from the basic binary when writing to the chip, maybe this is obvious to more well versed programmers, but it isnt easily SWD'd on - a firmware for a working parasite can be dumped via SWD, and flashed to another via SWD to make it work, but the output of the makefile hasnt been able to be successfully put in without a jlink until seemingly @kzyapkov just above.

[kzyapkov]

I don't own an original BMP either, they seem to be unobtainable. However, ports exist for many cheap boards, see the supported platforms in the code, each comes with instructions. I think Black Pill a good option these days. The first answer to this issue has a link to a good walkthrough, there are many other articles on the topic.

But, in short:

On linux, if you install the udev rules, /dev/ttyBmpGdb and /dev/ttyBmpTarg should point to the GDB server and target UART respectively. Then, to flash a hex file

export HEX_FILE=s140_nrf52_7.2.0_softdevice.hex
arm-none-eabi-gdb --batch \
    -ex "set confirm off" \
    -ex "target extended-remote /dev/ttyBmpGdb" \
    -ex "monitor swdp_scan" \
    -ex "attach 1" \
    -ex "load $HEX_FILE" \
    -ex "kill" \
    -ex "quit"

I didn't know about nanoDAP. They'll do the job, (as @oleo65 says) and may be easier than the BMP. I'd go for the originals from Muse Lab though, you never know what you will get with the clones, plus the authors should be supported when possible.

[jrhbcn]

I'd go for the originals from Muse Lab though, you never know what you will get with the clones, plus the authors should be supported when possible.

I agree. However, I am not sure of the right Muse Lab board as they have several very similar to each other. Let's see if @oleo65 can see these messages and clarify it.

Regards

[oleo65]

Ok, this might be a little bit confusing with all the names. 😇

I own a probe called nanoDAP (at least that's what is printed on the PCB) from muselab-tech.com which I ordered directly via their aliexpress shop. In the store it is confusingly named Mini DAPLink. I suppose that's price you pay being lost in translation somewhere between Chinese, English (and in my case German)🤷

I specifically will not recommend any of the probes since I cannot compare them in respect of functionality or firmware capabilities. I am far from an expert with this kind of little hardware and still trying to get comfortable in the whole embedded environment.

Nevertheless I managed to flash and erase the nRF52840 chip just fine using either OpenOCD or pyOCD. Additionally I also got somehow the RTT console working and rudimentally a gdb debugging environment. So in theory it should all be possible with these devices as long as they comply with the SWD specs used to communicate with the microcontrollers. 😃

Side note: In my experience, the whole Nordic ecosystem is tailored by Nordic to the SEGGER J-LINK toolchain and will work with those probes basically out of the box. If you are really unsure I would stick with those as also recommended by @rbaron in the docs. But if you are willing to tinker a little bit more and get your hands somewhat dirty, taking a different route might also be fun (and a lot less expensive).

[ZehelSitchel]

I was able to use a blackmagic probe on a cheap "Black Pill v2" to flash a Zephyr-based firmare on the b-parasite. The BMP even supports RTT which works as a log backend.

There isn't much to it -- just follow the official instructions. I can do a short writeup if there's interest.

@kzyapkov I would love a write up for using the BMP.

I used WSL Ubuntu to compile the code and Windows to flash my b-parasite boards with the GDB toolchain. But I would like to reflash them to assign different MAC addresses and do it via Ubuntu. Mostly because I can't get GBD to see the b-parasites after the original flash.

[jrhbcn]

Hello,

Just to confirm that I have been able to compile and flash the parasite firmware using a cheap blackmagic probe clone (bluepill STM32F103C8T6) following the steps highlighted by @kzyapkov and @1technophile. I have my first b-parasite running yes!!! (was quite difficult to solder the nordic chip with my soldering skills, result is not pretty but seems to work!).

I can create better detailed instructions (@rbaron let me know if you want them to be included in the documentation). For the impatient, these are the steps I followed in MacOS:

1. Flash the blackmagic probe (BMP) firmware into the bluepill STM32F103C8T6. I used a rather cheap st-link v2 for this (you can buy the blue pill and the st-link v2 as a bundle in aliexpress). I followed this guide to flash it with the stlink tool.
2. Compile the b-parasite firmware following @rbaron instructions in this github.
3. Merge the softdevice firmware and the b-parasite firmware into a single hex. I used the mergehex tool from Nordic: mergehex -m nRF5_SDK_17.1.0_ddde560/components/softdevice/s140/hex/s140_nrf52_7.2.0_softdevice.hex b-parasite/code/b-parasite/_build/nrf52840_xxaa.hex -o firmware.hex
4. Connect the blue pill to the parasite and flash the merged firmware. I followed the end of this guide to flash the firmware:

arm-none-eabi-gdb --batch \
    -ex "set confirm off" \
    -ex "target extended-remote /dev/cu.usbmodem806046B71" \
    -ex "monitor swdp_scan" \
    -ex "attach 1" \
    -ex "load firmware.hex" \
    -ex "kill" \
    -ex "quit"

[1technophile]

@jrhbcn I'm working on a tutorial for information. I will share it here once done. Should be in a few days.

[jrhbcn]

@1technophile great!! Let me know if you want me to help you in any way (maybe adding macos specific instructions if you haven't used that platform).

[1technophile]

Here is the tutorial, on macOS also ;-)
https://1technophile.blogspot.com/2022/11/playing-with-b-parasite.html

I can add it to the wiki also if @rbaron wants.

On another note, I think it could be interesting to activate the discussions module of the project as most of the issues here are more discussion oriented.

[jrhbcn]

Nice tutorial @1technophile, the only thing missing for my case/steps is that I used a bluepill as a cheap clone replacement of a proper black magic probe and had to first install the BMP firmware (my step 1) in it using yet another board (stlinkv2). The rest is exactly the same! Regards,

[dannyjim-ml]

Good to know someone else got the NRF52840DK working @chucknorris101, I picked one up myself but it seems in the 3.0.0 revision they swapped some pins around but I think I have them hooked up correctly. I'm stuck on getting the firmware to compile, some error with the nRF sdk not being able to find the gnu toolchain...any chance you have plans for writing up a tutorial?

[drspangle]

@dannyjim-ml I was able to get the firmware to compile by following the same instructions in the main wiki -- make sure you're setting the SDK_ROOT environment variable properly. The package to flash onto the device ought to be the same, AFAIK, regardless of what interface you're using to flash it with.

However, I'm working with the blackmagic-probe team to figure out why there is an error when you get to the stage in @1technophile 's tutorial where you actually load the firmware. On BluePill devices, which is what I'm running, it fails with a malloc: failed in flash_buffer_alloc. You can only see this if you're using the bmprobe firmware with the debug extensions. It seems that the flash page size on the nRF52 is reading out as a value near or over the limits of the BluePill probe's RAM, so it's trying to buffer, runs out of RAM, and fails. Hopefully I'll be able to report back soon with a fix, or there may be a firmware update for the bmprobe firmware (for BluePill devices specifically).

@1technophile: are you using a BluePill or a native BlackMagic probe? If the former, did you encounter this error? (Edit: No longer relevant. The root cause has been identified and a patch is in the works from the blackmagic team. I'm writing up a guide for a workaround now.)

[drspangle]

I worked with the blackmagic probe team and came up with a workaround, while they develop a patch for the BluePill. I'm going to write up the tutorial for how to do this. The BluePill I'm using cost around $20, so this is going to be a huge cost savings for anyone who wants to do this without having to shell out for the Segger EDU devices (assuming you can even find one).

[drspangle]

Here's how to get this working with a BluePill:

These instructions assume you have the ARM-built toolchain and all required dependencies, as mentioned on the BlackMagic probe's documentation. It also assumes you have dfu-util, bmputil or one of the other tools for flashing the probes installed and working. Finally, I am assuming that you have already compiled and hexmerge'd the b-parasite firmware and Nordic softdevice and have the firmware blob ready to go in a file named out.hex.

• Buy a BluePill, I sourced mine from here for $20 and it came with an ST-Link V2: https://www.amazon.com/gp/product/B079B7FGRB/
• Flash the BluePill using the ST-Link V2. The BluePill comes with nothing on it out of the factory, so you need to use the ST-Link to flash the initial firmware.
  • You can use the following guide to make sure your BluePill is flashed and is running firmware: https://black-magic.org/upgrade.html
  • Note that you're going to end up having to use the Black Magic Debug App (BMDA) rather than interacting directly with the BluePill probe to flash your b-parasite. This is due to a bug in the firmware for BluePill which is currently being patched. You need to first flash the device from the factory so it can be updated with other firmware and be tested in working order. Then, we need to make sure that the probe itself is running recent BluePill firmware to ensure that it behaves as expected when we connect to it from within BMDA on the host system.
  • You can test that the BluePill firmware is working by figuring out the where on your machine the handle to the probe is first. I'm running in WSL and attaching the probe to WSL using WSL USB Manager, so mine is /dev/ttyUSB0.
  • Next, run arm-none-eabi-gdb, and run target extended-remote <handle to the probe>
  • Finally, run mon version. This should return output from the actual probe firmware itself. Verify that it's recent.
• Now that we've got a working probe, we need to install the correct firmware for the BluePill, rather than the generic BlackMagic firmware. The key difference is that the BluePill doesn't support any target power modes, you may have seen other guides mention a step where you have to run monitor tpwr enable -- you won't be doing that with your BluePill.
  • Now we need to get the BluePill firmware compiled and ready. Clone the https://github.com/blackmagic-debug/blackmagic repo, or if you've done so already, make sure it's on a clean tree -- run make clean in the blackmagic repo root.
  • Next, run make PROBE_HOST=swlink BLUEPILL=1 in the blackmagic repo root.
  • Flash the resulting blackmagic.elf file onto your device and re-run the previous instructions to test that the firmware is working.
  • Next, run make clean and start from a clean tree again. Then, run make PROBE_HOST=hosted HOSTED_BMP_ONLY=1 ENABLE_DEBUG=1. This will compile BMDA, and the result will be a binary (src/blackmagic).
  • Run src/blackmagic, and take note of which port it's running on. In another terminal, navigate to the directory containing your out.hex file and run gdb: arm-none-eabi-gdb.
  • Double check that your b-parasite is wired up to the BluePill correctly.
  • Rather than connecting to the actual BluePill probe directly as we did previously, we're going to connect to BMDA. Execute tar ext :<port> inside your gdb session. Use whatever port your BMDA instance is running on -- this should have been output in the terminal window where you ran it. Mine was :2000, which I think is the default.
  • Scan for targets. Run monitor swdp_scan in your gdb session.
  • Attach to the Nordic nRF52 M4 (it should be listed as target 1) by running attach 1.
  • Upload the firmware. Run: load out.hex.
  • Launch debug with run. You're done, if you saw no errors at this stage the firmware is flashed to your b-parasite!

[drspangle]

The bug which was the root cause of the problems flashing the b-parasite firmware using the BluePill have been fixed, you can find out more details in blackmagic-debug/blackmagic#1325. Edit: This patch is now in the main branch.

This means that if you follow the instructions @1technophile provided here, with some minor changes for your BluePill, you'll be in working order. Here are the steps:

1. Plug in the BluePill, which has already been flashed with a bootloader/firmware. We're going to make sure it's up to date with the latest patch so you won't be affected by the issue.
2. Compile the BluePill firmware from source. Use make PROBE_HOST=swlink BLUEPILL=1 in the repo root from a clean working tree. Flash it to the BluePill using bmputil flash <firmware file>.
3. Physically connect the BluePill to the b-parasite and verify the voltage on the device. You can't do this from within gdb anymore, the BluePill doesn't support it. You'll want to make sure the b-parasite is being supplied with 3v3. If you haven't wired up the device correctly, you won't see this voltage (and/or you may have already seen the magic smoke come out...)
4. Go to the directory containing your compiled b-parasite firmware, that has been hexmerged with the nRF softdevice (this is detailed in @1technophile's guide). Run arm-none-eabi-gdb out.hex (where out.hex is the hexmerged binary blob).
5. Within gdb, execute tar ext <the handle you use for the BluePill>. In my case, using WSL and connecting to the BluePill using WSL USB Manager, mine is /dev/ttyACM0.
6. Within gdb, execute mon swdp_scan and verify you see the b-parasite's Cortex chipset as the first result.
7. Attach to the cortex with attach 1
8. Within gdb, execute load out.hex and observe that the sections are loaded without error.
9. Launch debug in gdb by executing run and observe that there are no errors.
10. Verify that the checksum of the loaded firmware matches the binary blob on your host machine. In gdb, execute compare-sections. If everything matches, you've successfully flashed the b-parasite and verified that the firmware was loaded successfully.

[rbaron]

Hey everyone,

just a heads up that I finally managed to merge the #76. It migrates the code from the legacy nrf-sdk to the nRF Connect SDK. The build process changed a bit, but I think most flashing methods discussed here will still work, with the added benefit that we don't have to flash the SoftDevice separately (or manually merge it with the application) anymore.

I also tried to update all the docs and add new pages to the Wiki. I linked some of the flashing method discussed here on the How to Flash the Samples page. I'm hoping the new docs make sense.

Tks!

[drspangle]

Sorry if this sounds a bit pedantic, I'm just not familiar with the terminology here. Is the idea that "samples" means firmware for running the b-parasite? If it weren't for this post mentioning it, I might not have made the connection that this is the wikipage I want to go to if I want to learn how to bring up the device and get the firmware running. Am I understanding this correctly?

[1technophile]

Thanks, fantastic to have access to the binaries from the actions

On another topic, I was thinking that the discussion module could be interesting for this project, as a lot of issues are looking more like forum topics than real issues.

[drspangle]

Thanks, fantastic to have access to the binaries from the actions

@1technophile Does this mean that the repo can be set up to have binary blob releases that are generated automatically? If so, maybe we should ask @rbaron to set that up to track updates to the main branch?

[rbaron]

Sorry if this sounds a bit pedantic, I'm just not familiar with the terminology here. Is the idea that "samples" means firmware for running the b-parasite? If it weren't for this post mentioning it, I might not have made the connection that this is the wikipage I want to go to if I want to learn how to bring up the device and get the firmware running. Am I understanding this correctly?

Samples is maybe not the ideal name, but I wanted to convey a similar idea of a "dev board" that comes with different samples, mostly because I'm hoping to support other protocols than BLE. Right now we have the main BLE firmware, and a couple of test/calibration firmwares. It's also the term used by nRF Connect for examples. I'm open to suggestions.

@1technophile I've enabled the discussions module 👌

[drspangle]

It's also the term used by nRF Connect for examples. I'm open to suggestions.

In this case, maybe the term "firmware samples" is best? (i.e., How to Build Firmware Samples, How to Flash Firmware Samples -- these seem like where I'd go if I wanted to know how to get the firmware compiled, and then put it onto the device)

[rbaron]

It's also the term used by nRF Connect for examples. I'm open to suggestions.

In this case, maybe the term "firmware samples" is best? (i.e., How to Build Firmware Samples, How to Flash Firmware Samples -- these seem like where I'd go if I wanted to know how to get the firmware compiled, and then put it onto the device)

Good idea. I had named them "firmware samples" in the main README. I will update the wiki too. Tks.

[1technophile]

@1technophile Does this mean that the repo can be set up to have binary blob releases that are generated automatically? If so, maybe we should ask @rbaron to set that up to track updates to the main branch?

Yes the repo could be setup like this with binaries attached to releases

[dannyjim-ml]

@drspangle appreciate the writeup! I've obtained a few bluepills since reading this and just wanted to add a note: I've so far bought 3 bluepills and all of them are unable to be flashed with the BMP firmware. I'm highly suspect that they might be clone chips read more here. Trying to confirm if this is actually the case and if I just have 3 bricked bluepills on hand.

Pretty close to just buying the BMP from Adafruit at this point! Either way, just wanted to make a note of that for any future tinkerers who come up against a similar issue.

[kzyapkov]

Some notes on using BMP:

Back when I looked, official BMP hardware was unobtainium, but boards are available for purchase now. I just ordered one, and encourage everyone who can afford it to do the same.

For alternative BMP hardware, I strongly recommend the "Black Pill" board instead of Blue Pill. It's almost as cheap, but way more capable. I doesn't require another SWD programmer (like STLink), but can be flashed directly using the built-in bootloader via USB. https://github.com/blackmagic-debug/blackmagic/tree/main/src/platforms/blackpillv2

Now that firmware is ported to NRF Connect, use west flash -r blackmagicprobe --gdb-serial /dev/ttyBmpGdb to flash it.

And finally, one cool feature of BMP is the RTT support, see this. If your blackmagic probe is built with ENABLE_RTT=1, Zephyr logs are accessible if you do the following GDB sequence:

arm-none-eabi-gdb --batch \
    -ex "target extended-remote /dev/ttyBmpGdb" \
    -ex "monitor swdp_scan" \
    -ex "attach 1" \
    -ex "set confirm off" \
    -ex "set mem inaccessible-by-default off" \
    -ex "file build/zephyr/zephyr.hex" \
    -ex "load" \
    -ex "monitor rtt" \
    -ex "run"

and in a second terminal, tio /dev/ttyBmpTarg (or screen/minicom/yourserialtoolofchoice)

[RobertLukan]

I am using OpenOCD and it works fine for flashing. However, I am not sure how can I do debugging ? Should I dedicate Serial/UART on the chip(solder some cables to it) and log the messages out there, or there is a way to do remote debugging. over OpenOCD. I am using OpenOCD on Raspberry PI.

[Judman]

Hey all, Looking for some help.
I need to calibrate my boards to account for the coating as discussed in issue #79 , but I am running into the same issue as shown in #71 .

I have a bluepill flashed to BMP firmware compiled using drspangle's Dec 6th instructions. I successfully used it to flash the BLE firmware on the 4 boards. I used VS code to build samples then WSL and arm gdb to flash the boards.

Linux Battlestation 5.15.90.1-microsoft-standard-WSL2 #1 SMP Fri Jan 27 02:56:13 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

I pass through the bluepill from Windows 10 to WSL v2

Bus 001 Device 004: ID 1d50:6018 OpenMoko, Inc. Black Magic Debug Probe (Application)

Now that they are all flashed I cannot get arm gdb to recognize the boards. I have connected them the same way I did when I flashed them by using the battery then connecting clk, io and gnd from the bluepill to the pogo clip.

gdb error

judson@Battlestation:/mnt/c/Users/Judson$ arm-none-eabi-gdb
GNU gdb (GNU Arm Embedded Toolchain 10.3-2021.10) 10.2.90.20210621-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "--host=x86_64-linux-gnu --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) tar ext /dev/ttyACM0
Remote debugging using /dev/ttyACM0
(gdb) monitor swdp_scan
SW-DP scan failed!
Failed
(gdb) monitor swdp_scan
SW-DP scan failed!
Failed
(gdb) monitor swdp_scan
SW-DP scan failed!
Failed
(gdb) q

I have also tried letting the bluepill and a stand alone bench power supply power up the boards and I get the same error in gdb.
I can also still see the boards reporting info to home assistant so they are powered on and functioning.

I have tried to use nrfjprog in Windows 10, but it does not recognize the bluepill as a programmer.

nrfprog

nrfjprog --family NRF52 --recover
ERROR: No debuggers were discovered.
NOTE: For additional output, try running again with logging enabled (--log).
NOTE: Any generated log error messages will be displayed.

Is there a connect under reset or something similar for reflashing the nrf52840? I really have no idea what I am doing haha I just follow the guides of smart people on here and google (which has failed me for this issue).

[DanAE111]

Looking into this as well i have an STM32F411E-DISCO which i believe should be compatible with BMP so that likely could be used (untested). But further to that the board also includes a built in ST-LINK/V2 with SWD headers.

Looks like the ST-LINK can be flashed with J-Link OB.

https://www.segger.com/products/debug-probes/j-link/models/other-j-links/st-link-on-board/

Hoping to give it a go when i can get the firmware side of things sorted out.

[Maaajaaa]

I don't know if I'm too late to the party, but I've successfully flashed my parasites using a raspberry pi 4, pretty much exactly following this tutorial. I needed to make some changes to make it work with the pi4, and I'd be up for writing a wikipage if that makes sense for @rbaron as I can imagine that many people have a raspberry pi laying around, possibly also since HomeAssistant is one use case for the parasite.

[greyeey]

To also chime in on the programming debate:
I have gotten it to work with a cheap buspirate (hw v3.6, fw 6.11) and OpenOCD (0.12 with buspirate support). I could brew up a little written instruction if anybody is interested.

[rbaron]

I just came across the nrfmicro wiki. It's a pretty great summary of using different methods of flashing, including using J-Link, ST-Link, Raspberry Pi or an STM32 board. I added a link to it to our wiki.

[imdbere]

I wanted to add that you can easily flash the hex file using a cheap ST-Link clone and OpenOCD

https://github.com/seemoo-lab/openhaystack/wiki/Flashing-nRF-with-OpenOCD---ST-Link