Anyone poked around the Atmel EDBG?

[technix]

So I bought an Arduino M0 Pro today. It came with an Atmel EDBG chip. And I have an Atmel ICE. So I decided to try poking around it. I don't really mind ruining it, as I can just force flash it with my Atmel ICE to restore its functionality.

Some sources claims it is just an AT32UC3A4256 with some custom marking. Let's find out.

The EDBG comes in a 7mm square package, which fits the AT32UC3A(3,4)(64,128,256) UFBGA100 package. The pinout as shown on the Arduino M0 Pro schematics match too.

The EDBG is given its own JTAG connector with AVR pinout. I did pull an IDCODE off it - 0x7202f03f. Curious as silicon revision H for the AT32UC3A4256 series have an IDCODE of 0x7202[0-26-9a-e]03f. It definitely acts as if it belongs to the series.

I am wondering if it is possible to force flash the Atmel EDBG firmware (or more extremely, Atmel ICE firmware, as it is also powered by the EDBG chip) into a freah AT32UC3A4256 chip and make it function as an EDBG or Atmel ICE device?

[ataradov]

Atmel EDBG firmware (or more extremely, Atmel ICE firmware, as it is also powered by the EDBG chip) into a freah AT32UC3A4256 chip and make it function as an EDBG or Atmel ICE device?

You would need to get that firmware first somehow. Updates are encrypted, and EDBG chips are locked.

[technix]

Atmel EDBG firmware (or more extremely, Atmel ICE firmware, as it is also powered by the EDBG chip) into a freah AT32UC3A4256 chip and make it function as an EDBG or Atmel ICE device?

You would need to get that firmware first somehow. Updates are encrypted, and EDBG chips are locked.

I think that firmware rescue mode would be useful for this, if it works.

[ataradov]

I think that firmware rescue mode would be useful for this, if it works.

What is "firmware rescue mode"? If you mean the standard bootloader function that you can access using atfw utility, then it also recovers and encrypted image.

[westfw]

Of all the things that Atmel has done, one of the most annoying is the way that they've kept their debugging protocols so proprietary...

[Mr. Scram]

Of all the things that Atmel has done, one of the most annoying is the way that they've kept their debugging protocols so proprietary...

Of course, otherwise they wouldn't be able to sell their programmers for those prices. I bought half a desk full of official Cypress and STM programmers and prototyping boards for less than the cost of one Atmel ICE and a few cables. Thanks Atmel, now Microchip.

[senso]

Get a dragon, they cost 50€ or a bit less, have one for years now, never failed me..

If you get into ARM's, just get a student J-Link for 50€ and be happy.

[ataradov]

Get a dragon, they cost 50€ or a bit less, have one for years now, never failed me..

I believe dragon is not recommended anymore. If you are going for a bare PCB anyway, then Atmel-ICE PCBA is $50 and is going to be supported for quite some time.

If you get into ARM's, just get a student J-Link for 50€ and be happy.

For ARMs there are way cheaper options. The cheapest one I know is my $10 debugger. But it is slow., being USB FS device.

LPC Link II in CMSIS-DAP mode is fast and is around $25. Plenty of other cheap options as well.

[alank2]

Of all the things that Atmel has done, one of the most annoying is the way that they've kept their debugging protocols so proprietary...

Add to this coming out with yet another new programming/debugging protocol every time they release a new chip.

[technix]

If you get into ARM's, just get a student J-Link for 50€ and be happy.

For ARMs there are way cheaper options. The cheapest one I know is my $10 debugger. But it is slow., being USB FS device.

LPC Link II in CMSIS-DAP mode is fast and is around $25. Plenty of other cheap options as well.

For generic ARM I would just go with an STM32F042F6P6 with dap42 firmware as CMSIS-DAP debug probe. It is likely the smallest and cheapest CMSIS-DAP adapter chip I can find and can hand solder.

[westfw]

But it is slow., being USB FS device.

I don't quite understand why USB FS (12Mbps, right?) should be "slow" by debugging standards.  Is CMSIS/DAP *that* "transaction inefficient"?  Maybe someone should put gdb-server on the debug probe...

[Mr. Scram]

Get a dragon, they cost 50€ or a bit less, have one for years now, never failed me..

If you get into ARM's, just get a student J-Link for 50€ and be happy.

I'd buy it mostly for AVR debugging capabilities, so the J-Link wouldn't solve all my woes. For ARM I'm now looking into PSoC, which I'm not sure is fully supported by the J-Link. Most programmers aren't that expensive and it can pay to get hardware that the manufacturer knows and expects. Atmel is somehow an expensive exception.

The Dragon seems to have a mixed reputation, with many people blowing them up. The ICE is actually a nice piece of hardware, just too expensive. It's not the actual money either, just that Atmel seems to be taking advantage of the situation.

[ataradov]

I don't quite understand why USB FS (12Mbps, right?)

It is USB HID (interrupt endpoints), so it does not need drivers on any OS. But this comes at a cost - 64 Kbytes/s max transfer rate.

[westfw]

Keep an eye out for Atmel (Microchip) training.  Frequently a "hands on training class" will be giving away slightly old hardware at really steep discounts.   For example, in NY "somewhat associated with Makerfaire" (this week?), these is:
https://www.eventbrite.com/e/microchips-get-launched-new-york-tickets-36836871073
which includes a class on "Advanced Arduino Debugging", where you'll get to take home an ATmega328p Xplained-mini (Uno equivalent with mEDBG on-board) AND a JTAGICE3 debugger (does ARM too), all for $25.

[technix]

Keep an eye out for Atmel (Microchip) training.  Frequently a "hands on training class" will be giving away slightly old hardware at really steep discounts.   For example, in NY "somewhat associated with Makerfaire" (this week?), these is:
https://www.eventbrite.com/e/microchips-get-launched-new-york-tickets-36836871073
which includes a class on "Advanced Arduino Debugging", where you'll get to take home an ATmega328p Xplained-mini (Uno equivalent with mEDBG on-board) AND a JTAGICE3 debugger (does ARM too), all for $25.

I am not in the States, and there is barely any of those hands-on training classes here in China.

[dgtl]

Is CMSIS/DAP *that* "transaction inefficient"?  Maybe someone should put gdb-server on the debug probe...

Black Magic Probe is advertized as having gdb server on board. Havent tried it out myself yet, though.
https://github.com/blacksphere/blackmagic/wiki

[funkathustra]

Get a dragon, they cost 50€ or a bit less, have one for years now, never failed me..

If you get into ARM's, just get a student J-Link for 50€ and be happy.

Agree with the J-Link suggestion. Also consider the J-Link EDU Mini, which is $20. Definitely a no-brainer for ARM developers.

Disagree with the AVR Dragon recommendation. AVR Dragon isn't being updated anymore, and it can't program or debug new AVR parts.

And if you're an Atmel loyalist, you'll want to abandon the megaAVR and switch to the new AVR parts (the tinyAVR 1-Series stuff), as they've got substantially better peripherals and clocking options than the popular megaAVRs that people use, and they're also cheaper.

Problem is, they use UPDI — a one-wire programming and debugging interface — which only the Atmel ICE supports.

I'm not going to complain about UPDI, which is way better than the horrific ISP/debugWIRE combination that megaAVRs use, but it does mean my AVR Dragon is getting retired if I ever have to work with Atmel AVR parts again (doubtful).

By the way, if you're like me and you assumed you could use an mEDBG on a board to program arbitrary parts, don't waste your time. I bought an ATtiny817 Xplained Mini, with the intent of developing code for the ATtiny1617. No dice: the mEDBG on that board is programmed specifically for the ATtiny817, and Atmel Studio refuses to use it to debug anything other than that chip.

The guys over on AVR Freaks thought I was insane to think you could use a $20 dev board to debug an external target. I thought they were insane for suggesting otherwise, as no other MCU manufacturer locks down their dev boards like that.

Atmel is insane, and their AVR parts are completely average in the soup of 8-bit, 16-bit, and 32-bit parts out there. Still, if you're forced to use them for legacy reasons or general sadomasochistic inclines, pick up an Atmel ICE.

[ataradov]

By the way, if you're like me and you assumed you could use an mEDBG on a board to program arbitrary parts, don't waste your time. I bought an ATtiny817 Xplained Mini, with the intent of developing code for the ATtiny1617. No dice: the mEDBG on that board is programmed specifically for the ATtiny817, and Atmel Studio refuses to use it to debug anything other than that chip.

I'm not sure about mEDBG specifically, but EDBG on ARM boards can be used to program other devices. AS itself recognizes the board, and limits your choice to the device installed by default, but you can disable that check in the settings.

[funkathustra]

By the way, if you're like me and you assumed you could use an mEDBG on a board to program arbitrary parts, don't waste your time. I bought an ATtiny817 Xplained Mini, with the intent of developing code for the ATtiny1617. No dice: the mEDBG on that board is programmed specifically for the ATtiny817, and Atmel Studio refuses to use it to debug anything other than that chip.

I'm not sure about mEDBG specifically, but EDBG on ARM boards can be used to program other devices. AS itself recognizes the board, and limits your choice to the device installed by default, but you can disable that check in the settings.

You're right; I should have said "debug" instead of "program" --- yes, you can override the device type in the Device Programmer pop-up in Atmel Studio, but you can't do that in the project options "Tool" section (at least on the Xplained Mini boards that I've tried thus far); thus, Atmel Studio refuses to debug the target.

[ataradov]

The check mark works in both cases for me. If I enable device checking, then programming dialog only shows one device, and a project settings window does not show a debugger as an option if the project is created for another device. If I disable this check, then I can select whatever device I like in both cases.

I have a Tiny817 Xmini board, and I created a project for Tiny816. I can select the debugger, and attempt to start debugging, but it eventually complains about invalid device ID.

So it look like it all works as expected.

[funkathustra]

I have a Tiny817 Xmini board, and I created a project for Tiny816. I can select the debugger, and attempt to start debugging, but it eventually complains about invalid device ID.

And does it actually let you debug the code?

Even if you were able to, I suspect it's because the 817 and 816 are the same die, right? Just different package? (and device ID)

Which check mark are you talking about? Can you screen-shot it, please?

All I'm saying is: when I create a project that targets an ATtiny1616, I can't use my Tiny817 board to debug it -- the Xplained Mini 817 mEDBG board doesn't even appear in the "Tool" selection drop-down. I can go to device programming and override it there, but it doesn't even appear in the Tool drop-down menu for my ATtiny1616-based projects.

[ataradov]

And does it actually let you debug the code?

I don't know, since I actually have the right chip installed on the board. But it tries, and I suspect it will work.

All I'm saying is: when I create a project that targets an ATtiny1616, I can't use my Tiny817 board to debug it -- the Xplained Mini 817 mEDBG board doesn't even appear in the "Tool" selection drop-down. I can go to device programming and override it there, but it doesn't even appear in the Tool drop-down menu for my ATtiny1616-based projects.

There must be something wrong with your studio installation. I just tried the same with a project for ATtiny1616, and I get the same exact result - tool appears in the project settings. The only thing to keep in mind is that I had to close the project settings window and open it again after disabling the device check.

It actually appears even in ARM projects (but obviously does not show any supported programming protocols). With the check disabled, AS just shows all tools it knows about.

[funkathustra]

The only thing to keep in mind is that I had to close the project settings window and open it again after disabling the device check.

Thanks for the tip! Where is the device check setting you've mentioned?

[ataradov]

Tools (Main Menu) -> Options ... -> Tools -> Hide Unsupported Device -> False.

[funkathustra]

Tools (Main Menu) -> Options ... -> Tools -> Hide Unsupported Device -> False.

Boom! Thanks so much! It totally works.

Now I don't need to buy an Atmel ICE for my review project — thanks for saving me $140!

Also, sorry for semi-hijacking this thread. My bad.