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
