Why is mEDBG so slow to load and run on Xplained 328pb

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

Hi All!,

 

Seems like it takes an awfully long time to flash a medium size program...

 

Am I missing a setting of one sort or another?

 

R.

This topic has a solution.
Last Edited: Thu. May 12, 2016 - 03:43 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is this over debugWire? We have seen quite a regression in programming speed for debugWire in studio 7.

Of not, then what interface, device and studio version? What is long time?

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

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

The proper EDBG runs on a fast 32-bit UC32 or ARM chip.

The mEDBG runs on a small 8-bit AVR chip.

 

The XMINI boards are definitely as cheap as they could produce them.    Quite honestly,   it would make little difference to the price if they used a UC32.   

 

The ATMEL-ICE is considerably faster than the XMINI.    Even the Dragon is faster than the XMINI.

When you consider that debugWIRE is inherently limited in speed,   I would guess that the difference in throughput is due to the poorer processing performance of the 8-bit mEDBG.

 

I believe that the SAMD10-XMINI also uses the same mEDBG.    I do not have one.   

Does that have a snail-like performance too?

 

OTOH,   think about it.   It is nice to be able to debugWIRE a 328PB chip with a single USB cable.    And pretty good value too.

 

Perhaps Morten might give an authoritive answer.

 

David.

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

All xmini boards uses the medbg (mega32u based). And yes, it is slower than edbg (uc3 based).

The price difference is actually the real point for the xmini kits, and that's why we use a mega for it.

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

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

All,

 

Sorry, I did give a paucity of detail. Yes, debug-wire,  on an 328pb, X-plain mini, and Atmel Studio 7.

 

Am I  to understand there is a speed problem in Atmel Stdio 7 specifically, vs. 6.x  that might be corrected eventually?

 

Actually, I have found Studio 7 to be a  rather impressive affair taken as a whole.

 

Randy

Last Edited: Thu. Oct 15, 2015 - 02:20 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, hopefully the debugWire bug will be resolved soon (I'm on vacation so I don't know about the schedule).

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

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

The mEDBG runs on a small 8-bit AVR chip.

Come now; a 16MHz 32u4 really shouldn't be "slow" when it comes to loading 32k of program flash.

I guess it could be doing something silly like putting one generic dbeugwire command programming one flash word inside of one CMSIS/DAP encapsulation, and sending them one per USB polling time, but that wouldn't be the fault of the 32u4 itself being slow...

 

Can one use SPI for program loading while still having debugwire used for debugging?  Or does enabling debugwire disable SPI programming?

 

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

Or does enabling debugwire disable SPI programming?

Yes. They both use the reset line with DW using just that line.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

As far as I can remember,  my 168PB-XMINI can swap between SPI and debugWIRE painlessly.

 

@westfw,

Yes,   an 8-bit chip should be able to handle the hardware interface just as well as a 32-bit EDBG.

The processing speed is going to be very different.   The ARM or UC32 are 32-bit.    An ARM has a barrel-shifter.   I suspect that the UC32 does too.

 

I suspect that it was a bit of a tight fit to squeeze the firmware into a 32kB chip.   Meaning no unrolled loops or inline functions.    Is it the same firmware in the SAMD10 mEDBG as the MEGA328PB mEDBG ?

 

The Dragon has got "massive" amounts of 8-bit MCU and memory.    And it is still pretty slow.

The JTAGICE-mkII is significantly faster.

 

I don't have a JTAGICE-3 but I understand that it is faster than the mkII.

The ATMEL-ICE is very fast.

 

If my suspicions about the "squeeze" are correct,    Atmel may well be able to carefully optimise the bottlenecks,   but I doubt if this is a priority.    It is simpler to just use a proper EDBG chip.

 

Incidentally,   I just looked at the SAMD10-XMINI User Guide.    It does not say which SAMD10 part number is mounted.     Can any owner look to see if it is a C14A or a D14A?    I guess that it is not a C13A or SAMD9.

None of the options look very well endowed.

 

David.

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

I just looked at the SAMD10-XMINI User Guide.    It does not say which SAMD10 part number is mounted.     Can any owner look to see if it is a C14A or a D14A?

 

D14A:

Detected device
Device signature  0x10020100
Revision          B

Datasheet information
                          ATSAMD10D14AM
CPU                       CORTEX-M0PLUS
Flash size                    16 KB
SRAM size                     4 KB
VCC range                      N/A
Maximum operating speed        N/A

 

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

Anyone,

 

By way of trying to correct this I just installed 7.0.634, no improvement. It feels like the 90's all over again!

 

Glacial, but functional.

 

Randy

Last Edited: Sun. Dec 6, 2015 - 10:43 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry state of affairs ...

 

Tested 7.0.790, still very, very slow with anything beyond a trivial program.

 

No change on this issue, I got a "glad hand" from AVR Tech support on being aware of the problem, but no fix in sight, unless I'm missing something perhaps?

 

In general I'm hearing from professional folks, far, far more experienced than me,  that AVR tech support is a sourced out, incompetent mess, and AVR is jeopardizing their entire top-end customer base relationships.

 

Comments?

 

R.

Last Edited: Wed. May 11, 2016 - 05:30 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So what is your problem? The mEDBG is perfectly functional. Just SLOW.
.
If you want to go faster, buy a real ATMEL-ICE and a Uno clone. The debugWIRE will work fine.
.
It seems a false economy to use the m32u4 instead of a proper UC32. It also means that you can feel smug if you own an ATMEL-ICE.
Of course, you could have bought a Nucleo board with a Cortex-M4F and debugger for about the same cost as your XMINI.
.
David.

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

tech support is a sourced out, incompetent mess,

There are talented people in support, unfortunately the whole support arrangement, (and Studio in general, shall we add the forum software for good measure??) seems to give out those kind of vibes.

 

A new version of Studio is supposedly imminent, don't know if it will fix your problem. Hope it will fix mine which has been pending for 6 months now.

 

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

(It has the "feel" of "we're intentionally letting this product remain slow, so as to encourage sales of our more expensive products"  (Microchip might be proud!))

ARM debug is documented, SWD is documented, CMSIS-DAP is documented, 32u4 "development boards" are widely available in the form of Arduino Micro or Teensy 2.  An open source high-speed mEDBG chip should be a reasonable university  or community project.  (Assuming that I'm not overlooking something that makes it impossible.)  AVR debugging would be harder, since it's less documented.

 

Edit: oops - we were talking about 328pb xmini.  For program loading (without debugging), you could put the Arduino bootloader on the chip and upload at 56700bps...  It's not the first time that someone noticed that a bootloader can work faster than a programmer...

 

Last Edited: Wed. May 11, 2016 - 08:40 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

rasyoung wrote:

Glacial, but functional.

 

Any numbers on that 'glacial' ?

Did you check on a scope for actual Baud and any gaps ?

 

Google finds this

http://www.ruemohr.org/docs/debu...

and I can see mentions of 4k ~ 500k Baud as Debug Wire range, but it is not that clear if you can go above that Clk/128 /

ie can you actually set a 16MHz AVR to run DebugWire at 500k ?

 

The link above suggests 25 bytes of dance, per Flash byte word of payload, and at 125k , that's 500 1000 bytes a second, transfer alone.

 

If it makes you feel better, I'm looking at the Intel D2000, 32 bit MCU with a High Speed USB JTAG Debug link, - now, one would think that could be quick ?

They report 40 seconds is a typical download time.... wow...

 

Last Edited: Wed. May 11, 2016 - 11:13 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The link above suggests 25 bytes of dance, per Flash byte of payload,

Huh?  There's a "write page" command...

And the complaint is that mEDBG is much slower than EDBG, which should eliminate DW as the bottleneck.

 

 

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

westfw wrote:

The link above suggests 25 bytes of dance, per Flash byte of payload,

Huh?  There's a "write page" command...

And the complaint is that mEDBG is much slower than EDBG, which should eliminate DW as the bottleneck.

 

Did you follow the link, where it reports this ?  (edit: I see that is actually a word of payload, not byte, so have crorected my post slightly)

 

Writing a Flash Page...

And then repeat the following until the page is full.

D0 1F 00 - set PC to bootsection for spm to work
D2 B6 01 23 ll - in r0,DWDR (ll)
D2 B6 11 23 hh - in r1,DWDR (hh)
D2 BF B7 23 - out SPMCSR,r27 = 01 = SPMEN
D2 95 E8 23 - spm
D2 96 32 23 - adiw Z,2

Last Edited: Wed. May 11, 2016 - 11:14 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cough.  I followed the link, but I guess I didn't read it very carefully.  The "read flash page" did a whole block at once, and I assumed the write page was essentially similar...

 

repeat the following until the page is full.

D0 1F 00 - set PC to bootsection for spm to work
D2 B6 01 23 ll - in r0,DWDR (ll)
D2 B6 11 23 hh - in r1,DWDR (hh)
D2 BF B7 23 - out SPMCSR,r27 = 01 = SPMEN
D2 95 E8 23 - spm
D2 96 32 23 - adiw Z,2

 

An Interesting way to do things, essentially executing out-of-step instructions for each piece.  It should still be pretty easy to improve on that - I don't see why the PC needs to be reset for every byte, and most chips will be able to use "SPM Z+"

I wonder why they use the "xct 'n r0,DWDR'; data" instead of "xct 'ldi t0,data'"

 

For "program chip" functions, I'd be looking at speeding things up using the "write multiple register" command, or even RAM...

The concept of executing single instructions would result in a lot of flexibility...

 

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

David, et al.

 

(Thanks to all for chiming in on this issue!)

 

Your comments are spot on. As point of fact their exactly what I did do. I got a JTAGICE3 basic, and then took a good hard look at finally updating my focus to the STM32 eco-system, which has worked out surprisingly well in a number of dimensions.

 

But the circumstance still begs the question, of why extend AVR Studio 7 to provide importing native Arduino sketches, libraries and all, and then when you develop a low-cost piece of hardware in support, that would be perfect to apply in an educational setting which is where my focus lies, not do enough user testing to see if can actually work or not? Having to wait a minute plus for the program to reload, after a simple variable update just isn't doable.

 

As this discussion gets formally more technical, there is one common sense perspective I would like to offer. When you see an 8 bit AVR, running on a 3$ USBASP, bit-banging USB 1.0, and writing the code a reasonable rate to an AVR target, it just rails me to see this dedicated native USB chip struggle to flash the target AVR.  Something is way off!

 

I did find this ...

 

  http://savannah.nongnu.org/patch...

 

The developers of AVRdude, do support the mEDBG protocol, and I would be interested in doing some WireShark peeking around to see just what was happening, if I can find out exactly how to do it.

 

And it also suggests something I am somewhat chagrin to admit. I should have tested my AVRStudio 7.0 setup, against AVRdude write times from day one. Perhaps it isn't AVR Studio causing the problem, but the mEDBG protocol  (related to EDBG but different) or a related hardware issue.  If AVRdude struggles then I've learned something new.

 

R.

 

 

 

 

 

Last Edited: Thu. May 12, 2016 - 06:39 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My experience is:

ATMEL-ICE is faster than JTAGICE-2 is faster than Dragon is faster than mEDBG.

 

I have never seen or used a JTAGICE-3.   I believe it is faster than JTAGICE-2 but slower than ATMEL-ICE.

 

If you have a lot of debug windows,  it can take a serious amount of time to read the OCD and update the windows.

debugWIRE is inherently slower than JTAG.    

 

With some incarnations of Studio,   a slow PC can mean that OCD stuff times out.    Making the whole debug session virtually unusable.

 

I am sure that your students will be doing fairly simple experiments / assignments.

If they run to breakpoints rather than single-step,   everything should go quite smoothly.    This applies to debugging in general.    Only single-step when absolutely necessary.

 

ARM hardware and evaluation tools are far better than AVR ones.

OTOH,  the AVR is a nice simple controller to work with.

 

David.

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I did pursue my line of reasoning regarding avrdude and the mEDBG protocol. It was necessary to update my avrdude install on Ubuntu 15.04 to version 6.3, when I did I got the new support for mEDBG that is baked into the 6.3 released.

 

I'm loading the approximately 23k hex file from compiling the fantastic "cli" program from here:

 

http://piconomic.co.za/, if you haven't checked this out yet, do, it is a wonderful library...

 

(Notice DWEN,  debug wire is not enabled, so the ISP mode switch is used)

 

rasyoung@vic2016:~/Desktop/cli_hex$ avrdude -p m328p -c xplainedmini -e -U flash:w:cli.hex

avrdude: usbdev_open(): WARNING: failed to set configuration 1: could not set config 1: Device or resource busy

avrdude: stk500v2_command(): command failed
avrdude: Target prepared for ISP, signed off.
avrdude: Now retrying without power-cycling the target.
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.05s

avrdude: Device signature = 0x1e950f (probably m328p)
avrdude: erasing chip
avrdude: reading input file "cli.hex"
avrdude: input file cli.hex auto detected as Intel Hex
avrdude: writing flash (23236 bytes):

Writing | ################################################## | 100% 21.57s

avrdude: 23236 bytes of flash written
avrdude: verifying flash memory against cli.hex:
avrdude: load data flash data from input file cli.hex:
avrdude: input file cli.hex auto detected as Intel Hex
avrdude: input file cli.hex contains 23236 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 21.47s

avrdude: verifying ...
avrdude: 23236 bytes of flash verified

avrdude: safemode: Fuses OK (E:FF, H:9F, L:E0)

avrdude done.  Thank you.

 

So 42 seconds, a considerable improvement over 1 minute, but not orders of magnitude change.

 

So maybe railing at AVR Studio 7, was looking under the wrong rock. In that the avrdude team was looking at the mEDBG protocol on a byte by byte basis, there simply may not be much room for optimization.

 

R.

 

Ps. Not withstanding, and a separate issue entirely, is the poor performance intentional so as not to compete with the up-scale products? I just wouldn't know about that, but if there is such an issue it would seem only fair that the "new" ATMEL, in the spirit of openness would give out the necessary info to allow the community to fix the problem. I have marked this issue solved, but to my mind, it is really more in terms of a reluctant acquiescence.

 

Last Edited: Thu. May 12, 2016 - 05:08 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

rasyoung wrote:

I'm loading the approximately 23k hex file from compiling the fantastic "cli" program from here:

 

avrdude: writing flash (23236 bytes):

Writing | ################################################## | 100% 21.57s

Reading | ################################################## | 100% 21.47s

avrdude: verifying ...
avrdude: 23236 bytes of flash verified

 

So 42 seconds, a considerable improvement over 1 minute, but not orders of magnitude change.

I'm unclear, this was using avrdude and mEDBG ?

Did you scope the line to check for any idle/gaps ?

Those speeds come in close to the 1000 bytes/second rough estimate I made above.

 

Does avrdude allow change of mEDBG speed ? 

I can find mention of hosts supporting to 500k, but less clear is if you can ask for over SysCLK/128 - hinted at in the link above ?

 

You could skip that verify, in many cases - give students two download choices, and mostly they can use pgm-only for changes.

- also, most student project will be more modest in size, giving another speed gain ?

 

With a s-l-o-w link, another approach (if AVR Dude supports it) is to avoid secure, and do page-change send only.

You then add a simple util that keeps track of last hex, and compares with new-new, and collects only changed pages.

 

A new project start would use full erase and verify, then you can use the page-change-hex approach for iterative edits.

 

A simple time-check could automate that - if last-hex is more than xx minutes older than new-hex, do a full clean.

That would make new classes start clean, but speed up edits.

 

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

ahhh the good ol' days when one had to expose EPROM windows to UV rays in order to change a bit...... wink or load code from paper tape or magnetic tape.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

My thought was to isolate, if possible, exactly where the "slowdown" was, is it in somewhere in the internals of AVR Studio 7, or the firmware resident in the mEDBG hardware on the Xplained Mini? So yes, I used avrdude 6.3 to exercise the 'Mini without Atmel Studio 7. I'll look into avrdude switches to increase "clock speed".

 

Lot's of excellent suggestions, thanks to all....

Last Edited: Fri. May 13, 2016 - 02:37 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just to note that when you use the fancy, GUI front end to programming within Studio 7 it's really just providing a firendly user interface for Atmel's own atprogram.exe that is buried deep within the AS7 installation. So an alternative to isolate the low level part form the high level is to run atprogram.exe directly just as you have been doing with avrdude.exe.

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

I couldn't leave this topic without posting this comparison. AVRDude 6.3 programming a ATMega328p via software USB, usbasp

 

rasyoung@vic2016:~/Desktop/cli_hex$ avrdude -p m328p  -B 500  -c usbasp -e -U flash:w:cli.hex

avrdude: set SCK frequency to 2000 Hz
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e950f (probably m328p)
avrdude: erasing chip
avrdude: set SCK frequency to 2000 Hz
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: reading input file "cli.hex"
avrdude: input file cli.hex auto detected as Intel Hex
avrdude: writing flash (23236 bytes):

Writing | ################################################## | 100% 4.04s

avrdude: 23236 bytes of flash written
avrdude: verifying flash memory against cli.hex:
avrdude: load data flash data from input file cli.hex:
avrdude: input file cli.hex auto detected as Intel Hex
avrdude: input file cli.hex contains 23236 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 2.84s

avrdude: verifying ...
avrdude: 23236 bytes of flash verified

avrdude: safemode: Fuses OK (E:00, H:00, L:00)
avrdude: error: usbasp_transmit: Broken pipe

avrdude done.  Thank you.

 

Very significant difference, and I think demonstrates the potential for improvement for mEDBG.

 

R.

 

Last Edited: Sat. May 14, 2016 - 04:36 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

rasyoung wrote:

I couldn't leave this topic without posting this comparison. AVRDude 6.3 programming a ATMega328p via software USB, usbasp

 

avrdude: writing flash (23236 bytes):

Writing | ################################################## | 100% 4.04s

avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 2.84s

 

Very significant difference, and I think demonstrates the potential for improvement for mEDBG.

Those numbers are more as-expected and now the flash time is showing longer than read, however you are unclear on which physical link this uses.

I think usbasp is SPI only, and yes, SPI would be quite a bit faster.

 

Looking at the UG, I find this

 

Programming the Target Using mEDBG
 Using the Embedded Debugger on the Xplained Mini board to program the ATmega328 via the SPI bus.
  1. Connect the mEDBG USB to the PC.
  2. Go to Atmel Studio: click Tools, select Device Programming, and select the connected mEDBG as Tool
   with Device = ATmega328P and Interface = ISP, click Apply. Note that if ISP programming fails it could
   be because debugWIRE is enabled. See debugging chapter on how to disable debugWIRE mode:
    “Debugging the Target Using mEDBG” on page 4.

 

and the alternative path

1.5.2 Debugging the Target Using mEDBG  Using the Embedded Debugger on the Xplained Mini board to debug the ATmega328P via debugWIRE....
4. In the Project menu select the project properties page, select the Tools tab and select mEDBG as
debugger and debugWIRE as interface
.
..
6. Atmel Studio will display an error message if the DWEN fuse in the ATmega328P is not enabled, click YES
to make Studio set the fuse using the ISP interface.
..
8. When exiting debug mode select "Disable debugWIRE and Close" in the Debug menu, this will disable the
DWEN fuse.
Important If any other cpu clk than the external clk supplied by the mEDBG is used the debugWIRE is not guaranteed to work.

 

So that seems reasonably flexible ?

- you can use SPI for faster downloads, if the debug flow at the time suits that,

OR

- you can flip to debugWire for slower downloads, but break/step  debug (and the SPI port is free)

 

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

Programming challenge: given an Atmega32u4-based system (Say, Arduino Leonardo or Arduino Micro), how fast can you program an external ATmega328p using debugwire...  :-)

 

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

Hi everyone,

 

Here's a small bit of info to add to the discussion. I measured the debugWIRE clock rate and it was 125 kHz. Using ISP programming, the clock rate is about 56 kHz. There is thus plenty of room for improvement, but I could not find a way to change the clock rate. I found the XML setting file here: c:\Program Files (x86)\Atmel\Studio\7.0\tools\mEDBG\mEDBG.xml

(Incidently the FW is also here: c:\Program Files (x86)\Atmel\Studio\7.0\tools\mEDBG\medbg_fw.zip)

 

I also tried the ATPROGRAM command-line tool:

atprogram -t medbg -i ISP -cl 1000khz -f -d atmega328p program -c -f test.hex --verify

 

The clock rate setting had no effect :(

 

Regards,

Pieter

http://piconomic.co.za

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

All,

 

Recent update: AVR Studio 7, build 1006, no change.

 

Randy

Last Edited: Tue. Mar 14, 2017 - 01:33 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Randy current version is 7.0.1417 don't know it better or worse.

 

http://www.avrfreaks.net/forum/a...

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

I passed an opinion in #21. It is still relevant.
The debugWIRE protocol is relatively slow however fast a debugger can process information.
The debugger transmits a command sequence. It has to leave open time slots for the target chip to reply.
ATMEL-ICE is faster than JTAGICE-2 is faster than Dragon is much faster than mEDBG.
.
I can only guess that the speed difference is down to the chip inside the debugger. Since mEDBG is a very tight squeeze into a 32U4, it probably uses lots of tricks to save Flash memory. e.g. common sequences moved to subroutines instead of inline code.
.
The XMINI-mega328 is an excellent prototype development platform. Ok for minor changes but irritating for serious development.
The XMINI-tiny817 works a lot faster but obviously with smaller Flash memory.
.
I would guess that the mEDBG could be optimised for speed. Most apps have only a few bottlenecks. Concentrate on the worst. You often get dramatic results. Of course, the slow speed might be intentional. To differentiate between EDBG and mEDBG.
.
David.

Last Edited: Tue. Mar 14, 2017 - 08:01 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:
Since mEDBG is a very tight squeeze into a 32U4,...

What size is mEDBG, and where do you find that information ?

 

david.prentice wrote:
... I would guess that the mEDBG could be optimised for speed. Most apps have only a few bottlenecks. Concentrate on the worst. You often get dramatic results. Of course, the slow speed might be intentional. To differentiate between EDBG and mEDBG. . David.

 

Hopefully it is not intentional, but really, there is no excuse for very slow speeds (or large code sizes) in what is really just a bridge device.

8 bit MCUs can manage UART bridge designs to 3~4MBd.

Taking a quite modest 230.4kBaud, 32k should be able to transfer at ~ 1.5 seconds, for verify, and flash page pgm may slow write times a little.

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

You can see the size of mEDBG by looking at the firmware HEX files e.g.

C:\Program Files (x86)\Atmel\Studio\7.0\tools\mEDBG\medbg_fw.zip

 

On my AS7.0 medbg.hex is 0x6FC3 bytes with a bootloader at 0x7000.   i.e. about 61 bytes spare.

 

Bear in mind that medbg provides a CDC channel as well as debugWIRE and ISP facilities all over USB.

This is pretty impressive to all fit in a 32kB chip with limited SRAM.

 

Most DEBUGGER chips run on ARM or UC32.   e.g. STM32 ST-Link runs on a 128kB STM32F103 (I think).   Freescale run on a 128kB MK20.    I forget what NXP use.

 

But it also shows that a Manufacturer can provide a DEBUGGER chip onboard their Evaluation Boards at little cost.

ARM even provide the software for Manufacturers to build their CMSIS-DAP on a regular 128kB MCU.

 

One of the features enjoyed by Atmel is that they have to do their own software for their proprietary debugWIRE, PDI, UPDI, ...

 

This is largely speculation on my part.    I suppose that the mega32U4 chip is 5V tolerant.    If Atmel were to put a proper UC32 EDBG chip on an XMINI,  it would require all sorts of electrical protection.    More expensive than the UC32 chip.

 

David.

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

mEDBG is a very tight squeeze into a 32U4

I'm not sure I understand why it should be a "tight squeeze."

 

medbg provides a CDC channel as well as debugWIRE and ISP

 Well, I guess there IS that.  Where is my SAMC-based debugger chip?

 

I do wish Microchip would open up the debug protocols and let the hackers fiddle with it...

(I don't know if people are expecting new versions of AS to speed up the AS side of things, speed up the mEDBG "settings", or include new mEDBG firmware that speeds up that side as well.   All are possible, right?)

 

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

david.prentice wrote:

This is largely speculation on my part.    I suppose that the mega32U4 chip is 5V tolerant.    If Atmel were to put a proper UC32 EDBG chip on an XMINI,  it would require all sorts of electrical protection.    More expensive than the UC32 chip.

There are always PIC24 models, that seem to have USB in QFN28, up to 128k bytes ? - unless there is a Mega64U coming real soon ?

 

I see Cypress have a MB9AF312KPMC-G-JNE2  48LQFP 160k M3 USB part, wide Vcc,  that is quite a bit cheaper ($1.62) than a mega32u($2.48), but I do not expect Microchip to use that ;)

Nuvoton have USB parts in wide Vcc, from $1,75 for 64k, QFN33

 

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

It would be very unlikely that any Manufacturer would use someone else's chip to host their debugger.
I am not familiar with PIC24. It might be faster than 32U4 but I doubt if it is faster than UC32 or SAM.
.
Anyway, it is not a good idea to change hardware after a design has already been widely sold. And you would have separate firmware versions. Think how embarassing it would be if one firmware has a bug that is different between debugger chips.
.
They could publish protocols. I would not expect them to publish their firmware source. Who is going to write their own debug firmware? AS7 is free. IAR is very expensive. Rowley have lost interest. Does ImageCraft have its own debugger?
.
David.

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

david.prentice wrote:
I am not familiar with PIC24. It might be faster than 32U4 but I doubt if it is faster than UC32 or SAM.
Faster is relative until absolute with test results.

There's a third party STK500 that can have an AVR ISP clock of up to 3MHz that uses a PIC18F25K50.

Will Microchip create an AVRISP3?

Might fill a gap below the Atmel-ICE though the third parties cover that well.

david.prentice wrote:
Does ImageCraft have its own debugger?
Software debugger for the ImageCraft CodeBlocks IDE :

ImageCraft Embedded Systems Tools

ImageCraft

JumpStart Debugger for AVR

https://imagecraft.com/index.php?option=com_opencart&Itemid=148&route=product/product&path=25&product_id=67

...

  • Seamless Interface with All modern Atmel Debug Pods: JDB-AVR works with the AVR Dragon, JTAGICE MkII, JTAGICE3, and Atmel-ICE.
     
  • Better Than AVR Studio 6.2 and Studio 7: Working call stack display; tightly coupled to the compiler, which provides the best possible source-level debugging experience.
  • ...

 


https://www.pololu.com/blog/587/new-product-pololu-usb-avr-programmer-v2

https://www.pololu.com/product/3170

Pololu Robotics and Electronics

Pololu USB AVR Programmer v2 User’s Guide

5.7. Programming faster

https://www.pololu.com/docs/0J67/5.7

(mid-page)

AVR
Clock Frequency
ISP Frequency Atmel Studio
Setting
AVRDUDE
Option(1)
20 MHz 3000 kHz(2) 1.843 MHz -B 0.5

(1): If the programmer is already configured to use the specified ISP Frequency, you do not need to supply this option to AVRDUDE, but you probably should just in case.
(2): You should select this frequency using the programmer’s configuration software, so that the programmer will use it instead of the 1.843 MHz frequency requested by Atmel Studio and AVRDUDE.

http://www.microchip.com/wwwproducts/en/PIC18F25K50

 

"Dare to be naïve." - Buckminster Fuller

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

All,

 

By way of an update, I was able to come to a satisfactory solution, not so much by brilliance but persistence.  I punted on the low-end X-plained 328p mini, and went with the Piconomix Scorpion board, and a factory ATMEL Basic-ICE JTAG adapter. On Windows 7 (Windows 10 being a nightmare, story for another day) I'm getting acceptable uploads, and faultless step debug/variable inspection with the latest and created ATMEL Studio 7, (1417).  The Piconomix libary code/cli application is quite an achievement, much to learn there.

 

So economically since I have quite a few students to support, it's a wash, lower unit price (8.99$), but less debug capability unless I provide the Basic-ICE to the lab. I willing to forgo some bells and whistles, for stability and convenience, as the AVR Studio simulator runs great this setup.

 

https://piconomix.com/

https://sourceforge.net/projects...

https://piconomix.com/product/at...

 

 

R.

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

As far as I know,  the mEDBG (ATmega328PB version) does everything that the ATMEL-ICE EDBG can do for an ATmega328PB.

 

The only difference is that the debugging comms are really slow on the mEDBG.

My XMINI-328P takes about 3 minutes to upload a full 32kB binary before a Debug session can even get started.

 

Student projects are probably only a few hundred bytes of binary.   So you will not notice the uploading time.

 

AVR hardware is very simple and easy to learn.

ARM hardware and evaluation kits are also cheap.   The debug capabilities are in a different league.

 

David.

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

Ah yes, I did finally track down that the latest and greatest Atmel Studio, is now posted on Microchip web resources.

 

    http://www.microchip.com/develop...

 

Kind of pounds home that ATMEL is now owned by Microchip.

 

 

 

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

david.prentice wrote:

...

The only difference is that the debugging comms are really slow on the mEDBG.

My XMINI-328P takes about 3 minutes to upload a full 32kB binary before a Debug session can even get started.

 

Student projects are probably only a few hundred bytes of binary.   So you will not notice the uploading time.

hehe, nice side step of the 3 minute download (?!) time issue there !

 

Has anyone compared the download times per kB on the ATtiny817 board ?

With 1617 and 3217 parts coming, that may be a better student platform than XMINI-328P ?

 

Last Edited: Tue. Jun 20, 2017 - 11:05 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I really wish Microchip would open up the DebugWire AVR debug protocols, and let "the community" fiddle with attacking the performance issues of mEDBG.  Just from some of the reverse-engineered data on the net, I have several "ideas" for potential speedups, but ... it'd be easier and more shareable if the protocols were known.

 

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

@Who-Me,

 

UPDI works very nicely.   Much faster than debugWIRE.   I posted the upload times for an XMINI-817 in an earlier thread.  

 

@westfw,

 

I doubt if Microchip/Atmel would ever publish the debugWIRE spec.    I am even more doubtful that anyone would bother to write their own debugger.    AS7 is free.     GDB works.    Rowley works (but appear to have lost interest).

 

As I said earlier.   The mega32U4 flash memory is 99.99% full.    There is no scope for unrolling or inlining code.

I do suspect that there is an "unfortunate" bottleneck that could be relieved.   After all,   a 32kB dW upload of the binary @ 115200 baud is 2.9 seconds.   With a "response window" it is still going to be under 10 seconds.    

The debug info must still be parsed from the ELF file.    This only takes a few seconds when you use the Simulator for a 32kB application.

 

So my 3 minutes experience could have plenty of room for improvement.    e.g. 180 secs -> 20 secs.

 

David.

Last Edited: Wed. Jun 21, 2017 - 02:03 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The mega32U4 flash memory is 99.99% full.

Is it dynamically re-programmed to support only the chip family that is actually being used at the time?   IIRC, Chipkit3 does that.

 

From the info that has been reverse-engineered, it looks like you get an IOREG location and the ability to stuff the instruction bus with a 16bit instruction.

So "write page" consists of a page worth stuffed instruction to read the port and do SPM sequences; some 5 instructions (each taking 4bytes sent over the DW link.)

If I wanted programming to be faster, I'd be looking at putting some sort of "bootstrap helper" in one of the "to-be-overwritten anyway" flash pages, and using DW to write a page-at-a-time to RAM instead (which is apparently "somewhat more optimized.")  It'd be a bit gross, but ... the debugger is already erasing and re-writing flash pages just to implement breakpoints...

(also, it's not clear who generates that page worth of SPM sequences; if it's the 32u4, after having been sent a full page, that's sort-of ok.  If it's back on the PC, then I/O latency is adding to the programming time as well!)

 

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

By way of another comparison, PDI protocol debugging/program loading is blistering fast on the Xmega Xplained E5's factory demo program, using an ATMEL's Basic-ICE.  I didn't want to end this thread without evaluating the upstream ATMEL tools in a similar context.  If one is able/willing to spend to get the professional tools, the performance is certainly there ...
 

Attachment(s): 

Last Edited: Sun. Jul 2, 2017 - 07:36 PM