Segger J-Trace does less than J-Link?

[kerouanton]

Hello to all official J-Link and J-Probe users,

A few weeks ago I decided to start focusing on ARM development and spent days to choose which tools I would need. So, after studying documentation, websites and reviews, I bought from Segger a J-Trace Pro Cortex-M, believing it would handle all the needs for a long time.

My current needs are :
- flashing + debugging + tracing Cortex-M devices (the reason I bought the J-Trace Pro Cortex-M),
- flashing a few Cortex-A devices (I discovered that the Cyclone FPGA embeds Cortex-A cores), maybe debugging them but no tracing.
- in the future, maybe play (flash+debug) Risc-V devices, but that's not a priority.

When explaining my needs, Segger told me I chose the wrong model and that I should upgrade it to the full-featured 1'980€ J-Trace Pro Portex probe. That's probably out of my hobbyist tight budget (not counting the return shipping fees, around 100€ forth and back).

For this reason, I need clarification before any return or deciding anything, as on the Segger website, the information is not clear for me. 

I read on their J-Link "comparison" page (https://www.segger.com/products/debug-probes/j-link/#comparison) that the full J-Link probes family (except the Edu model) can support Cortex-A, Cortex-R, Cortex-M, Risc-V cores and more.

I also read on their J-Trace Pro "Key Features" page (https://www.segger.com/products/debug-probes/j-trace/#key-features) that all J-Trace Pro models all have "Full J-Link Debug Functionality".

I can't understand for this reason why any J-Link probe, even the 398€ J-Link Base support all CPU families but that the J-Trace Pro Cortex-M cannot.  When buying the device, I really thought it was able to support the "Full J-Link Debug Functionnality" that I had read on the J-Link page. For me, it meant that all cores described as supported on any J-Link were supported, but that the Trace feature was only available for Cortex-M.

I only need to *trace* Cortex-M, nothing else. It doesn't make sense that a 1'500€ device does much less than a 398€ device or even than the 998€ J-Link Pro which seem to share much hardware features with the J-Trace Pro. If this was clear on the website, I probably would not have bought the J-Trace Pro.

In advance, thank you for your answers. That will help me decide what to do.

Best regards and I hope your answers will also help other people to decide without making the same mistake as I did 

[ataradov]

Well, they do strange software locking of features to get more money. This is their business model, basically.

One generic advice - don't expect a lot from trace. It is rarely useful in practical applications and in almost all cases there are better ways to debug the issue without involving the trace. So, I personally would focus on getting the debugger you need ignoring the trace support. If it is there - nice, otherwise - don't worry about it.

And you will also find that a lot of devices don't even implement trace support.

One trace-related feature I found useful is MTB present on some Cortex-M devices. It does not even need any debugger support and trivial to enable from the firmware. It then on each taken branch writes source and destination address into the circular buffer. Really easy to setup and interpret by hand and in majority of cases this is all you need to know. But unfortunately it is very rarely implemented.

[thm_w]

Can you return it?
What are you using tracing for as a hobbyist?

Get a jlink pro clone for your cortex-a stuff, if EDU does not support them.

[rsjsouza]

For this reason, I need clarification before any return or deciding anything, as on the Segger website, the information is not clear for me. 

Their J-Trace comparison page shows the Cortex M model does not support any of the other Cortex cores.
https://www.segger.com/products/debug-probes/j-trace/#supported-devices

In my experience, Trace is useful in very specific cases where all other debugging techniques present on the upper abstraction layers can't get to the root cause of the problem. In other words, Trace will never be your first line of defense against a problem especially if you have RTOSes, Protocol libraries (BLE, USB, etc) or otherwise any higher level abstraction with their own context-debugging capabilities. Trace will output raw assembly data (with proper correlation with your source code if using the appropriate IDE) and allow you to navigate at the lowest level possible. It may also allow real-time monitoring of specific memory regions (DWT) that can help with runaway arrays and other unexpected and uncontrollable conditions.

The difference in price for a full blown Trace probe that supports Cortex R or A is the sheer complexity that demands faster hardware and a more intricate firmware. Cortex M Trace is a lot simpler when compared to ETM and, depending on the device manufacturer, can be physically quite different, with many data lanes for ETM.

If you are not seeing the immediate need for Trace, I would return this probe and get the full featured non-Trace probe from them.

[kerouanton]

Thank you for your quick answer. I'll see with Segger what is possible. 

By the way, in the case I keep the J-Trace Pro (from what I understood their return policy is crap, 20% restocking fee etc.), if I buy a J-Link Base, the low-end model that doesn't seem to come with licenses for Ozone etc, do you know if I connect it along with the J-Trace Pro which has the licenses, it can use Ozone etc? Sorry to ask so dumb questions 
And what about the Chinese clones I see everywhere on Aliexpress?

[eutectique]

Ozone will nag you with the pop-up saying "you can only use Ozone for non-commercial purposes". There is a "stop nagging me for today" checkbox though.

[kerouanton]

that's good to know, thanks

[thm_w]

And what about the Chinese clones I see everywhere on Aliexpress?

Thats what I told you to get if EDU is not enough. Jlink V9 pro is $20. V11 is more no idea if its worth it.

https://www.aliexpress.com/item/1005004773251586.html
https://www.eevblog.com/forum/microcontrollers/jlink-ob-clone/
https://www.eevblog.com/forum/microcontrollers/j-link-clone-with-j-flash-lite/
https://www.eevblog.com/forum/microcontrollers/segger-jlink/

[kerouanton]

Thank you, I've put one in my aliexpress basket. Have a good weekend

[GromBeestje]

Keep in mind not all clones contain a level shifter. Make sure to check this if your voltage ain't 3.3 Volt.
Also, clones may **OUTPUT** 3.3 Volt on the VTref pin. This can usually be disabled by a jumper inside.

[hans]

I have a J-Link EDU V8, and in theory it doesn't support Cortex-m4, m7, etc. I've used it to debug countless of STM32F4s and other m4 CPUs without problems, however, that is with a 3rd party debugtool "openocd". It is probably more mechanical in generating SWD commands  to support the necessary SWD and Flash programming commands for each target (that is, if someone on the community wrote a functioning target script for it). Segger may eventually drop a probe generation simply because it gets too old. This can allow you to still get some extra mileage of JLink tools that dont officially support e.g. Cortex-A processors, but having the hardware (e.g. JTAG or SWD) to do so... but it may not be without bumps as OpenOCD afterall is a community-sourced project.

I've since then gotten a J-Link EDU Mini, as I needed to debug some Cortex-m33 device, and its securezone stuff can be a bit iffy in OpenOCD (especially on niche targets such as EFR32 radio SoCs). With official J-Link support, I can use IDEs such as SiLabs SimplicityStudio, which debugs using Segger's Jlink executables instead of Openocd.
Its somewhat funny that Segger is so vocal about "illegal" clones of probes that implement their API (or use their HEX as well? IDC) But then plenty of hobbyists and the like use 3rd party PC tools to drive their probes, potentially.. Its similar with buying a Saleae clone that was made to work with the Logic software, but then ending up using Sigrok anyway.


But yeah , the times I have needed instruction or data trace has been very limited as well. Maybe only 1 or 2 times it was hard to pinpoint exactly where a HardFault was generated in my code, and that took some extra time.. But I'm fairly certain that learning a new tool also costs time, so that may tie it down, and with the limited occasions of needing it, I skipped it for hobby use.

[mac.6]

Remember that some cortex m0+ have ETB included (Embedded Trace Buffer), although not a perfect trace (it shows only branches), it can be very useful.
JLink tools support it, I don't know for OpenOCD/GDB duo.

[DiTBho]

don't expect a lot from trace. It is rarely useful in practical applications and in almost all cases there are better ways to debug the issue without involving the trace. So, I personally would focus on getting the debugger you need ignoring the trace support. If it is there - nice, otherwise - don't worry about it.

yup, that's my opinion, too, especially for hobby.

[peter-h]

What are you using tracing for as a hobbyist?

I did a google on this stuff and it resembles the old ICE (in circuit emulator) functionality which died out when CPUs got beyond a few tens of MHz.

It can be incredibly useful, especially for finding crash bugs.

I used a £10k Japanese ICE for the Z180, extensively. A brilliant tool. But that had a much bigger trace buffer than one seems to get in these CPUs.

[slugrustle]

I've used a Holtek In Circuit Emulator to develop code for an HT48R003, and I loved it.  You can see everything.

I wish ICEs were still common, but alas, they are not.