Segger J-Link EDU alternative

[Nogtail]

I've been trying to find myself a J-Link EDU for almost a year now with no luck. Element14 has an ETA of mid 2024 and I haven't heard back from Segger about when they might be in stock. I don't mind spending a bit on something reliable, but I can't justify a commercial J-Link for hobby projects. Is there a good alternative to the J-Link or should I just try my luck with a cheap clone? Supporting a large range of devices is important as I always seem to find myself using something different, although most are ARM Cortex-M based.

Thanks!

[josip]

J-Link EDU ia not my cup of tea because it is fixed to 3.3V target (there is no voltage translators), and there is no UART channel. I am using NXP MCU-Link (https://www.nxp.com/part/MCU-LINK) and soon will buy STLink-V3-MiniE (https://www.eevblog.com/forum/microcontrollers/stlink-v3-minie-discovered/msg4090171/#msg4090171).

For just flashing with MCU-Link I am using CLI OpenOCD (very lite executable for any OS without installation).

[pcprogrammer]

As a hobbyist myself I only use the cheap clones, but do have different ones for the different types of devices like STM32 MCU's, Atmel AVR MCU's, different vendor FPGA's. Have not looked around yet to find an open source project that allows a bluepill to do it all with one device, but it might be out there

At least there is openOCD to do the part on the personal computer.

[hans]

J-Link EDU ia not my cup of tea because it is fixed to 3.3V target (there is no voltage translators), and there is no UART channel. I am using NXP MCU-Link (https://www.nxp.com/part/MCU-LINK) and soon will buy STLink-V3-MiniE (https://www.eevblog.com/forum/microcontrollers/stlink-v3-minie-discovered/msg4090171/#msg4090171).

For just flashing with MCU-Link I am using CLI OpenOCD (very lite executable for any OS without installation).

Is that for the newer EDU's? Because my JLink V8 EDU (non-clone) can debug 1.8V targets just fine. It also does Cortex-M4 through OpenOCD even though JLink's own software suite says it doesn't support it.
Only the mini is fixed target voltage.

If you want a general purpose tool, I suppose a FTDI dongle with JTAG support could be the best option. For SWD AFAIK you only need to connect a resistor between 2 of the data pins to get a half-duplex data connection to the target. OpenOCD should take care of the rest (if properly configured).
But perhaps this is not the out-of-the-box experience you want.

[josip]

Is that for the newer EDU's? Because my JLink V8 EDU (non-clone) can debug 1.8V targets just fine. It also does Cortex-M4 through OpenOCD even though JLink's own software suite says it doesn't support it.
Only the mini is fixed target voltage.

If you want a general purpose tool, I suppose a FTDI dongle with JTAG support could be the best option. For SWD AFAIK you only need to connect a resistor between 2 of the data pins to get a half-duplex data connection to the target. OpenOCD should take care of the rest (if properly configured).
But perhaps this is not the out-of-the-box experience you want.

Yes, you are right. I was thinking on mini.

[DavidAlfa]

The regular ST-Link v2 can be converted to the jlink edu.
https://www.segger.com/products/debug-probes/j-link/models/other-j-links/st-link-on-board/

[Rudolph Riedel]

The regular ST-Link v2 can be converted to the jlink edu.
https://www.segger.com/products/debug-probes/j-link/models/other-j-links/st-link-on-board/

Yes, but: "The firmware is only to be used with ST target devices."
And the last time I tried this since I desparately needed a JLink but only had a ST-Link, the Segger software refused to flash my non-ST target.

[optotester]

Hi,

Was in the same situation and bought one last month from https://kamami.pl/en/stm32-programmers/178667-j-link-edu-8-08-90.html

Got delivered within a week. At the time they had something like 3 in stock, not sure now (they provide stock by phone or email).

They only deliver in the EU though so you may have to go through a reshipment service.

[luiHS]

For just flashing with MCU-Link I am using CLI OpenOCD (very lite executable for any OS without installation).

Where can I get that utility?, I can't find it.

Always miss a utility like Segger's Jflash to simply be able to load the executable into the microcontroller without the need to use MCUXpresso or in some cases to load an executable whose sources are not from MCUXpresso (Teensy with the Arduino environment).

Neither PE Micro nor the NXP programmers include any utility like the one Segger provides with Jflash, or ST with STM32 CubeProgrammer.

[peter-h]

I have a Jlink EDU which you are welcome to buy from me. Got it about 6 months ago. It does nothing which the STLINK V3 doesn't do, AFAICT, when using ST Cube IDE, which is all I do.

If interested, PM me

[josip]

Where can I get that utility?, I can't find it.

Always miss a utility like Segger's Jflash to simply be able to load the executable into the microcontroller without the need to use MCUXpresso or in some cases to load an executable whose sources are not from MCUXpresso (Teensy with the Arduino environment).

Neither PE Micro nor the NXP programmers include any utility like the one Segger provides with Jflash, or ST with STM32 CubeProgrammer.

You should download sources and build OpenOCD by yourself. At the end you should have exe CLI file that need only config (txt) file related to master / target device for flashing. There is no installation of anything, just copy openocd generated binary / config where you need it.

Or you can download pre-built OpenOCD for Windows ...
https://gnutoolchains.com/arm-eabi/openocd/

Here is flashing hex binary file with MCU-Link as master and K32L2A31 as target on WinXP command prompt (I patched OpenOCD source by myself  to support new K32L2A familly, so there are some warnings / errors reported)...

D:\>OpenOCD\bin\openocd -c "adapter driver cmsis-dap" -f "target\klx.cfg" -c "program fb.hex verify reset exit"
Open On-Chip Debugger 0.11.0 (2021-10-16) [https://github.com/sysprogs/openocd]
Licensed under GNU GPL v2
libusb1 09e75e98b4d9ea7909e8837b7a3f00dda4589dc3
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "swd". To override use 'transport select <transport>'.
Info : add flash_bank kinetis klx.pflash
Info : CMSIS-DAP: SWD Supported
Info : CMSIS-DAP: JTAG Supported
Info : CMSIS-DAP: FW Version = 1.10
Info : CMSIS-DAP: Serial# = XXXXXXXXXXXX
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 1 TDO = 1 nTRST = 0 nRESET = 1
Info : CMSIS-DAP: Interface ready
Info : clock speed 1000 kHz
Info : SWD DPIDR 0x2ba01477
Info : klx.cpu: hardware has 2 breakpoints, 2 watchpoints
Info : starting gdb server for klx.cpu on 3333
Info : Listening on port 3333 for gdb connections
Error: DP initialisation failed
Info : SWD DPIDR 0x2ba01477
target halted due to debug-request, current mode: Thread
xPSR: 0x61000000 pc: 0x00004096 msp: 0x1fff8400
Info : SWD DPIDR 0x2ba01477
Error: Failed to read memory at 0x40048024
Info : Kinetis K32L2A31 detected: 2 flash blocks
Info : 2 PFlash banks: 256k total
Info : Disabling Kinetis watchdog (initial WDOG_CS 0x00002180)
** Programming Started **
Info : Padding image section 0 at 0x00000008 with 1016 bytes
Info : Flash write discontinued at 0x00000410, next section at 0x00001000
Warn : MAXADDR1 0x20 check failed, please report to OpenOCD mailing list
Info : This device supports Program Longword execution only.
Info : FOPT requested in the programmed file differs from current setting, set 'kinetis fopt 0x3d'.
Info : Trying to re-program FCF.
Info : This device supports Program Longword execution only.
Info : This device supports Program Longword execution only.
** Programming Finished **
** Verify Started **
** Verified OK **
** Resetting Target **
Error: DP initialisation failed
shutdown command invoked

[thm_w]

https://www.eevblog.com/forum/testgear/alternative-to-segger-j-link-edu/

[robca]

I have a Jlink EDU which you are welcome to buy from me. Got it about 6 months ago. It does nothing which the STLINK V3 doesn't do, AFAICT, when using ST Cube IDE, which is all I do.

Pretty sure you are right for the STM32 with ST Cube IDE.

With certain processors (e.g. nRF52), JLink can use Monitor Mode Debugging, which is a clever way to help debug environments like the Nordic SDK, where there is a real time component managing the Bluetooth stack. Normal debugging will crash the communication stack.

More here: https://github.com/NordicPlayground/j-link-monitoring-mode-debugging. Incidentally, there is a weird issue when using FP code, which I reported here https://github.com/NordicPlayground/j-link-monitoring-mode-debugging/issues/5. It has been fixed on the Segger side after I reported it, but might not be on the Nordic side

For situations like those, Segger's Jlink is the only (sane) option. Might be useful with other, similar multitasking targets

[peter-h]

Debugging in real time has not been possible since "bond-out" CPUs went out of fashion, in the 1990s.

I used to have a Japanese ICE (in circuit emulator) for the Z180 (cost about £10k) which had a trace buffer of a few k words, so you could trace a whole ISR in real time; the CPU knew nothing about it.

We also had an American-made ICE for the 80x286, which was a full length doubled-up ISA card in a 25MHz Compaq PC, which did something similar. Cost well into 4 digits. Wonderful for tracing code around dongles (which often used timers to detect single step debugging attempts)

Faster CPUs put an end to all this. Tektronix tried for a while to make logic analyser features which did a similar job, with code disassembly, symbol listing, etc. I stopped following that a long while ago. On-chip caches killed that off.

None of these debuggers we are talking about here are anywhere near real time, because they use a hardware address match (a feature of the CPU) and then extract data via a serial interface running at some MHz (JTAG or SWD; not sure of the difference, if any). Some debuggers can do a "trace" by setting a new breakpoint to the next instruction and running to it, but this isn't real time; it is something like 100x or 1000x slower.

The main feature, arguably, of the expensive Seggers (not the EDU) is that they can dynamically patch jump instructions into the CPU FLASH and use this to deliver an unlimited number of "hardware" breakpoints. The 32F417 I am using has on chip support for 5, which is normally OK but if you exceed it, the debugger blows up and you have to reload the code and start again.