Segger J-Link

[mbrockdev]

Hi all,

I know during covid segger j-link prices went crazy (shortages) - been out of the industry for a while - come back needing to pick one up and noticed they are still stupidly expensive - what is the go to thing these days? I've seen Pi Pico's can be used for SWD debug, but not sure how good that is? Don't want to be fighting the tool...

Thanks in advance

Matt

[eleguy]

ST-Link programmer/debugger to rescue?

[GromBeestje]

They've always been expensive. Primary target commercial use. For the EDU version, it seems, they only offer the mini, they dropped the regular EDU it seems.
And well... there are the clones, in varying quality, with or without level shifters in place.

Looking at what Raspberry offers, it's a CMSIS-DAP based probe. If that is their official offering, it should be good.
And if you can run that firmware on another board, I expect it will perform the same.

Other options include ST-Link clones, and FTDI based board.

Basically, all of these will work with OpenOCD. So if your target is supported by OpenOCD you're fine. There is also a Python based PyOCD, but I never got that working smoothly.

Another option would be a Black Magic Probe. These devices take a different approach and integrate a GDB debugger in the probe, and you connect your GDB to a "serial port" to debug the target. Also check the supported devices here.

The official Black Magic Probe boards do contain a level shifter, but many of the other options lack such, so that is also something to consider, what voltage is your target running at.

[ajb]

It would help to know what devices you're looking to work with.  There was a thread here not too long ago discussing some debug probe options: https://www.eevblog.com/forum/microcontrollers/sts-gdb-server-probe-rs-jlink-etc-what-are-the-differences-between-them/msg5798911/

[peter-h]

I looked at these a while ago and tried the Edu. A waste of money IMHO against the STLINK V3, unless you want the feature whereby they patch the CPU FLASH on the fly to get loads of "hardware" breakpoints, but only their top models do that.

[voltsandjolts]

IMHO the Segger tools are among the best in the business. The J-Link just works, reliably, whatever platform, whatever ide, whatever mcu, plug-in and get going on your code. The best feature for me is the ozone programmer/debugger, which gives me the freedom to choose my editor and build system. Saying goodbye to the oem ide's made life easier tbh. All for £150 on a second-hand J-Link Plus I bought on this forum - bargain.

That said, there are likely low cost tools that can offer most of what the Segger tools have, although I've not felt the need to look.

[mwb1100]

only their top models do [flash breakpoints].

I believe all J-Links (including EDU) are licensed for flash breakpoints except the base model.  I believe that for base models you get an "unlimited" trial.

The ARM cores I've worked on inthe last decade have has 6 hardware breakpoints and that has usually enough been enough for me.  Though occasionally I have to jump through some hoops to juggle which are enabled at any particular time.

[mwb1100]

IMHO the Segger tools are among the best in the business..

That has been my experience too, though on ARM-based ST-Micro devices I had just as good an experience with ST-Link V2 - even the ultra cheap clones.  As I mentioned in the thread linked to by @ajb, my understanding is the the ST-LINKs can be used with non-ST devices however I don't have experience with that.

[ColinB]

The Segger J-Link is solid. But it is expensive, starting at 500 USD for the base model (though EDU might be an option, but I haven't looked at it since I like to avoid products with usage restrictions).

If I was shopping for an alternative ARM programming, I'd look at the Black Magic Probe. https://black-magic.org/. It is open source. It has a GDB server built-in which should make it more convenient to use, than a lot of the more limited low-cost JTAG/SWD like Olimex JTAG or RP2030 DAP etc.

If you're using ST or NXP products they have good low-cost programmers for their devices, the ST-Link or NXP MCU Link Pro.

[__george__]

If you're using ST or NXP products they have good low-cost programmers for their devices, the ST-Link or NXP MCU Link Pro.

Nordic as well, they actually use a Segger debugger in their dev boards. But it can only be used with Nordic chips :/

[peter-h]

Is this a Segger product, or a fake?

https://www.ebay.co.uk/itm/316519892284

What should be the minimal software for loading code into a F4xx?

I ordered one, because the GD 407 seems dead with the STLINK V3
https://www.eevblog.com/forum/microcontrollers/opinions-on-st-32f407vgt6-versus-gigadevice-gd32f407vgt6/

[voltsandjolts]

Enjoy your _obviously_ fake J-Link which illegally uses Segger copyrighted software for developing your commercial copyrighted firmware product.
Do you see the irony?
Do you believe in karma?

[peter-h]

Read the above link about the GD32F407 which is "dead" with an STLINK debugger. This is an experiment. I am not using the device commercially.

Segger did sell a debugger for about 60 quid; I bought one.

[voltsandjolts]

You're experimenting with replacing the STM mcu in your commercial product with a cheaper GD, for commercial benefit.
But this isn't commercial work.
OK.

[peter-h]

Gosh you are sitting on an impressive high horse today

The GD 407 doesn't have hardware crypto and is of no use for whatever I might be selling. Like I said, and I can't keep repeating it for ever, this is an experiment. I would not use a chinese CPU in production - notwithstanding that during covid the ST chips were unavailable while the chinese ones were - given the current political risk. I use STLINK debuggers for everything including production. Tested a Segger EDU debugger, it didn't do anything special, so I sold it, otherwise the house just fills up with junk. This one is to see if that GD 407 chip is real, or another fake.

Happier now?

[voltsandjolts]

Oh, just experimenting, eh.

Well that's fine, because copyright law doesn't apply to hobbyists, and importing counterfeit goods is totally fine 

[mwb1100]

FWIW I worked a project that used a GD32F103 part because of ST supply problems during covid, and it worked fine with Segger tools - once we figured out that code could only run from the first 256K (or 128K - I can't remember for sure) of flash due to the shadow RAM.  That fact wasn't documented in the original references GigaDevice provided.

The GD32F103 is otherwise a very close clone of the STM32F103.  There was one minor issue with I2C where using a certain register access order worked on ST but didn't on GD and we had to do a little bit of rejiggering to get the code to work on both.

Having only half the flash executable was a big deal though, it forced us to redo our flash update design.

[zapta]

What is your target architecture?

If it's ESP32, RPI Pico, or STM32, there are inexpensive alternatives that work well (my experience is with platformio).

[bson]

If I was shopping for an alternative ARM programming, I'd look at the Black Magic Probe. https://black-magic.org/. It is open source. It has a GDB server built-in which should make it more convenient to use, than a lot of the more limited low-cost JTAG/SWD like Olimex JTAG or RP2030 DAP etc.

I just got a Black Magic.  Haven't had a chance to use it "for real" yet, but plugged it in and confirmed that gdb can connect to it just fine.  Pretty handy not to have to run openocd, although the latter is certainly more full featured and easily modified for example to support a custom RTOS.  The Black Magic can be used without gdbserver as well.  And it's not vendor locked the way e.g. stlink v3 is (which is a pretty nice device IMO).

[julian1]

Openocd has patches for GD32. A generic debugger + openocd makes sense, unless support for gd32 is specifically listed.

https://review.openocd.org/c/openocd/+/6543
https://review.openocd.org/c/openocd/+/6527
https://github.com/openocd-org/openocd/blob/master/src/flash/nor/stm32f1x.c

[bingo600]

If I was shopping for an alternative ARM programming, I'd look at the Black Magic Probe. https://black-magic.org/. It is open source. It has a GDB server built-in which should make it more convenient to use, than a lot of the more limited low-cost JTAG/SWD like Olimex JTAG or RP2030 DAP etc.

I just got a Black Magic.  Haven't had a chance to use it "for real" yet, but plugged it in and confirmed that gdb can connect to it just fine.  Pretty handy not to have to run openocd, although the latter is certainly more full featured and easily modified for example to support a custom RTOS.  The Black Magic can be used without gdbserver as well.  And it's not vendor locked the way e.g. stlink v3 is (which is a pretty nice device IMO).

I just build one, for a Blackpill (401cc)
Not as fancy as yours - No level xlate , but not $75 either
https://github.com/blackmagic-debug/blackmagic/tree/main/src/platforms/common/blackpill-f4

Bootloader & Firmware built & loaded fine.
Now to solder pins on the Blackpill

Tip: The User key is active low

[thm_w]

Is this a Segger product, or a fake?

https://www.ebay.co.uk/itm/316519892284

Old clone, V9, last supported firmware is probably from 2021: https://uglyduck.vajn.icu/ep/archive/2019/05/Unbricking_a_SEGGER_J_Link_v9_debug_probe.html
Lots of newer clones exist, eg V12: https://www.aliexpress.us/item/3256807767975833.html

[peter-h]

What is the minimal software which is likely to run on it, for loading code to the GD 407, from Cube IDE v1.14 (which supports Segger debuggers - or at least did work with the Edu a couple of years ago)?

I read that uglyduck article and the guy is an expert at this

[peter-h]

I installed Ozone and it seems to see the chip but it doesn't look like Ozone is capable of FLASH programming. What sort of tool is needed for that? The Ozone manual says nothing. Sounds like I need J-Flash, and that worked fine.

Cube IDE does not run with the debugger either. When I do F11 (build and load FLASH) even with a ST chip it says "failure to execute MI command". With the GD407 it doesn't find an ST device which is probably not surprising.

I will update here
https://www.eevblog.com/forum/microcontrollers/opinions-on-st-32f407vgt6-versus-gigadevice-gd32f407vgt6/

[__george__]

I installed Ozone and it seems to see the chip but it doesn't look like Ozone is capable of FLASH programming. What sort of tool is needed for that? The Ozone manual says nothing. Sounds like I need J-Flash, and that worked fine.

Cube IDE does not run with the debugger either. When I do F11 (build and load FLASH) even with a ST chip it says "failure to execute MI command". With the GD407 it doesn't find an ST device which is probably not surprising.

I will update here
https://www.eevblog.com/forum/microcontrollers/opinions-on-st-32f407vgt6-versus-gigadevice-gd32f407vgt6/

Ozone is certainly possible to do flash programming.  I have used it multiple times and they also advertise it in their front page. But if you cannot connect to the debugger it cannot help you I guess.

[bingo600]

Cube IDE does not run with the debugger either. When I do F11 (build and load FLASH) even with a ST chip it says "failure to execute MI command". With the GD407 it doesn't find an ST device which is probably not surprising.

david_alpha has "beaten" Cube IDE into submisiion for Pyua (Non ST) , in the Puya thread.

[peter-h]

Right, but he is an expert

I have no real need to run Cube with the Segger box. I just got the (fake) Segger to load code into the GD 407, which it does do, using J-Link.