Programmer for ARM M0+ MCU

[anvoice]

Finally starting my foray into ARM MCU programming. I have an atsamd10d14a MCU and a breakout for it on the way, but not sure what programmer I should use for this particular model. I'm looking at several inexpensive J-link programmers right now, but none of them state that they're compatible with M0+. Then there is ATMEL-ICE that I'm guessing will work, but it's not cheap. Could anyone recommend a reasonable programmer/debugger compatible with the samd10? Thanks in advance!

[ataradov]

What specific J-Link models you are looking at that are cheaper than Atmel-ICE?

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

There is a PCBA version of the Atmel-ICE, which is just $50. But it does not come even with USB or 50mil cables, so you will have to supply that yourself.

[ataradov]

J-Link EDU, specifically prohibits commercial usage, but I don't think they will ever know and bother to send you a legal letter as an individual user.

I thought you need an actual .edu email to buy them? Or contact sales representative and provide some supporting information.

Well, it appears that you can just buy it from DigiKey for $63.

[anvoice]

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.

[ataradov]

That one works better than EDU. It's a cloned full JLink.

I don't have a lot of experience with clones. But supported devices only include CM3 for whatever reason. It is actually a full working clone?

[ataradov]

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

Somewhat smoother integration. But ultimately, it should not matter. AS supports full J-Link, I don't know about clones and EDU versions. $16 seems like it would be worth the risk.

I'll order one and we'll see what happens

[jnz]

Undoubtedly a clone, but if its gets the job done, I'd be fine with that.

That’s not a clone. It’s a counterfeit / knockoff.

There is a difference. Buying a clone hurts them if you would have bought directly, one sale damage. Supporting knockoffs hurts an entire brand.

Don’t support that.

[anvoice]

Undoubtedly a clone, but if its gets the job done, I'd be fine with that.

That’s not a clone. It’s a counterfeit / knockoff.

There is a difference. Buying a clone hurts them if you would have bought directly, one sale damage. Supporting knockoffs hurts an entire brand.

Don’t support that.

Unfortunately I don't have the $$$ for the genuine thing. If China can reverse engineer it and sell it for $, that becomes my only real option of getting work done.

Thank you for the suggestions everyone, I think I'll try the clone (counterfeit if you prefer) and see how it works out. I'll report back once I have results.

[anvoice]

I'll give an example. When working in a chemistry lab, I used a super-expensive Kapton polyimide tape developed by Dupont (btw, hurting THAT brand is the last thing I'd be concerned about) I believe. Now I use a "Koptan" tape from China for my 3d printer printing surface and have 0 problems. I think it's also reasonable that if you're selling hardware worth $10 for hundreds, and somebody comes out with a "counterfeit" for much less, there will be some takers.

[Canis Dirus Leidy]

Undoubtedly a clone, but if its gets the job done, I'd be fine with that.

Don't know about new clones, but old China-links (I have one, bought in 2011) worked until first software (and banned serial numbers list) update. Because Segger bricked you hardware long before it became FTDI.

P.S. Yes, there are methods to crack the firmware number check, but I just buy Bus Blaster.

[lgbeno]

I'm sure that both J-Link and Atmel-ICE will work.  Your other choice is to get a Xplained board with built in EDGB.  If you plan on doing electronics for a long time, do yourself a favor and buy some decent tools, you won't regret it, even if "nice" is a $20 jlink EDU https://www.adafruit.com/product/3571?gclid=CjwKCAjwypjVBRANEiwAJAxlInCFbtm9K17SCkT6fnpKnq5x-So3XUSc6Q8gpus0BdBnpcchmPnGTRoCJv4QAvD_BwE

By the way SAMD10 is a decent MCU but be careful as the bloated ASF library steals away a lot of the useable flash.  Ataradov has some great projects on how to really setup a device like this https://github.com/ataradov/dgw. For learning, using a SAMD20 or21 is going to be far less restrictive.


Sent from my iPhone using Tapatalk Pro

[technix]

If you plan to stick to Atmel Microchip, you can actually get their latest PICKit 4 for that chip. If you want to venture elsewhere, here are some options I found viable:

• Chinese cloners have already mass produced their J-Link v9 clones and a v10 clone have surfaced. I'd rather buy a v9/v10 over a v8 since those won't trigger so much warning signs in Segger-provided code, and they don't brick themselves. Chinese clones of J-Link v8 can occasionally brick themselves actually. Also v9/v10 supports more chips (Cortex-M7 requires a v9, and Cortex-M23/M33 likely will require a v10)
• They also have clones of U-Link 2. If you can grab a trial version of Keil MDK, upgrade that thing to the latest firmware and you get a highly universal CMSIS-DAP debug probe.
• Another alternative is those Chinese clones of ST-Link/v2 (actually since ST-Link is open source it is not really a clone...) If you want to work with other vendors' chips you can load a CMSIS-DAP firmware onto it.
• It depends, but you may find those USB Blaster clones work under OpenOCD if you plan to stick with open source.

[andersm]

If you plan to stick to Atmel Microchip, you can actually get their latest PICKit 4 for that chip.

I'm going to say it's a little early to get a Microchip-branded anything for ARM development.

[anvoice]

I'm sure that both J-Link and Atmel-ICE will work.  Your other choice is to get a Xplained board with built in EDGB.  If you plan on doing electronics for a long time, do yourself a favor and buy some decent tools, you won't regret it, even if "nice" is a $20 jlink EDU https://www.adafruit.com/product/3571?gclid=CjwKCAjwypjVBRANEiwAJAxlInCFbtm9K17SCkT6fnpKnq5x-So3XUSc6Q8gpus0BdBnpcchmPnGTRoCJv4QAvD_BwE

By the way SAMD10 is a decent MCU but be careful as the bloated ASF library steals away a lot of the useable flash.  Ataradov has some great projects on how to really setup a device like this https://github.com/ataradov/dgw. For learning, using a SAMD20 or21 is going to be far less restrictive.

I ordered some generic programmer for about $6, will see how that works. Unlike the one I posted about earlier, this one doesn't seem to forge the J-link logo. It works over SWD so I just need to figure out how to program via that.

I do plan on doing electronics for a long time, just don't see what the advantage of an expensive option is over the cheap no-brand ones.

My choice fell on the SAMD10 because it's actually a perfect fit for a project I was hoping to do, so I thought I'd learn MCUs and get something done at the same time.

If you plan to stick to Atmel Microchip, you can actually get their latest PICKit 4 for that chip. If you want to venture elsewhere, here are some options I found viable:

• Chinese cloners have already mass produced their J-Link v9 clones and a v10 clone have surfaced. I'd rather buy a v9/v10 over a v8 since those won't trigger so much warning signs in Segger-provided code, and they don't brick themselves. Chinese clones of J-Link v8 can occasionally brick themselves actually. Also v9/v10 supports more chips (Cortex-M7 requires a v9, and Cortex-M23/M33 likely will require a v10)
• They also have clones of U-Link 2. If you can grab a trial version of Keil MDK, upgrade that thing to the latest firmware and you get a highly universal CMSIS-DAP debug probe.
• Another alternative is those Chinese clones of ST-Link/v2 (actually since ST-Link is open source it is not really a clone...) If you want to work with other vendors' chips you can load a CMSIS-DAP firmware onto it.
• It depends, but you may find those USB Blaster clones work under OpenOCD if you plan to stick with open source.

Yep, I just have no idea what I'll be needing in the future. Right now a very simple SWD programmer seems like it'll suffice, though of course I want some growing room. Never heard of U-link before, but I'll look into it.

[ataradov]

I ordered some generic programmer for about $6, will see how that works.

Link? If it is just a CMSIS-DAP programmer, then it will not work with Atmel Studio. While Atmel-ICE is also a CMSIS-DAP programmer, it actually implements some extensions, and studio does not like when those extensions are not implemented. Tools like OpenOCD and my EDBG programmer will work fine.

[anvoice]

I ordered some generic programmer for about $6, will see how that works.

Link? If it is just a CMSIS-DAP programmer, then it will not work with Atmel Studio. While Atmel-ICE is also a CMSIS-DAP programmer, it actually implements some extensions, and studio does not like when those extensions are not implemented. Tools like OpenOCD and my EDBG programmer will work fine.

https://www.ebay.com/itm/J-link-OB-ARM-Emulator-Debugger-Programmer-Downloader-Replace-V8-SWD/222806224226?epid=24005977180&hash=item33e0492d62:m:m8KPqfYVIrusRw2DkHxxZlg
I don't mind moving away from Atmel Studio if other options exist.

[lgbeno]

Well, you're free to make your own choices but I think this forum is giving you sound advice to make sure that you learn instead of getting frustrated with sub par tools or premature optimization to save a buck.  Pennywise, dollar foolish, spend your time learning, not wondering if the clone programmer is at fault, at least thats my 2cents.  It might all work out, you just never know.  It took me awhile to learn this lesson myself.


Sent from my iPhone using Tapatalk Pro

[lgbeno]

In fact I'd rather mail you a samd21 xplained board from my personal stock to help out.


Sent from my iPhone using Tapatalk Pro

[anvoice]

Make no mistake, I appreciate everyone's input on this forum. I think it's very valuable advice.

I just try to distinguish between the situation you described and a more common one when the alternatives are just overpriced. Maybe working in a lab skewed my senses of being owned on prices.

I'll get a development board later if it looks like it's going to be useful, it's not that big a deal. I'm just rationing my resources since I'm just starting out with this.

[ataradov]

https://www.ebay.com/itm/J-link-OB-ARM-Emulator-Debugger-Programmer-Downloader-Replace-V8-SWD/222806224226?epid=24005977180&hash=item33e0492d62:m:m8KPqfYVIrusRw2DkHxxZlg
I don't mind moving away from Atmel Studio if other options exist.

This is the same thing as in that black box, but without a box.

[anvoice]

https://www.ebay.com/itm/J-link-OB-ARM-Emulator-Debugger-Programmer-Downloader-Replace-V8-SWD/222806224226?epid=24005977180&hash=item33e0492d62:m:m8KPqfYVIrusRw2DkHxxZlg
I don't mind moving away from Atmel Studio if other options exist.

This is the same thing as in that black box, but without a box.

So it should work then? Curious though, the black box has more pins than this.

[ataradov]

So it should work then? Curious though, the black box has more pins than this.

Well, it is a knock-off, so depends and who knows.

Black  box has a standard 20-pin ARM JTAG connector. Half the pins there are ground. And this one does not support JTAG at all, only SWD.

[ataradov]

Ok, I've got that $16 one. And it does appear to work with AS after the firmware update to the latest offered version. Nothing got bricked, at least for now.

The board is quite decently made by "Seggen"

But given how many legitimate tools there are that are quite cheap, I'm not sure if it is worth it.

[technix]

Ok, I've got that $16 one. And it does appear to work with AS after the firmware update to the latest offered version. Nothing got bricked, at least for now.

The board is quite decently made by "Seggen"

But given how many legitimate tools there are that are quite cheap, I'm not sure if it is worth it.

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.

[ataradov]

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.

[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.