Re: [AVaRICE-user] AVaRICE with AVRDragon and AtMEGA8u2, debugWire

[Brian <bh...@ch...>]

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