Joerg,
Thank you for your reply. Most illuminating.
So, among the plethora of programmers out there, can you suggest one that will
work with Avarice to provide a proper gdb experience?
Just need something for AVR right now.
Thanks again,
Bob Wirka
________________________________
From: Joerg Wunsch <[email protected]>
To: "[email protected]" <[email protected]>
Sent: Friday, March 23, 2012 9:43 AM
Subject: Re: [AVaRICE-user] Slow debugging with Avarice and gdb
As Bob Wirka wrote:
> Single stepping, and running to a breakpoint is VERY slow with
> Avarice and gdb. AVR Studio doesn't have this problem, so it must be
> solvable.
Upgrade to AVR Studio 5.x, and it will be about as slow as GDB +
AVaRICE are. ;-)
The reason it is slow is that the JTAGICE mkII has been tailored to
work with AVR Studio 4 and nothing else. Part of the jobs usually
done by the debugger have been moved into the ICE (adding hardware
cost to the ICE, like the slave MCU and the event memory). At the
other end, low-level functionality as it's used extensively by GDB or
the Visual Studio debugger sitting below the new Atmel Studio gets
slowed down by this, and as these low-level functions make up for the
bunch of legwork done by these debuggers, they become the "critical
path" in terms of debugging speed.
Presumably, the JTAGICE mkIII uses a lean and fast design. It thus
cannot be used with AVR Studio 4's approach anymore (only with Atmel
Studio 5+), so it would very likely also make AVaRICE/GDB benefit
speedwise, except for two reasons:
. There's zero documentation publically available about its
communications protocol, and
. I don't know of anyone having the time to integrate it even if there
were documentation (which is essentially a rewrite of most of the
implementation files in AVaRICE).
> Hoping this can be fixed by proper command line invocation of
> avarice, and/or the right "set remote" commands from within gdb.
The only thing you can do is to ensure you are always working with the
highest possible JTAG clock rate. When debugging, the JTAG clock must
be less than one fourth of the CPU clock, so AVaRICE defaults to 250
kHz as most AVRs ship with a default CPU clock of 1 MHz. If you erase
the CKDIV8 fuse, your CPU speed will bump to 8 MHz, so you can run
AVaRICE with -B 2MHz for improved speed.
Other than that, try avoiding single-steps unless they are really
necessary. Jumping to explicit breakpoints (which could be temporary
ones) is much faster. GDB's single-stepping is done by asking the ICE
to low-level single step until the reported PC value matches an
instruction not belonging into the current sourcecode line range.
This causes a truckload if ICE traffic (and target round-trips between
stopped and running state), in particular for more complex sourcecode
lines.
> erase: avarice --mkII --jtag usb --jtag-bitrate 1000 --part atmega644
> --erase
> program: avarice --mkII --jtag usb --jtag-bitrate 1000 --part atmega644
> --erase --program --verify --file $1
I do not recommend this usage anymore. The entire programming
functionality is unmaintained, and might slowly fall apart over time.
I don't want to maintain two tools in parallel, and AVRDUDE offers a
much richer feature set for everything around programming AVRs.
> It **appears** to debug even if the chip is erased, and no program
> has been loaded.
Sure. Even after erasing, what do you think how much flash ROM your
ATmega644 still has? 0? 4 Bytes? Or just 64 KiB?
As it's still got a full 64 KiB of flash, the entire 64 KiB do have
some firmware in it (even though that firmware consists of opcode
0xffff only, which is interpreted as an alternative NOP).
Consequentely, if you ask your debugger, it still simply assumes the
target would execute exactly the same code that it's got in its ELF
file. If you set a breakpoint to line 42, the debugger calculates
address 0x148 for it, and tells the ICE to stop at address 0x148.
When continuing the program, your ATmega644 will execute its NOPs
until it eventually hits the breakpoint at 0x148, where it stops, and
returns control to the debugger.
--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
avarice-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/avarice-user
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
avarice-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/avarice-user
