Programmer for ARM M0+ MCU

[technix]

This is a v8 clone. If you step up on the prices a bit you can get a v9 clone actually. v10 clone is still a bit expensive now, more expensive than the genuine EDU Mini.

I'm not really interested in originals or clones. I prefer standard CMSIS-DAP tools.

I was just interested to see what's inside one of those, and it is basically a full copy of the real one.

In earlier days of those clones they did remove some features to save cost, then flak followed quickly. Now most of those Chinese clones are faithful and retains all features, while they even adds a few tweaks to the power delivery.

[bson]

In earlier days of those clones they did remove some features to save cost, then flak followed quickly. Now most of those Chinese clones are faithful and retains all features, while they even adds a few tweaks to the power delivery.

What features do the Seggers have that any other JTAG adapter doesn't?

[andersm]

What features do the Seggers have that any other JTAG adapter doesn't?

Out-of-the box support in most commercial IDEs is maybe the big one.

[Geoff_S]

J-links also offer unlimited software breakpoints - very helpful when you’re working with Cortex M0+’S that only offer one hardware breakpoint...

[ataradov]

J-links also offer unlimited software breakpoints - very helpful when you’re working with Cortex M0+’S that only offer one hardware breakpoint...

Interesting. Do you have any idea how they actually do it? Is it hardware independent?

Atmel Studio  also has unlimited breakpoints on all debugers, but it actually sets software breakpoint by modifying flash, so if you remove the debugger without properly stopping the session, you end up with a non-functioning firmware.

[andersm]

Do you have any idea how they actually do it? Is it hardware independent?

Atmel Studio  also has unlimited breakpoints on all debugers, but it actually sets software breakpoint by modifying flash, so if you remove the debugger without properly stopping the session, you end up with a non-functioning firmware.

Same thing. However, you need a separate license to use the feature with the base J-Link probe.

[Geoff_S]

Interesting. Do you have any idea how they actually do it? Is it hardware independent?

How ?  No idea.  I've only used it on Cortex M0+ chips and it works very well.  I know it can be used on bigger Cortex chips but not sure about others:
https://www.segger.com/products/debug-probes/j-link/technology/flash-breakpoints/

Segger makes nice kit and their software add-ons (eg "RTT" real-time trace and SystemView viewer) are invaluable.  If I was just after a SWD debugger for use as a hobbyist for self-learning, a J-Link EDU mini is cheap enough that I wouldn't think twice about buying one instead of some generic clone...

[splin]

This is one of the reasons I prefer to run the code from RAM if possible rather than FLASH when debugging - GDB supports software breakpoints in RAM but not FLASH. It also loads faster and doesn't wear the FLASH, though that shouldn't be much of a problem these days.

It does mean you need to select a device with enough RAM which obviously won't always be possible, but often I find that I tend to make heaviest use of the debugger for relatively small programs such as when trying to get to grips with a new peripheral or trying to understand example or third party code. In the case of ST's Nucleo boards there isn't even much, if any, premium for selecting a higher spec part in a product line than a more basic one.

For example, when debugging an STM32F334 ADC example using DMA ('ADC_SingleConversion_TriggerSW_DMA') , I ended up using quite a lot of breakpoints when it didn't work consistently, to cover all the error condition tests etc. The code sets up the ADC and DMA but only starts the ADC when a user input button is pressed - within an interrupt routine triggered by the switch input going low. The particular fault turned out to be due to switch bounce causing a second switch input interrupt trying to start the ADC but the LL HAL code checked to see if the ADC was already running - which it was as the first interrupt had started it.

It's obvious now, but it took me quite a while, and lots of breakponts, to get to the slaphead moment of realisation. In mitigation I suppose I was rather naively expecting the ST example code to work properly. 

You don't need as many breakpoints when the program execution is consistent allowing you to keep moving the breakpoint(s) to find the problem.

[Gibson486]

Looking at https://www.ebay.com/itm/ARM7-ARM9-ARM11-J-Link-V8-ARM-USB-JTAG-Adapter-Emulator-Programmer-Debugger/142161804998?hash=item211980fec6:g:NUkAAOSwo4pYEVjb. Undoubtedly a clone, but if its gets the job done, I'd be fine with that.

If you plan to use Atmel Studio, then you definitely will get the best experience with Atmel-ICE.

Could you elaborate on that? I get that the driver will install automatically, but is there any advantage beyond that?

I don't have an .edu email so that option wouldn't work for me.

In terms of IDEs, Atmel probably has/had the best vendor provided IDE. Everything, when used in conjunction with their programmers, just works so smoothly. Atmel, IMO, has very good documentation as well.

[Gibson486]

This is one of the reasons I prefer to run the code from RAM if possible rather than FLASH when debugging - GDB supports software breakpoints in RAM but not FLASH. It also loads faster and doesn't wear the FLASH, though that shouldn't be much of a problem these days.

It does mean you need to select a device with enough RAM which obviously won't always be possible, but often I find that I tend to make heaviest use of the debugger for relatively small programs such as when trying to get to grips with a new peripheral or trying to understand example or third party code. In the case of ST's Nucleo boards there isn't even much, if any, premium for selecting a higher spec part in a product line than a more basic one.

For example, when debugging an STM32F334 ADC example using DMA ('ADC_SingleConversion_TriggerSW_DMA') , I ended up using quite a lot of breakpoints when it didn't work consistently, to cover all the error condition tests etc. The code sets up the ADC and DMA but only starts the ADC when a user input button is pressed - within an interrupt routine triggered by the switch input going low. The particular fault turned out to be due to switch bounce causing a second switch input interrupt trying to start the ADC but the LL HAL code checked to see if the ADC was already running - which it was as the first interrupt had started it.

It's obvious now, but it took me quite a while, and lots of breakponts, to get to the slaphead moment of realisation. In mitigation I suppose I was rather naively expecting the ST example code to work properly. 

You don't need as many breakpoints when the program execution is consistent allowing you to keep moving the breakpoint(s) to find the problem.

LOL...you actually got something useful from the ST example code? I remember the example code for I2C. Now that is a laughing matter.

[technix]

This is one of the reasons I prefer to run the code from RAM if possible rather than FLASH when debugging - GDB supports software breakpoints in RAM but not FLASH. It also loads faster and doesn't wear the FLASH, though that shouldn't be much of a problem these days.

It does mean you need to select a device with enough RAM which obviously won't always be possible, but often I find that I tend to make heaviest use of the debugger for relatively small programs such as when trying to get to grips with a new peripheral or trying to understand example or third party code. In the case of ST's Nucleo boards there isn't even much, if any, premium for selecting a higher spec part in a product line than a more basic one.

For example, when debugging an STM32F334 ADC example using DMA ('ADC_SingleConversion_TriggerSW_DMA') , I ended up using quite a lot of breakpoints when it didn't work consistently, to cover all the error condition tests etc. The code sets up the ADC and DMA but only starts the ADC when a user input button is pressed - within an interrupt routine triggered by the switch input going low. The particular fault turned out to be due to switch bounce causing a second switch input interrupt trying to start the ADC but the LL HAL code checked to see if the ADC was already running - which it was as the first interrupt had started it.

It's obvious now, but it took me quite a while, and lots of breakponts, to get to the slaphead moment of realisation. In mitigation I suppose I was rather naively expecting the ST example code to work properly. 

You don't need as many breakpoints when the program execution is consistent allowing you to keep moving the breakpoint(s) to find the problem.

LOL...you actually got something useful from the ST example code? I remember the example code for I2C. Now that is a laughing matter.

ST example and library code is something I wouldn't touch with a ten foot pole. Those are more times than not a slim layer on top of the actual hardware registers with unoptimized example code. Way too often I found writing things de novo can be faster than using those libraries and burn breakpoints to figure out all the kink and quirksof their code.