Unbricking A SEGGER J-Link V9 Debug Probe

Last year [Emil] found themselves in the situation where a SEGGER J-link debug probe suddenly just stopped working. This was awkward not only because in-circuit debuggers are vital pieces of equipment in embedded firmware development, but also because they’re not that cheap. This led [Emil] to take the device apart to figure out what was wrong with it.

After checking voltages on the PCB, nothing obvious seemed wrong. The Tag-Connect style JTAG header on the PCB appeared to be a good second stop, requiring only a bit of work to reverse-engineer the exact pinout and hook up an ST-Link V2 in-circuit debugger to talk with the STM32F205RC MCU on the PCB. This led to the interesting discovery that apparently the MCU’s Flash ROM had seemingly lost the firmware data.

Fortunately [Emil] was able to flash back a version of the firmware which was available on the internet, allowing the J-Link device to work again. This was not the end of the story, however, as after this the SEGGER software was unable to update the firmware on the device, due to a missing bootloader that was not part of the firmware image.

Digging further into this, [Emil] found out a whole host of fascinating details about not only these SEGGER J-Link devices, but also the many clones that are out there, as well as the interesting ways that SEGGER makes people buy new versions of their debug probes.

(Thanks Zelea for the tip)

23 thoughts on “Unbricking A SEGGER J-Link V9 Debug Probe

  1. > What I’ve discovered was that the user licenses […] are stored in clear […] and there is one RSA digital signature […]. The signature is derived from the hardware ID of your microcontroller using 65537 as the public key and a 256 byte modulus which is stored in the firmware. There is no way to calculate mathematically the digital signature without the private key which only SEGGER has.

    RSA 256 is is actually pretty easy to crack using a Capture The Flag tool (such as [RsaCtfTool](https://github.com/Ganapati/RsaCtfTool)) as short RSA keys are often used in easy crypto challenges.

  2. I’m curious about whether its just the SAM MCU based JLink’s that seem to have a built in self bricking function, or whether this also applies to some of the newer hardware, which I think uses the STM32F7 MCU.

    Incidentally, the old STM32F1 series JLink dongles, which seem to be based on the JLink OB hardware, don’t seem to suffer from self bricking.

  3. “just stopped working”. Yeah… That normally happens after a junior engineer borrows it for the first time, and clicks ‘ok’ like a demented baboon on every window that pops up when installing the pc software, and then gets bored and unplugs it mid firmware upgrade.

      1. Absolutely. However, ime firmware upgrade routines are often written with a surprising lack of robustness. I even have some keysight gear that keysight themselves can’t upgrade (and just shrug)

        1. A few comments on all of this …
          So newer J-Links do not use an STM32F7 CPU. Latest hardware uses a dual Core
          LPC4322 (M4/M0) for J-Link Base and Plus and a FPGA (Zynq) with built-in Cortex-A9 for high end models (J-Link ULTRA+ / PRO).
          Our Firmware update is in fact “bullet proof”, in a sense that were a firmware update gets interrupted,
          that will not brick the unit. Firmware update can continue the next time. That is of course if you use our boot loader and not some hacked replacement boot loader.
          We do not purposely “brick” our own products. They can be used as long as they live, and we do nothing to shorten the life span. On the J-Link V9, which we have only produced for a short period of time, as it was not dual core and most of all did not have a High-speed USB interface, we are aware of this type of problem. We have had a couple of units come back with this type of problem, where the firmware
          (or a part of it) has been lost. The units are fine if they get re-flashed.
          Unfortunately, this is not easy to diagnose, as the Read-out protection is enabled, and we also can not read back the firmware. From what we have seen, it seem like only a part of the flash content has been lost, as the debug interface was still functional and showed that a part of the program must still have been there. Why the CPU lost its memory we never figured out, but I think this is a problem on many MCUs. Some are better in this respect than others. On the current models (V10/V11), to the best of my knowledge this has not happened at all, and we are using the LPC4322 for about 5 years now.
          So to be clear: We do *not* purposely limit the life time of our products.
          We actually do the opposite and try to make them as robust as possible. The target side protection is as robust as possible, USB side protection (using regulators that can take substantial voltage spikes) etc.
          We analyze as much as possible all faults and where possible and necessary learn from things and improve the hardware. That said, I think it is very robust.
          What we do sell new J-Link is of course a process of continuous improvement. Latest generation J-Link are a lot more capable and faster than older ones.
          And on the software protection side, NZSmartie is correct:
          > here is one RSA digital signature […]. The signature is derived from the hardware ID
          > of your microcontroller using 65537 as the public key and a 256 byte modulus which is stored in the
          > firmware.
          > There is no way to calculate mathematically the digital signature without the private key which only SEGGER has.
          Yes, we use our own software “emSecure” here, which uses RSA-2048

          One note on all the cloning:
          As a company, we have bills to pay and need to stay profitable.
          We need to sell our products, which we do. Business is doing OK, I can not complain.
          Our strategy is to be fair and make money with professional users.
          This applies to software like Systemview, Embedded Studio etc.:
          They are under “Friendly license”, basically saying that anyone can use the full functionality free of charge as long as long as it is not done to develop a commercial product.
          Details: http://studio.segger.com/index.htm?http://studio.segger.com/license-sfl.htm

          We also try to make our debug probes, in which we obviously put a lot of engineering efforts,
          available to students and hobbyists.
          J-Link EDU uses the same hardware and has the same features as a J-Link Base (+ unlimited breakpoints in flash memory), and is available for $63.50 on line.
          Our J-Link EDU Mini is available for just $18. A somewhat simpler hardware, not quiet as fast, but still really useful. Basically the same features when used on a Cortex-M.

          The point is:
          We try to generate revenue from our professional users, not from students and hobbyists, who are welcome to use our tools at no charge.
          We are a fair company, we do not “brick” our own products.
          The fair thing on the other side is to buy our products (or a license for it where required, such as
          Embedded Studio or Systemview) when using them for a commercial product.

          And to Maya, and back to the original thread:

          > Unbricking A SEGGER J-Link V9 Debug Probe
          Nothing wrong from my perspective with doing that. But SEGGER did not brick it!

          And you are saying:
          > as the interesting ways that SEGGER makes people buy new versions of their debug probes.
          I am curious … Can you elaborate a bit?

          Cheers, to a happy and healty 2021!

          1. It is nice when we get a cogent response from the manufacturer / developer.
            Thank you.
            (I’ll leave it others to shred your response if they feel you have stated something in error B^) )

          2. Thanks for the detailed reply. I’ve never used a j-link. It does highlight one of my points when you say that you know that under some rare circumstances it can foul up, but you don’t know why. Over the last 30 years, I’ve written several firmware update modules, and those kind of problems are the nightmare. Especially when they only happen in the field, or you get told ‘yeah, it didn’t work one time last week, so I had to reflash it from scratch’ by a developer. However, they are almost always soluble. It’s just a matter of tickling the right engineers interest so they devote non work time to it, as it becomes a vendetta :-)

            All the best for ’21 and onwards

          3. I am the author of the above article. First of all thanks for the all the SEGGER products and support software. Nowadays you can also find the J-Link integrated in a lot of development boards. I have never said that SEGGER bricked anything. As for the clones, when detected, they keep working except for a nagging message, which I think is very generous. The reason I have some many versions of your probes is that the support for some of the processors is only found in the newer versions. I understand that most of the time this is a hardware limitation. There is simply not enough space in the firmware to support everything covered in the newer probes (but the V9 hasn’t got an update for more than a year).

          4. Thanks for an excellent and interesting post! Your mindset seems very fair and reasonable.
            I will actually “invest” in an official Jlink-EDU, a step-up from a few old re-purposed 2$ ST-Link clones I’ve used previously, for my admittedly very modest hobbyist-level J-link:ing.

            Thanks for being sympathetic to hobbyist and non-commercial users!

          5. I’m one of the people who mentioned bricking.

            My assumption, because this was such a unusual failure type, that it must be deliberate, however it sounds like the application code must contain functions which have the ability to erase sections of the program ROM, rather than having a separate bootloader application in the firmware, which is used for handling firmware updates.

            Technically I know it would be possible, somehow, for the main application code to jump into a separate bootloader block and execute code to erase a section of MCU ROM, but this seems a lot less lightly than if the code to erase the ROM was in the same application section.

            For the record, I do own a JLink Edu Mini, which from what I can remember is branded as Adafruit and was bought though a legitimate channel.

            I’m not doing any commercial firmware development.

            I also own various other older JLinks, which are most likely clones.
            Some of the “Clones” appear to be identical to real JLink’s, which made me think that they must have come from the same factory that produce the JLink’s available though the major suppliers.
            i.e Gold plated PCB’s, high quality soldering etc etc.

            Some however, are low quality PCB’s and have completely different PCB layouts.

            The bricking problem happened a lot to me on the SAM based boards which I have, and happened on multiple occasions.

            I presume since this problem only occurs on the old versions, that its not worth wasting any time to investigate the problem, but it seemed to happen fairly frequently in my experience.


            I was planning on using the JLink Edu Mini as my main programmer / debugger, but I had problems getting it to connect to a NXP K22 series MCU, so ended up going back to using the very old STM32F1 board

            For STM32 development I use a STLink, mainly because STM’s IDE/Toolchain is easier to use with a STLink

          6. On taobao(chinese aliexpress), most sellers selling j-link clones say that their products can automatically update(in fact they can’t as they can’t dump the bootloader), won’t lose firmware and very stable.
            Well, maybe it is the bad manufacture quality making firmware loss…

    1. I’m not a native speaker, but I think “they” is commonly used as a gender-neutral pronoun when the authors doesn’t know and doesn’t want to presume about the person they are referring to. It’s shorter and more readable than using “he or she”.

  4. Why not use a 2-level bootloader. The primary only downloads to RAM and has no flash driver. The secondary contains the drivers, and it’s only downloaded before an SW update, and wiped from RAM after use. Standard in automotive ECUs. An intermittent malfunction and inadvertent jump to unknown memory regions (the flash routines) can’t cause permanent malfunction anymore. Debuggers are expected to be used with half-finished, failing HW, unstable power supply, occasional short circuits by the scope probe, falling wires and the like. Any debugger HW or SW that commits suicide and corrupts itself under these circumstances is unusable.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.