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. Btw., when debugging an 8 KiB device (ATmega8U2), better pick another 8 KiB device for -P, like the ATmega88. > Suffice it to mention that using Atmel Studio > under Windows works flawlessly. 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. 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. -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) ------------------------------------------------------------------------------ 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
