mEDBG tool not appearing in ATTiny1616 project

Go To Last Post
13 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have an ATTiny817 Xplained Mini board (which has an mEDBG built-in) connected to an external ATTiny1616 (with the zero-ohm resistor removed to bypass the on-board 817).

 

While the target appears and programs properly in the Device Programming window (so long as I key in "ATTiny1616" in the "Device" field...), it does not appear in the "Tool" section of my ATTiny1616-targetted project.

 

It does appear in the Tool section of projects that target the ATTiny817.

 

How do I get this tool to appear in Atmel Studio?

 

I purchased the ATTiny817 Xplained Mini board specifically because it advertises that it has an mEDBG debugger built-in, and Atmel Studio reports that the ATTiny1616 supports mEDBG debuggers:

 

I would have purchased an Xplained Mini ATTiny1616 board, but they don't appear to exist.

Last Edited: Sun. Sep 10, 2017 - 03:45 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry to be OT, but how do you configure a dark background on Atmel Studio?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why would anyone want a dark background in Studio?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@jaycarlson:

If I recall correctly, the mEDBG on Xplained boards are "locked down" to only handle the AVR model on the specific board. I.e. (and if I'm correct) you can only debug ATtiny817 AVRs with that board.

 

Like it or not, but my recollection kind-of makes sense. If any Xplained board with an mEDBG could debug every AVR then there would be a much smaller actual market for the Atmel-ICE.

 

(So, how come it can program your tiny1616? Maybe Atmel missed something, or maybe they didn't care..)

 

I had a look though the 817 Xplained users guide, but could see no proof of my hypothesis/recollection.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Last Edited: Sun. Sep 10, 2017 - 10:47 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@El Tangas: Tools menu, Options. In the tree control in the Options dialogue: Environment, General. In the right pane, select a Color theme.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, some people find dark backgrounds less tiring on the eyes and I'm one of them. It's just personal preference.

 

Now, back to the OP problem, when I look into the file medbg_fw.zip inside my Atmel\Studio\7.0\tools\mEDBG folder, it has 4 versions of firmware inside, they seem specialized for each protocol, but not for each chip. So I don't know how Studio "locks" them. However, it would be interesting to flash a Mega32U4 with this firmware and see what happens.

 

The file "Atmel.ATtiny_DFP.pdsc" (look for it in the installation folder of AS7) contains the information that appears in the "Device" tab, but it's not really useful either. The locking mechanism must be somewhere else.

 

edit: Tnx Johan

Last Edited: Sun. Sep 10, 2017 - 11:08 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here's som (of many) hypotheses: Remember that Studio can recognize a board model, i.e. every Xplained board has some board model ID on it. With that the lock-down would be doable. Or it could actually be that the mEDBGs are is some way customized for the board they are on.

 

My recollection of this lock-down is from something I read several years ago when the first Xplained boards came out. (Or I could have mixed things up with some Luminary Micro I was testing then..)

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The tiny817 xplained manual says

3.1. Mini Embedded Debugger
The ATtiny817 Xplained Mini contains the Atmel Mini Embedded Debugger (mEDBG) for on-board
programming and debugging. The mEDBG is a composite USB device of two interfaces; a debugger and
a Virtual COM Port.
Together with Atmel Studio, the mEDBG debugger interface can program and debug the ATtiny817. 

There's nothing there to suggest the medbg can be used for anything but the 817 on the board. Most xplained boards are like this. If you want an medbg that can program/debug any AVR you need an Atmel-ICE. Otherwise why would anyone ever pay for an ICE? 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

If you want an medbg that can program/debug any AVR you need an Atmel-ICE.

 

"mEDBG" isn't a protocol; it's a type of embedded debugger found on dev boards. Atmel-ICE does not have support of "mEDBG" — it does have support for UPDI. If mEDBG debuggers are target-specific, why on earth would Atmel Studio list that the ATTiny1616 supports "mEDBG" debuggers if Atmel doesn't make an ATTiny1616-specific mEDBG-enabled dev board? It's misleading.

 

clawson wrote:

Otherwise why would anyone ever pay for an ICE? 

While this may seem obvious to you, it is unheard of outside of the Atmel ecosystem. Most semiconductor manufacturers have realized the ridiculousness of trying to make money off tools — basically every MCU out there is available on a sub-$30 dev board, and that dev board can almost universally be used for debugging arbitrary targets in the CPU's family. In fact, I'd say the majority of dev boards from Silicon Labs, TI, Microchip, ST, and NXP are actually designed from the ground up to easily debug external targets. Why would a manufacturer want to make it more difficult to use their part in a design?

 

The big difference I see is that most manufacturer's embedded debuggers are USB Full Speed, instead of USB High Speed, which the stand-alone third-party debuggers (think SEGGER J-Link or Microchip ICD) use.

 

I don't have an Atmel ICE; I only an AVR Dragon, which was the debugger recommended to me by an Atmel rep a year or so ago. Yet, it seems like Atmel's MCUs use a new debug protocol every time I look at the ecosystem, and the AVR Dragon is unable to debug (or even program) the new chips.

 

I am so, so sick of getting burned by Atmel tools, especially given how average these AVR parts are when compared to everything else out there these days.

Last Edited: Sun. Sep 10, 2017 - 04:27 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The pricing policy is Microchip's. They doubled the cost of ATMEL-ICE almost as the first action when they took over Atmel. 

 

And the electronics inside an Atmel-ICE is basically the same as on xplained just with less limited firmware. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

By the way, @ataradov over on the EEVBlog forums mentioned that you can totally use an mEDBG with different targets — just go to Tools (Main Menu) -> Options ... -> Tools -> Hide Unsupported Device -> False

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

I used an Attiny 416 Xplained-nano.

After desoldering the 4 resistors as indicated in the documentation I cutted the board and soldered a 2x3 pinhead.

See pictures attached.

My first attemp to read a board equiped with an Attiny 1616 was unsuccessful :Atmel Studio told that the target was not an Attiny 416 and nothing was possible.

 

Then I modified the  Tools (Main Menu) -> Options ... -> Tools -> Hide Unsupported Device -> False

 

and now it's OK! it works well!

I can read, program, modify the fuses...

 

Now I can use this programmer for quick and light projects and keep safe my Atmel-ICE.

Great !

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The mEDBG debugger has been known to program/debug many different devices for a while now.

A freaks member figured out that the mEDBG firmware is not encrypted, and is configured through bytes in the EEPROM of the ATmega32U4:

https://www.avrfreaks.net/commen...

The comment above shows the memory map of the EEPROM.

There are several firmware images for the mEDBG (for different interfaces like UPDI, SPI/ISP and dW, and TPI:
https://www.avrfreaks.net/commen...

 

Unfortunately the "simple" way to modify the ATmega32U4 EEPROM content is through an Atmel-ICE, which is a bit cumbersome to connect to the test-points on the bottom side of the board.

Note that you dont want to completely erase the mEDBG through an Atmel-ICE without backing up its content first, you dont want to lose the bootloader.

 

JohanEkdahl wrote:

My recollection of this lock-down is from something I read several years ago when the first Xplained boards came out. (Or I could have mixed things up with some Luminary Micro I was testing then..)

 

The EDBGs and mEDBG are not locked down per say, but they send a device name to Atmel Studio to conveniently pre-select the correct the device for the user. If you take any Xplained Pro board or Xplained Mini board and use atfw.exe or set "Hide Unsupported Devices" to false you should be able to use it as you please (obviously limited by the signals that are easily available on the board, and that you disconnect the target microcontroller on the board from the programming/debug signals).