Ho Joerg,
Thanks for the great and informative (and speedy!) response! I'll toss
in a few more tidbits of what's going on in case it sheds more light:
The target device is part of a project that features some status lights
that start blinking right after power up. When programming with Atmel
Studio in Windows, all the lights go out and stay out during programming
(which makes sense; the core is busy receiving the image). However,
when programming with avrdude on Debian, the lights blink strangely, as
though the device were being reset repeatedly. It's as though the AVR
Dragon is either not holding the device in reset correctly, or is not
sending it the correct commands somehow. avrdude also likes to hang or
spit out errors a lot, and even if it makes it to 100% on a write, the
automatic verify fails, and a second verify confirms that the prevous
image is still on the chip. So for some reason, the Dragon is just
behaving differently under all circumstances on Linux. :-(
Now on to some things you said:
I'd more suspect the actual debugWIRE connection at first though.
You can try experiment with pullup resistors on /RESET. I've seen
target working more reliably with 4.7 kΩ or 10 kΩ pullups, but
I've also seen target working best without any additional component
between the ICE (i.e. your Dragon) and the /RESET line.
Also make sure to use at most the standard STK500 cable length between
the Dragon and the target (about 15 cm), as the Dragon's line drivers
are known to be quite weak.
I'd agree completely except the exact same physical setup works fine
with Atmel Studio. So yeah, the connection is a problem, but Atmel
Studio can make the Dragon work with it. There actually is a 10k pullup
on that line on my project.
Then the only way to find out is (unfortunately) to trace Atmel
Studio's actions when initializing the AVR Dragon, and compare it
to what AVaRICE does.
Indeed. Can you point me to some resources so I can learn how to do
that? Can it be done without additional equipment (e.g. a USB sniffer)?
Btw., when debugging an 8 KiB device (ATmega8U2), better pick another
8 KiB device for -P, like the ATmega88.
Very useful, thank you. I'll use that.
Hm, here's a thought out of left field: Is it possible that the Linux
USB driver is somehow not letting the Dragon draw enough power from the
USB port? Not so much that it resets itself, but perhaps enough that it
can't drive the /RESET line strongly enough? I think I remember reading
somewhere that there was some low-level USB thing about moderating how
much power the connected device is allowed to draw. When I get back to
my workbench, I'll try powering the Dragon externally and see if that
changes anything.
Thanks!
-Brian
On 05/18/2016 01:45 AM, Joerg Wunsch wrote:
As Brian wrote:
got asynchronous event: 0xf7
recv: timeout
This is an
#define EVT_ERROR_PHY_RECEIVE_TIMEOUT 0xF7
meaning the debugWIRE transport timed out (between the Dragon
and the target).
So...is this something to do with telling AVaRICE it's an atmega48 when
it's really an atmega8u2?
Very unlikely.
--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j___
avarice-user mailing list
avarice-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/avarice-user
