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 https://github.com/rbaron/b-parasite/issues/43#issuecomment-1194451007.

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