avarice-user — AVaRICE Users

Re: [AVaRICE-user] Remote communication error

[Joerg W. <j...@ur...>]

As István Rétallér wrote:

> avarice -2 -j usb -P attiny45 -w --erase --program --file gdbinit-myfile
> localhost:4242 &

You are trying to program the file "gdbinit-myfile" into
your AVR.  Don't do this. ;-)

Just drop the --erase and --program options from the AVaRICE
commandline, forever.  They are deprecated.

You have already programmed your AVR through AVRDUDE.  That ought
to suffice to start with.

Then, you try programming it from the AVaRICE commandline.  Don't
do that at all.

Finally, your GDB init script also tries to program it, through the
"load" command.  That is *supposed* to work, but I wouldn't bet my hat
on that.  Just remove the "load" line from the script by now, and see
whether that gets you any further.

Quite possible there are still bugs in the constellation where
debugWIRE is used together with a GDB load command.  Its overall
performance is worse than AVRDUDE's initial ISP anyway, albeit a
working "load" command, of course, would offer a way to reprogram
without leaving the debug session, and switching back to ISP.
-- 
cheers, Joerg               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/
Never trust an operating system you don't have sources for. ;-)

[AVaRICE-user] Remote communication error

[István R. <ist...@gm...>]

Sorry for being so newbie, but still have some trouble.

I set succesfully the debugwire fuse
avrdude -F -c jtag2isp -P usb -B 10 -b 115200 -p t45 -e -U 
flash:w:myfile.hex -U lfuse:w:0xe2:m -U hfuse:w:0x9f:m -U efuse:w:0xff:m

... then start avarice
avarice -2 -j usb -P attiny45 -w --erase --program --file gdbinit-myfile 
localhost:4242 &

... then start avr-gdb
avr-gdb -x gdbinit-myfile

... and it becomes to operate, but exits with an error message:
...
...
Connection opened by host 127.0.0.1, port 58268.
0x00000000 in __vectors ()
Loading section .text, size 0x230 lma 0x0
jtagWrite(): numByte does not match page size
gdbinit-myfile:3: Error in sourced command file:
Remote communication error.  Target disconnected.

The content of gdbinit-myfile is:
file myfile.out
target remote localhost:4242
load
break main
continue

What do I still do wrong?

Re: [AVaRICE-user] JTAG device ID: 0xFFFF

[Joerg W. <j...@ur...>]

As István Rétallér wrote:

> The device is an empty Attiny45.

...which has no JTAG interface at all.

What's your intention?  Just programming through SPI?  Go and use
AVRDUDE (option -c jtag2isp).  The programming feature from AVaRICE's
commandline is deprecated anyway.
-- 
cheers, Joerg               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/
Never trust an operating system you don't have sources for. ;-)

[AVaRICE-user] JTAG device ID: 0xFFFF

[István R. <ist...@gm...>]

Hi all,
on Ubuntu 14.10 with JTAG ICE mkII 
<http://www.imexbb.com/Images/10669380/avr-jtag-ice-mkii.jpg> I get the 
message:

/avarice -2 -j usb --erase --program --file myfile.hex :4242//
//AVaRICE version 2.11, Jan 17 2014 02:51:59//
//
//Defaulting JTAG bitrate to 250 kHz.//
//
//JTAG config starting.//
//Found a device: JTAGICEmkII//
//Serial number:  00:b0:00:00:24:cf//
//Reported JTAG device ID: 0xFFFF//
//No configuration available for device ID: ffff/

The device is an empty Attiny45. Several chips were checked with the 
same result. Any idea please?
-- 

[AVaRICE-user] Support for Atmel Ice debugger

[Sebastián Z. <se...@za...>]

Hi,
is there plans to support the Atmel Ice debugger
<http://www.atmel.com/tools/ATATMEL-ICE.aspx>?

I read a recent thread in the list that says it is possible (
http://sourceforge.net/p/avarice/mailman/message/32112127/)

Regards
Sebastián

Re: [AVaRICE-user] debugWire : debug slow...

[Rémi P. <mr....@la...>]

I've installed trunk version thanks to this packet :
https://aur.archlinux.org/packages/avarice-svn
=>break is very quick! but stepping (s in gdb) takes ~2s

About flashing over debugWire (solution to poweroff / on problem), it 
isn't very reliable compared to ISP. I get lot of mismatch error using 
avrdude. Using avarice seems deprecated.
What is avarice command you used in order to flash using debugWire?

Little by little debugging becomes possible thanks to your help... Many 
thanks.

Le 09/12/2014 16:15, Armin Otterstätter a écrit :
> Okay then I would recommend you to build avarice from source. 
> Althought the package you installed states version 2.13 which 
> apparently is the most recent one, a lot has changed on trunk in the 
> meantime (Maybe a new release should be issued?).
> Anyways for me building from source fixed that problem.
>
> 2014-12-09 15:37 GMT+01:00 Rémi Pincent <mr....@la... 
> <mailto:mr....@la...>>:
>
>     "You should be using dragon_dw otherwise it will temporarily
>     activate ISP and then debugwire is only possible after
>     power-cycle. So this solves that problem."
>     :-) 1 problem solved. Now power off/on no more needed before
>     launching avarice!
>
>     I've attached wireshark logs :
>     you will find until frame 24 a break
>     and then from 25 to 132 is a step.
>
>     I'm using this avarice package :
>     https://aur.archlinux.org/packages/avarice/ with
>     https://aur.archlinux.org/packages/av/avarice/PKGBUILD
>     libusb used is 1.0.19-1
>
>
>     Le 09/12/2014 15:14, Armin Otterstätter a écrit :
>>     You should be using dragon_dw otherwise it will temporarily
>>     activate ISP and then debugwire is only possible after
>>     power-cycle. So this solves that problem.
>>
>>     About the USB delay. This is about the same time as I measured.
>>     And this relates to some USB-timeout. Is your avarice compiled
>>     with libusb 2.0 ? Could you post the Wireshark log?
>>
>>     2014-12-09 15:00 GMT+01:00 Rémi Pincent <mr....@la...
>>     <mailto:mr....@la...>>:
>>
>>         I've monitored usb using wireshark : break takes 1s, step
>>         takes 3s. Duration between 2 USB packets is at max 0.5s.
>>
>>         I'm glad to hear someone debugging at lightspeed with avarice
>>         + gdb. I hope I will manage to have such a setup.
>>
>>         I'm using avrdude for programming :
>>         *    avrdude -pm328p -c dragon_isp -Pusb -v -U
>>         flash:w:arduino_avr_template_avr_plugin.hex:i*
>>
>>         debugWire fuse is set, so when I flash I have following logs :
>>
>>         *    avrdude: jtagmkII_setparm(): bad response to set
>>         parameter command: RSP_FAILED
>>             avrdude: jtagmkII_getsync(): ISP activation failed,
>>         trying debugWire
>>             avrdude: Target prepared for ISP, signed off.*
>>
>>         ... then program is flashed. As I understand, ISB programming
>>         is used with debugWire fuse enabled.
>>
>>         Even if I wait during some seconds avarice won't run
>>         successfully, I have these logs :
>>         *AVaRICE version 2.13, Sep 19 2014 09:15:10*
>>
>>         *    JTAG config starting.**
>>         **    Found a device: AVRDRAGON**
>>         **    Serial number: 00:a2:00:04:72:83**
>>         **    set paramater command failed: DEBUGWIRE SYNC FAILED**
>>         **    Failed to activate debugWIRE debugging protocol**
>>         **    USB bulk read error: Input/output error**
>>         **    USB daemon died
>>
>>         *
>>         If I power off/power on MCU then avarice launches successfully.
>>
>>         Now I will test avarice programming.
>>
>>         Le 09/12/2014 13:13, Armin Otterstätter a écrit :
>>>         breaking/stepping is instantly on my setup. At least so fast
>>>         that it just noteable to me.
>>>
>>>         Regarding the ISP issue are you using avarice or avrdude for
>>>         programming? If avrdude, are you then using dragon with ISP
>>>         or debugwire?
>>>
>>>         For me programming with avarice is working just fine. But
>>>         when I use avrdude (which by itself also works just fine) I
>>>         have to add some delay before invoking avarice otherwise
>>>         avarice cannot open the USB. Because of that its
>>>         (unfortunately) impossible to run avrdude as a shell command
>>>         through .gdbinit.
>>>
>>>
>>>         2014-12-09 11:34 GMT+01:00 Rémi Pincent
>>>         <mr....@la... <mailto:mr....@la...>>:
>>>
>>>             Yes I'm on an Arch distribution.
>>>             Thanks for wireshark tip. I will check USB connection.
>>>
>>>             How long is breaking/stepping with your setup?
>>>
>>>             In fact, flash ends successfully through ISP in
>>>             debugWire mode. But after, if I want to launch a debug
>>>             session I must unplug MCU. Reset line is just pulled up.
>>>             This problem is also descriped on this topic :
>>>             http://awtfy.com/2012/03/29/hardware-debugging-the-arduino-using-eclipse-and-the-avr-dragon/
>>>             "If you get an error, check that you’re using libusb.
>>>             Also in most cases just cycling the power on both the
>>>             Dragon and the Arduino puts it back to working. If you
>>>             give avarice a -v flag for verbose it will constantly
>>>             spit shit out for you to read and not be interested in
>>>             as you debug. "
>>>
>>>             Lah.
>>>
>>>             Le 09/12/2014 10:27, Armin Otterstätter a écrit :
>>>>             I assume you're on Linux?
>>>>             I did the Tracing with Wireshark
>>>>             (http://wiki.wireshark.org/CaptureSetup/USB). There you
>>>>             can set the time-display to "relative to previous
>>>>             captured packet" (or similar) and then you can quickly
>>>>             see where the USB is hanging.
>>>>
>>>>             Hmm the DEBUGWIRE SYNC FAILD doesn't sound too good.
>>>>             When I'm downloading I don't have to unplug. Maybe
>>>>             there is some problem with the DebugWire communication
>>>>             alltogether. Do you have anything connected to Reset
>>>>             apart from the AVR Dragon?
>>>>
>>>>             Cheers,
>>>>             Armin
>>>>
>>>>             PS.: sorry missed the reply-all in the first
>>>>             response... so now back to the mailinglist...
>>>>
>>>>             2014-12-09 10:14 GMT+01:00 Rémi Pincent
>>>>             <mr....@la... <mailto:mr....@la...>>:
>>>>
>>>>                 Hi Armin,
>>>>
>>>>                 I'm using AVaRICE version 2.13, Sep 19 2014 09:15:10.
>>>>                 According to sf status "AVaRICE 2.12 is the latest
>>>>                 release."!
>>>>                 What is your version?
>>>>
>>>>                 How did you trace these USB issues?
>>>>
>>>>                 Another question, after flashing code using
>>>>                 debugger, I have to unplug/plug debugger and MCU 
>>>>                 otherwise when I launch avarice I have "set
>>>>                 paramater command failed: DEBUGWIRE SYNC FAILED",
>>>>                 have you some tips in order to solve this issue?
>>>>
>>>>                 Cheers
>>>>                 Lah
>>>>
>>>>                 Le 09/12/2014 10:08, Armin Otterstätter a écrit :
>>>>>                 Which Version of avarice are you using?
>>>>>                 I had similar problems when using the avarice that
>>>>>                 came with an apt-get install on a recent ubuntu
>>>>>                 (Version 2.11). I traced it down to some USB
>>>>>                 timeout issue. But the problem is resolved in
>>>>>                 trunk. Just get the most recent version from
>>>>>                 sf.net <http://sf.net>.
>>>>>                 If you're on the trunk already then it'll probably
>>>>>                 be something different...
>>>>>
>>>>>                 Cheers,
>>>>>                 Armin
>>>>>
>>>>>                 2014-12-09 9:54 GMT+01:00 Rémi Pincent
>>>>>                 <mr....@la...
>>>>>                 <mailto:mr....@la...>>:
>>>>>
>>>>>                     Hi all,
>>>>>
>>>>>                     I'm debugging ATmega328p with avarice +
>>>>>                     avr-gdb + avrdragon using debugWire.
>>>>>                     My binary is compiled with following options :
>>>>>                     -g2 -gstabs -O0
>>>>>                     -ffunction-sections -fdata-sections -std=gnu99
>>>>>                     All is right... But debugging is very slow,
>>>>>                     stepping is awfully slow
>>>>>                     (~5s), and breaking is also quite slow (~2s).
>>>>>                     Moreover if have often to reflash code, it
>>>>>                     seems flash get corrupted
>>>>>                     when debug sessions does not finish cleanly.
>>>>>
>>>>>                     I've written topic about this issue here
>>>>>                     http://www.avrfreaks.net/forum/avrdragon-debugwire-atmega328p-nice-unusable
>>>>>                     But for now, I haven't found any people
>>>>>                     working with a usable debugging
>>>>>                     environment with debugWire and avr-gdb...
>>>>>                     Suggestions are about changing
>>>>>                     toolchain and debugging tools in order to use
>>>>>                     some proprietary solutions...
>>>>>
>>>>>                     Have you got some suggestions in order to
>>>>>                     debug efficiently?
>>>>>
>>>>>                     Regards.
>>>>>
>>>>>
>>>>>
>>>>>                     ------------------------------------------------------------------------------
>>>>>                     Download BIRT iHub F-Type - The Free
>>>>>                     Enterprise-Grade BIRT Server
>>>>>                     from Actuate! Instantly Supercharge Your
>>>>>                     Business Reports and Dashboards
>>>>>                     with Interactivity, Sharing, Native Excel
>>>>>                     Exports, App Integration & more
>>>>>                     Get technology previously reserved for
>>>>>                     billion-dollar corporations, FREE
>>>>>                     http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>>>>>                     _______________________________________________
>>>>>                     avarice-user mailing list
>>>>>                     ava...@li...
>>>>>                     <mailto:ava...@li...>
>>>>>                     https://lists.sourceforge.net/lists/listinfo/avarice-user
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>

Re: [AVaRICE-user] debugWire : debug slow...

[Armin O. <arm...@gm...>]

Okay then I would recommend you to build avarice from source. Althought the
package you installed states version 2.13 which apparently is the most
recent one, a lot has changed on trunk in the meantime (Maybe a new release
should be issued?).
Anyways for me building from source fixed that problem.

2014-12-09 15:37 GMT+01:00 Rémi Pincent <mr....@la...>:

>  "You should be using dragon_dw otherwise it will temporarily activate ISP
> and then debugwire is only possible after power-cycle. So this solves that
> problem."
> :-) 1 problem solved. Now power off/on no more needed before launching
> avarice!
>
> I've attached wireshark logs :
> you will find until frame 24 a break
> and then from 25 to 132 is a step.
>
> I'm using this avarice package :
> https://aur.archlinux.org/packages/avarice/ with
> https://aur.archlinux.org/packages/av/avarice/PKGBUILD
> libusb used is 1.0.19-1
>
>
> Le 09/12/2014 15:14, Armin Otterstätter a écrit :
>
>  You should be using dragon_dw otherwise it will temporarily activate ISP
> and then debugwire is only possible after power-cycle. So this solves that
> problem.
>
>  About the USB delay. This is about the same time as I measured. And this
> relates to some USB-timeout. Is your avarice compiled with libusb 2.0 ?
> Could you post the Wireshark log?
>
> 2014-12-09 15:00 GMT+01:00 Rémi Pincent <mr....@la...>:
>
>>  I've monitored usb using wireshark : break takes 1s, step takes 3s.
>> Duration between 2 USB packets is at max 0.5s.
>>
>> I'm glad to hear someone debugging at lightspeed with avarice + gdb. I
>> hope I will manage to have such a setup.
>>
>> I'm using avrdude for programming :
>> *    avrdude -pm328p -c dragon_isp -Pusb -v -U
>> flash:w:arduino_avr_template_avr_plugin.hex:i*
>>
>> debugWire fuse is set, so when I flash I have following logs :
>>
>>
>>
>> *    avrdude: jtagmkII_setparm(): bad response to set parameter command:
>> RSP_FAILED     avrdude: jtagmkII_getsync(): ISP activation failed, trying
>> debugWire     avrdude: Target prepared for ISP, signed off.*
>>
>> ... then program is flashed. As I understand, ISB programming is used
>> with debugWire fuse enabled.
>>
>> Even if I wait during some seconds avarice won't run successfully, I have
>> these logs :
>>         *AVaRICE version 2.13, Sep 19 2014 09:15:10*
>>
>> *    JTAG config starting.*
>> *    Found a device: AVRDRAGON*
>> *    Serial number:  00:a2:00:04:72:83*
>> *    set paramater command failed: DEBUGWIRE SYNC FAILED*
>> *    Failed to activate debugWIRE debugging protocol*
>> *    USB bulk read error: Input/output error*
>>
>>
>> *    USB daemon died *
>> If I power off/power on MCU then avarice launches successfully.
>>
>> Now I will test avarice programming.
>>
>> Le 09/12/2014 13:13, Armin Otterstätter a écrit :
>>
>>  breaking/stepping is instantly on my setup. At least so fast that it
>> just noteable to me.
>>
>>  Regarding the ISP issue are you using avarice or avrdude for
>> programming? If avrdude, are you then using dragon with ISP or debugwire?
>>
>>  For me programming with avarice is working just fine. But when I use
>> avrdude (which by itself also works just fine) I have to add some delay
>> before invoking avarice otherwise avarice cannot open the USB. Because of
>> that its (unfortunately) impossible to run avrdude as a shell command
>> through .gdbinit.
>>
>>
>> 2014-12-09 11:34 GMT+01:00 Rémi Pincent <mr....@la...>:
>>
>>>  Yes I'm on an Arch distribution.
>>> Thanks for wireshark tip. I will check USB connection.
>>>
>>> How long is breaking/stepping with your setup?
>>>
>>> In fact, flash ends successfully through ISP in debugWire mode. But
>>> after, if I want to launch a debug session I must unplug MCU. Reset line is
>>> just pulled up.
>>> This problem is also descriped on this topic :
>>>
>>> http://awtfy.com/2012/03/29/hardware-debugging-the-arduino-using-eclipse-and-the-avr-dragon/
>>> "If you get an error, check that you’re using libusb. Also in most cases
>>> just cycling the power on both the Dragon and the Arduino puts it back to
>>> working. If you give avarice a -v flag for verbose it will constantly spit
>>> shit out for you to read and not be interested in as you debug. "
>>>
>>> Lah.
>>>
>>> Le 09/12/2014 10:27, Armin Otterstätter a écrit :
>>>
>>>   I assume you're on Linux?
>>>  I did the Tracing with Wireshark (
>>> http://wiki.wireshark.org/CaptureSetup/USB). There you can set the
>>> time-display to "relative to previous captured packet" (or similar) and
>>> then you can quickly see where the USB is hanging.
>>>
>>>  Hmm the DEBUGWIRE SYNC FAILD doesn't sound too good. When I'm
>>> downloading I don't have to unplug. Maybe there is some problem with the
>>> DebugWire communication alltogether. Do you have anything connected to
>>> Reset apart from the AVR Dragon?
>>>
>>>  Cheers,
>>> Armin
>>>
>>> PS.: sorry missed the reply-all in the first response... so now back to
>>> the mailinglist...
>>>
>>> 2014-12-09 10:14 GMT+01:00 Rémi Pincent <mr....@la...>:
>>>
>>>>  Hi Armin,
>>>>
>>>> I'm using AVaRICE version 2.13, Sep 19 2014 09:15:10.
>>>> According to sf status "AVaRICE 2.12 is the latest release."!
>>>> What is your version?
>>>>
>>>> How did you trace these USB issues?
>>>>
>>>> Another question, after flashing code using debugger, I have to
>>>> unplug/plug debugger and MCU  otherwise when I launch avarice I have "set
>>>> paramater command failed: DEBUGWIRE SYNC FAILED", have you some tips in
>>>> order to solve this issue?
>>>>
>>>> Cheers
>>>> Lah
>>>>
>>>> Le 09/12/2014 10:08, Armin Otterstätter a écrit :
>>>>
>>>>  Which Version of avarice are you using?
>>>> I had similar problems when using the avarice that came with an apt-get
>>>> install on a recent ubuntu (Version 2.11). I traced it down to some USB
>>>> timeout issue. But the problem is resolved in trunk. Just get the most
>>>> recent version from sf.net.
>>>>  If you're on the trunk already then it'll probably be something
>>>> different...
>>>>
>>>>  Cheers,
>>>> Armin
>>>>
>>>> 2014-12-09 9:54 GMT+01:00 Rémi Pincent <mr....@la...>:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I'm debugging ATmega328p with avarice + avr-gdb + avrdragon using
>>>>> debugWire.
>>>>> My binary is compiled with following options : -g2 -gstabs -O0
>>>>> -ffunction-sections -fdata-sections -std=gnu99
>>>>> All is right... But debugging is very slow, stepping is awfully slow
>>>>> (~5s), and breaking is also quite slow (~2s).
>>>>> Moreover if have often to reflash code, it seems flash get corrupted
>>>>> when debug sessions does not finish cleanly.
>>>>>
>>>>> I've written topic about this issue here
>>>>>
>>>>> http://www.avrfreaks.net/forum/avrdragon-debugwire-atmega328p-nice-unusable
>>>>> But for now, I haven't found any people working with a usable debugging
>>>>> environment with debugWire and avr-gdb... Suggestions are about
>>>>> changing
>>>>> toolchain and debugging tools in order to use some proprietary
>>>>> solutions...
>>>>>
>>>>> Have you got some suggestions in order to debug efficiently?
>>>>>
>>>>> Regards.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>>>>> from Actuate! Instantly Supercharge Your Business Reports and
>>>>> Dashboards
>>>>> with Interactivity, Sharing, Native Excel Exports, App Integration &
>>>>> more
>>>>> Get technology previously reserved for billion-dollar corporations,
>>>>> FREE
>>>>>
>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>>>>> _______________________________________________
>>>>> avarice-user mailing list
>>>>> ava...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/avarice-user
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>

Re: [AVaRICE-user] debugWire : debug slow...

[Rémi P. <mr....@la...>]

"You should be using dragon_dw otherwise it will temporarily activate 
ISP and then debugwire is only possible after power-cycle. So this 
solves that problem."
:-) 1 problem solved. Now power off/on no more needed before launching 
avarice!

I've attached wireshark logs :
you will find until frame 24 a break
and then from 25 to 132 is a step.

I'm using this avarice package :
https://aur.archlinux.org/packages/avarice/ with 
https://aur.archlinux.org/packages/av/avarice/PKGBUILD
libusb used is 1.0.19-1


Le 09/12/2014 15:14, Armin Otterstätter a écrit :
> You should be using dragon_dw otherwise it will temporarily activate 
> ISP and then debugwire is only possible after power-cycle. So this 
> solves that problem.
>
> About the USB delay. This is about the same time as I measured. And 
> this relates to some USB-timeout. Is your avarice compiled with libusb 
> 2.0 ? Could you post the Wireshark log?
>
> 2014-12-09 15:00 GMT+01:00 Rémi Pincent <mr....@la... 
> <mailto:mr....@la...>>:
>
>     I've monitored usb using wireshark : break takes 1s, step takes
>     3s. Duration between 2 USB packets is at max 0.5s.
>
>     I'm glad to hear someone debugging at lightspeed with avarice +
>     gdb. I hope I will manage to have such a setup.
>
>     I'm using avrdude for programming :
>     *avrdude -pm328p -c dragon_isp -Pusb -v -U
>     flash:w:arduino_avr_template_avr_plugin.hex:i*
>
>     debugWire fuse is set, so when I flash I have following logs :
>
>     *    avrdude: jtagmkII_setparm(): bad response to set parameter
>     command: RSP_FAILED
>         avrdude: jtagmkII_getsync(): ISP activation failed, trying
>     debugWire
>         avrdude: Target prepared for ISP, signed off.*
>
>     ... then program is flashed. As I understand, ISB programming is
>     used with debugWire fuse enabled.
>
>     Even if I wait during some seconds avarice won't run successfully,
>     I have these logs :
>     *AVaRICE version 2.13, Sep 19 2014 09:15:10*
>
>     *    JTAG config starting.**
>     **    Found a device: AVRDRAGON**
>     **    Serial number:  00:a2:00:04:72:83**
>     **    set paramater command failed: DEBUGWIRE SYNC FAILED**
>     **    Failed to activate debugWIRE debugging protocol**
>     **    USB bulk read error: Input/output error**
>     **    USB daemon died
>
>     *
>     If I power off/power on MCU then avarice launches successfully.
>
>     Now I will test avarice programming.
>
>     Le 09/12/2014 13:13, Armin Otterstätter a écrit :
>>     breaking/stepping is instantly on my setup. At least so fast that
>>     it just noteable to me.
>>
>>     Regarding the ISP issue are you using avarice or avrdude for
>>     programming? If avrdude, are you then using dragon with ISP or
>>     debugwire?
>>
>>     For me programming with avarice is working just fine. But when I
>>     use avrdude (which by itself also works just fine) I have to add
>>     some delay before invoking avarice otherwise avarice cannot open
>>     the USB. Because of that its (unfortunately) impossible to run
>>     avrdude as a shell command through .gdbinit.
>>
>>
>>     2014-12-09 11:34 GMT+01:00 Rémi Pincent <mr....@la...
>>     <mailto:mr....@la...>>:
>>
>>         Yes I'm on an Arch distribution.
>>         Thanks for wireshark tip. I will check USB connection.
>>
>>         How long is breaking/stepping with your setup?
>>
>>         In fact, flash ends successfully through ISP in debugWire
>>         mode. But after, if I want to launch a debug session I must
>>         unplug MCU. Reset line is just pulled up.
>>         This problem is also descriped on this topic :
>>         http://awtfy.com/2012/03/29/hardware-debugging-the-arduino-using-eclipse-and-the-avr-dragon/
>>         "If you get an error, check that you’re using libusb. Also in
>>         most cases just cycling the power on both the Dragon and the
>>         Arduino puts it back to working. If you give avarice a -v
>>         flag for verbose it will constantly spit shit out for you to
>>         read and not be interested in as you debug. "
>>
>>         Lah.
>>
>>         Le 09/12/2014 10:27, Armin Otterstätter a écrit :
>>>         I assume you're on Linux?
>>>         I did the Tracing with Wireshark
>>>         (http://wiki.wireshark.org/CaptureSetup/USB). There you can
>>>         set the time-display to "relative to previous captured
>>>         packet" (or similar) and then you can quickly see where the
>>>         USB is hanging.
>>>
>>>         Hmm the DEBUGWIRE SYNC FAILD doesn't sound too good. When
>>>         I'm downloading I don't have to unplug. Maybe there is some
>>>         problem with the DebugWire communication alltogether. Do you
>>>         have anything connected to Reset apart from the AVR Dragon?
>>>
>>>         Cheers,
>>>         Armin
>>>
>>>         PS.: sorry missed the reply-all in the first response... so
>>>         now back to the mailinglist...
>>>
>>>         2014-12-09 10:14 GMT+01:00 Rémi Pincent
>>>         <mr....@la... <mailto:mr....@la...>>:
>>>
>>>             Hi Armin,
>>>
>>>             I'm using AVaRICE version 2.13, Sep 19 2014 09:15:10.
>>>             According to sf status "AVaRICE 2.12 is the latest
>>>             release."!
>>>             What is your version?
>>>
>>>             How did you trace these USB issues?
>>>
>>>             Another question, after flashing code using debugger, I
>>>             have to unplug/plug debugger and MCU  otherwise when I
>>>             launch avarice I have "set paramater command failed:
>>>             DEBUGWIRE SYNC FAILED", have you some tips in order to
>>>             solve this issue?
>>>
>>>             Cheers
>>>             Lah
>>>
>>>             Le 09/12/2014 10:08, Armin Otterstätter a écrit :
>>>>             Which Version of avarice are you using?
>>>>             I had similar problems when using the avarice that came
>>>>             with an apt-get install on a recent ubuntu (Version
>>>>             2.11). I traced it down to some USB timeout issue. But
>>>>             the problem is resolved in trunk. Just get the most
>>>>             recent version from sf.net <http://sf.net>.
>>>>             If you're on the trunk already then it'll probably be
>>>>             something different...
>>>>
>>>>             Cheers,
>>>>             Armin
>>>>
>>>>             2014-12-09 9:54 GMT+01:00 Rémi Pincent
>>>>             <mr....@la... <mailto:mr....@la...>>:
>>>>
>>>>                 Hi all,
>>>>
>>>>                 I'm debugging ATmega328p with avarice + avr-gdb +
>>>>                 avrdragon using debugWire.
>>>>                 My binary is compiled with following options : -g2
>>>>                 -gstabs -O0
>>>>                 -ffunction-sections -fdata-sections -std=gnu99
>>>>                 All is right... But debugging is very slow,
>>>>                 stepping is awfully slow
>>>>                 (~5s), and breaking is also quite slow (~2s).
>>>>                 Moreover if have often to reflash code, it seems
>>>>                 flash get corrupted
>>>>                 when debug sessions does not finish cleanly.
>>>>
>>>>                 I've written topic about this issue here
>>>>                 http://www.avrfreaks.net/forum/avrdragon-debugwire-atmega328p-nice-unusable
>>>>                 But for now, I haven't found any people working
>>>>                 with a usable debugging
>>>>                 environment with debugWire and avr-gdb...
>>>>                 Suggestions are about changing
>>>>                 toolchain and debugging tools in order to use some
>>>>                 proprietary solutions...
>>>>
>>>>                 Have you got some suggestions in order to debug
>>>>                 efficiently?
>>>>
>>>>                 Regards.
>>>>
>>>>
>>>>
>>>>                 ------------------------------------------------------------------------------
>>>>                 Download BIRT iHub F-Type - The Free
>>>>                 Enterprise-Grade BIRT Server
>>>>                 from Actuate! Instantly Supercharge Your Business
>>>>                 Reports and Dashboards
>>>>                 with Interactivity, Sharing, Native Excel Exports,
>>>>                 App Integration & more
>>>>                 Get technology previously reserved for
>>>>                 billion-dollar corporations, FREE
>>>>                 http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>>>>                 _______________________________________________
>>>>                 avarice-user mailing list
>>>>                 ava...@li...
>>>>                 <mailto:ava...@li...>
>>>>                 https://lists.sourceforge.net/lists/listinfo/avarice-user
>>>>
>>>>
>>>
>>>
>>
>>
>
>

Re: [AVaRICE-user] debugWire : debug slow...

[Armin O. <arm...@gm...>]

You should be using dragon_dw otherwise it will temporarily activate ISP
and then debugwire is only possible after power-cycle. So this solves that
problem.

About the USB delay. This is about the same time as I measured. And this
relates to some USB-timeout. Is your avarice compiled with libusb 2.0 ?
Could you post the Wireshark log?

2014-12-09 15:00 GMT+01:00 Rémi Pincent <mr....@la...>:

>  I've monitored usb using wireshark : break takes 1s, step takes 3s.
> Duration between 2 USB packets is at max 0.5s.
>
> I'm glad to hear someone debugging at lightspeed with avarice + gdb. I
> hope I will manage to have such a setup.
>
> I'm using avrdude for programming :
> *    avrdude -pm328p -c dragon_isp -Pusb -v -U
> flash:w:arduino_avr_template_avr_plugin.hex:i*
>
> debugWire fuse is set, so when I flash I have following logs :
>
>
>
> *    avrdude: jtagmkII_setparm(): bad response to set parameter command:
> RSP_FAILED     avrdude: jtagmkII_getsync(): ISP activation failed, trying
> debugWire     avrdude: Target prepared for ISP, signed off.*
>
> ... then program is flashed. As I understand, ISB programming is used with
> debugWire fuse enabled.
>
> Even if I wait during some seconds avarice won't run successfully, I have
> these logs :
>         *AVaRICE version 2.13, Sep 19 2014 09:15:10*
>
> *    JTAG config starting.*
> *    Found a device: AVRDRAGON*
> *    Serial number:  00:a2:00:04:72:83*
> *    set paramater command failed: DEBUGWIRE SYNC FAILED*
> *    Failed to activate debugWIRE debugging protocol*
> *    USB bulk read error: Input/output error*
>
>
> *    USB daemon died *
> If I power off/power on MCU then avarice launches successfully.
>
> Now I will test avarice programming.
>
> Le 09/12/2014 13:13, Armin Otterstätter a écrit :
>
>  breaking/stepping is instantly on my setup. At least so fast that it
> just noteable to me.
>
>  Regarding the ISP issue are you using avarice or avrdude for programming?
> If avrdude, are you then using dragon with ISP or debugwire?
>
>  For me programming with avarice is working just fine. But when I use
> avrdude (which by itself also works just fine) I have to add some delay
> before invoking avarice otherwise avarice cannot open the USB. Because of
> that its (unfortunately) impossible to run avrdude as a shell command
> through .gdbinit.
>
>
> 2014-12-09 11:34 GMT+01:00 Rémi Pincent <mr....@la...>:
>
>>  Yes I'm on an Arch distribution.
>> Thanks for wireshark tip. I will check USB connection.
>>
>> How long is breaking/stepping with your setup?
>>
>> In fact, flash ends successfully through ISP in debugWire mode. But
>> after, if I want to launch a debug session I must unplug MCU. Reset line is
>> just pulled up.
>> This problem is also descriped on this topic :
>>
>> http://awtfy.com/2012/03/29/hardware-debugging-the-arduino-using-eclipse-and-the-avr-dragon/
>> "If you get an error, check that you’re using libusb. Also in most cases
>> just cycling the power on both the Dragon and the Arduino puts it back to
>> working. If you give avarice a -v flag for verbose it will constantly spit
>> shit out for you to read and not be interested in as you debug. "
>>
>> Lah.
>>
>> Le 09/12/2014 10:27, Armin Otterstätter a écrit :
>>
>>   I assume you're on Linux?
>>  I did the Tracing with Wireshark (
>> http://wiki.wireshark.org/CaptureSetup/USB). There you can set the
>> time-display to "relative to previous captured packet" (or similar) and
>> then you can quickly see where the USB is hanging.
>>
>>  Hmm the DEBUGWIRE SYNC FAILD doesn't sound too good. When I'm
>> downloading I don't have to unplug. Maybe there is some problem with the
>> DebugWire communication alltogether. Do you have anything connected to
>> Reset apart from the AVR Dragon?
>>
>>  Cheers,
>> Armin
>>
>> PS.: sorry missed the reply-all in the first response... so now back to
>> the mailinglist...
>>
>> 2014-12-09 10:14 GMT+01:00 Rémi Pincent <mr....@la...>:
>>
>>>  Hi Armin,
>>>
>>> I'm using AVaRICE version 2.13, Sep 19 2014 09:15:10.
>>> According to sf status "AVaRICE 2.12 is the latest release."!
>>> What is your version?
>>>
>>> How did you trace these USB issues?
>>>
>>> Another question, after flashing code using debugger, I have to
>>> unplug/plug debugger and MCU  otherwise when I launch avarice I have "set
>>> paramater command failed: DEBUGWIRE SYNC FAILED", have you some tips in
>>> order to solve this issue?
>>>
>>> Cheers
>>> Lah
>>>
>>> Le 09/12/2014 10:08, Armin Otterstätter a écrit :
>>>
>>>  Which Version of avarice are you using?
>>> I had similar problems when using the avarice that came with an apt-get
>>> install on a recent ubuntu (Version 2.11). I traced it down to some USB
>>> timeout issue. But the problem is resolved in trunk. Just get the most
>>> recent version from sf.net.
>>>  If you're on the trunk already then it'll probably be something
>>> different...
>>>
>>>  Cheers,
>>> Armin
>>>
>>> 2014-12-09 9:54 GMT+01:00 Rémi Pincent <mr....@la...>:
>>>
>>>> Hi all,
>>>>
>>>> I'm debugging ATmega328p with avarice + avr-gdb + avrdragon using
>>>> debugWire.
>>>> My binary is compiled with following options : -g2 -gstabs -O0
>>>> -ffunction-sections -fdata-sections -std=gnu99
>>>> All is right... But debugging is very slow, stepping is awfully slow
>>>> (~5s), and breaking is also quite slow (~2s).
>>>> Moreover if have often to reflash code, it seems flash get corrupted
>>>> when debug sessions does not finish cleanly.
>>>>
>>>> I've written topic about this issue here
>>>>
>>>> http://www.avrfreaks.net/forum/avrdragon-debugwire-atmega328p-nice-unusable
>>>> But for now, I haven't found any people working with a usable debugging
>>>> environment with debugWire and avr-gdb... Suggestions are about changing
>>>> toolchain and debugging tools in order to use some proprietary
>>>> solutions...
>>>>
>>>> Have you got some suggestions in order to debug efficiently?
>>>>
>>>> Regards.
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>>>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>>>> with Interactivity, Sharing, Native Excel Exports, App Integration &
>>>> more
>>>> Get technology previously reserved for billion-dollar corporations, FREE
>>>>
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>>>> _______________________________________________
>>>> avarice-user mailing list
>>>> ava...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/avarice-user
>>>>
>>>
>>>
>>>
>>
>>
>
>

Re: [AVaRICE-user] debugWire : debug slow...

[Rémi P. <mr....@la...>]

I've monitored usb using wireshark : break takes 1s, step takes 3s. 
Duration between 2 USB packets is at max 0.5s.

I'm glad to hear someone debugging at lightspeed with avarice + gdb. I 
hope I will manage to have such a setup.

I'm using avrdude for programming :
*    avrdude -pm328p -c dragon_isp -Pusb -v -U 
flash:w:arduino_avr_template_avr_plugin.hex:i*

debugWire fuse is set, so when I flash I have following logs :

*    avrdude: jtagmkII_setparm(): bad response to set parameter command: 
RSP_FAILED
     avrdude: jtagmkII_getsync(): ISP activation failed, trying debugWire
     avrdude: Target prepared for ISP, signed off.*

... then program is flashed. As I understand, ISB programming is used 
with debugWire fuse enabled.

Even if I wait during some seconds avarice won't run successfully, I 
have these logs :
*AVaRICE version 2.13, Sep 19 2014 09:15:10*

*    JTAG config starting.**
**    Found a device: AVRDRAGON**
**    Serial number:  00:a2:00:04:72:83**
**    set paramater command failed: DEBUGWIRE SYNC FAILED**
**    Failed to activate debugWIRE debugging protocol**
**    USB bulk read error: Input/output error**
**    USB daemon died

*
If I power off/power on MCU then avarice launches successfully.

Now I will test avarice programming.

Le 09/12/2014 13:13, Armin Otterstätter a écrit :
> breaking/stepping is instantly on my setup. At least so fast that it 
> just noteable to me.
>
> Regarding the ISP issue are you using avarice or avrdude for 
> programming? If avrdude, are you then using dragon with ISP or debugwire?
>
> For me programming with avarice is working just fine. But when I use 
> avrdude (which by itself also works just fine) I have to add some 
> delay before invoking avarice otherwise avarice cannot open the USB. 
> Because of that its (unfortunately) impossible to run avrdude as a 
> shell command through .gdbinit.
>
>
> 2014-12-09 11:34 GMT+01:00 Rémi Pincent <mr....@la... 
> <mailto:mr....@la...>>:
>
>     Yes I'm on an Arch distribution.
>     Thanks for wireshark tip. I will check USB connection.
>
>     How long is breaking/stepping with your setup?
>
>     In fact, flash ends successfully through ISP in debugWire mode.
>     But after, if I want to launch a debug session I must unplug MCU.
>     Reset line is just pulled up.
>     This problem is also descriped on this topic :
>     http://awtfy.com/2012/03/29/hardware-debugging-the-arduino-using-eclipse-and-the-avr-dragon/
>     "If you get an error, check that you’re using libusb. Also in most
>     cases just cycling the power on both the Dragon and the Arduino
>     puts it back to working. If you give avarice a -v flag for verbose
>     it will constantly spit shit out for you to read and not be
>     interested in as you debug. "
>
>     Lah.
>
>     Le 09/12/2014 10:27, Armin Otterstätter a écrit :
>>     I assume you're on Linux?
>>     I did the Tracing with Wireshark
>>     (http://wiki.wireshark.org/CaptureSetup/USB). There you can set
>>     the time-display to "relative to previous captured packet" (or
>>     similar) and then you can quickly see where the USB is hanging.
>>
>>     Hmm the DEBUGWIRE SYNC FAILD doesn't sound too good. When I'm
>>     downloading I don't have to unplug. Maybe there is some problem
>>     with the DebugWire communication alltogether. Do you have
>>     anything connected to Reset apart from the AVR Dragon?
>>
>>     Cheers,
>>     Armin
>>
>>     PS.: sorry missed the reply-all in the first response... so now
>>     back to the mailinglist...
>>
>>     2014-12-09 10:14 GMT+01:00 Rémi Pincent <mr....@la...
>>     <mailto:mr....@la...>>:
>>
>>         Hi Armin,
>>
>>         I'm using AVaRICE version 2.13, Sep 19 2014 09:15:10.
>>         According to sf status "AVaRICE 2.12 is the latest release."!
>>         What is your version?
>>
>>         How did you trace these USB issues?
>>
>>         Another question, after flashing code using debugger, I have
>>         to unplug/plug debugger and MCU  otherwise when I launch
>>         avarice I have "set paramater command failed: DEBUGWIRE SYNC
>>         FAILED", have you some tips in order to solve this issue?
>>
>>         Cheers
>>         Lah
>>
>>         Le 09/12/2014 10:08, Armin Otterstätter a écrit :
>>>         Which Version of avarice are you using?
>>>         I had similar problems when using the avarice that came with
>>>         an apt-get install on a recent ubuntu (Version 2.11). I
>>>         traced it down to some USB timeout issue. But the problem is
>>>         resolved in trunk. Just get the most recent version from
>>>         sf.net <http://sf.net>.
>>>         If you're on the trunk already then it'll probably be
>>>         something different...
>>>
>>>         Cheers,
>>>         Armin
>>>
>>>         2014-12-09 9:54 GMT+01:00 Rémi Pincent
>>>         <mr....@la... <mailto:mr....@la...>>:
>>>
>>>             Hi all,
>>>
>>>             I'm debugging ATmega328p with avarice + avr-gdb +
>>>             avrdragon using debugWire.
>>>             My binary is compiled with following options : -g2
>>>             -gstabs -O0
>>>             -ffunction-sections -fdata-sections -std=gnu99
>>>             All is right... But debugging is very slow, stepping is
>>>             awfully slow
>>>             (~5s), and breaking is also quite slow (~2s).
>>>             Moreover if have often to reflash code, it seems flash
>>>             get corrupted
>>>             when debug sessions does not finish cleanly.
>>>
>>>             I've written topic about this issue here
>>>             http://www.avrfreaks.net/forum/avrdragon-debugwire-atmega328p-nice-unusable
>>>             But for now, I haven't found any people working with a
>>>             usable debugging
>>>             environment with debugWire and avr-gdb... Suggestions
>>>             are about changing
>>>             toolchain and debugging tools in order to use some
>>>             proprietary solutions...
>>>
>>>             Have you got some suggestions in order to debug efficiently?
>>>
>>>             Regards.
>>>
>>>
>>>
>>>             ------------------------------------------------------------------------------
>>>             Download BIRT iHub F-Type - The Free Enterprise-Grade
>>>             BIRT Server
>>>             from Actuate! Instantly Supercharge Your Business
>>>             Reports and Dashboards
>>>             with Interactivity, Sharing, Native Excel Exports, App
>>>             Integration & more
>>>             Get technology previously reserved for billion-dollar
>>>             corporations, FREE
>>>             http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>>>             _______________________________________________
>>>             avarice-user mailing list
>>>             ava...@li...
>>>             <mailto:ava...@li...>
>>>             https://lists.sourceforge.net/lists/listinfo/avarice-user
>>>
>>>
>>
>>
>
>

Re: [AVaRICE-user] debugWire : debug slow...

[Armin O. <arm...@gm...>]

breaking/stepping is instantly on my setup. At least so fast that it just
noteable to me.

Regarding the ISP issue are you using avarice or avrdude for programming?
If avrdude, are you then using dragon with ISP or debugwire?

For me programming with avarice is working just fine. But when I use
avrdude (which by itself also works just fine) I have to add some delay
before invoking avarice otherwise avarice cannot open the USB. Because of
that its (unfortunately) impossible to run avrdude as a shell command
through .gdbinit.


2014-12-09 11:34 GMT+01:00 Rémi Pincent <mr....@la...>:

>  Yes I'm on an Arch distribution.
> Thanks for wireshark tip. I will check USB connection.
>
> How long is breaking/stepping with your setup?
>
> In fact, flash ends successfully through ISP in debugWire mode. But after,
> if I want to launch a debug session I must unplug MCU. Reset line is just
> pulled up.
> This problem is also descriped on this topic :
>
> http://awtfy.com/2012/03/29/hardware-debugging-the-arduino-using-eclipse-and-the-avr-dragon/
> "If you get an error, check that you’re using libusb. Also in most cases
> just cycling the power on both the Dragon and the Arduino puts it back to
> working. If you give avarice a -v flag for verbose it will constantly spit
> shit out for you to read and not be interested in as you debug. "
>
> Lah.
>
> Le 09/12/2014 10:27, Armin Otterstätter a écrit :
>
>   I assume you're on Linux?
>  I did the Tracing with Wireshark (
> http://wiki.wireshark.org/CaptureSetup/USB). There you can set the
> time-display to "relative to previous captured packet" (or similar) and
> then you can quickly see where the USB is hanging.
>
>  Hmm the DEBUGWIRE SYNC FAILD doesn't sound too good. When I'm downloading
> I don't have to unplug. Maybe there is some problem with the DebugWire
> communication alltogether. Do you have anything connected to Reset apart
> from the AVR Dragon?
>
>  Cheers,
> Armin
>
> PS.: sorry missed the reply-all in the first response... so now back to
> the mailinglist...
>
> 2014-12-09 10:14 GMT+01:00 Rémi Pincent <mr....@la...>:
>
>>  Hi Armin,
>>
>> I'm using AVaRICE version 2.13, Sep 19 2014 09:15:10.
>> According to sf status "AVaRICE 2.12 is the latest release."!
>> What is your version?
>>
>> How did you trace these USB issues?
>>
>> Another question, after flashing code using debugger, I have to
>> unplug/plug debugger and MCU  otherwise when I launch avarice I have "set
>> paramater command failed: DEBUGWIRE SYNC FAILED", have you some tips in
>> order to solve this issue?
>>
>> Cheers
>> Lah
>>
>> Le 09/12/2014 10:08, Armin Otterstätter a écrit :
>>
>>  Which Version of avarice are you using?
>> I had similar problems when using the avarice that came with an apt-get
>> install on a recent ubuntu (Version 2.11). I traced it down to some USB
>> timeout issue. But the problem is resolved in trunk. Just get the most
>> recent version from sf.net.
>>  If you're on the trunk already then it'll probably be something
>> different...
>>
>>  Cheers,
>> Armin
>>
>> 2014-12-09 9:54 GMT+01:00 Rémi Pincent <mr....@la...>:
>>
>>> Hi all,
>>>
>>> I'm debugging ATmega328p with avarice + avr-gdb + avrdragon using
>>> debugWire.
>>> My binary is compiled with following options : -g2 -gstabs -O0
>>> -ffunction-sections -fdata-sections -std=gnu99
>>> All is right... But debugging is very slow, stepping is awfully slow
>>> (~5s), and breaking is also quite slow (~2s).
>>> Moreover if have often to reflash code, it seems flash get corrupted
>>> when debug sessions does not finish cleanly.
>>>
>>> I've written topic about this issue here
>>>
>>> http://www.avrfreaks.net/forum/avrdragon-debugwire-atmega328p-nice-unusable
>>> But for now, I haven't found any people working with a usable debugging
>>> environment with debugWire and avr-gdb... Suggestions are about changing
>>> toolchain and debugging tools in order to use some proprietary
>>> solutions...
>>>
>>> Have you got some suggestions in order to debug efficiently?
>>>
>>> Regards.
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>>> Get technology previously reserved for billion-dollar corporations, FREE
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> avarice-user mailing list
>>> ava...@li...
>>> https://lists.sourceforge.net/lists/listinfo/avarice-user
>>>
>>
>>
>>
>
>

Re: [AVaRICE-user] debugWire : debug slow...

[Rémi P. <mr....@la...>]

Yes I'm on an Arch distribution.
Thanks for wireshark tip. I will check USB connection.

How long is breaking/stepping with your setup?

In fact, flash ends successfully through ISP in debugWire mode. But 
after, if I want to launch a debug session I must unplug MCU. Reset line 
is just pulled up.
This problem is also descriped on this topic :
http://awtfy.com/2012/03/29/hardware-debugging-the-arduino-using-eclipse-and-the-avr-dragon/
"If you get an error, check that you’re using libusb. Also in most cases 
just cycling the power on both the Dragon and the Arduino puts it back 
to working. If you give avarice a -v flag for verbose it will constantly 
spit shit out for you to read and not be interested in as you debug. "

Lah.

Le 09/12/2014 10:27, Armin Otterstätter a écrit :
> I assume you're on Linux?
> I did the Tracing with Wireshark 
> (http://wiki.wireshark.org/CaptureSetup/USB). There you can set the 
> time-display to "relative to previous captured packet" (or similar) 
> and then you can quickly see where the USB is hanging.
>
> Hmm the DEBUGWIRE SYNC FAILD doesn't sound too good. When I'm 
> downloading I don't have to unplug. Maybe there is some problem with 
> the DebugWire communication alltogether. Do you have anything 
> connected to Reset apart from the AVR Dragon?
>
> Cheers,
> Armin
>
> PS.: sorry missed the reply-all in the first response... so now back 
> to the mailinglist...
>
> 2014-12-09 10:14 GMT+01:00 Rémi Pincent <mr....@la... 
> <mailto:mr....@la...>>:
>
>     Hi Armin,
>
>     I'm using AVaRICE version 2.13, Sep 19 2014 09:15:10.
>     According to sf status "AVaRICE 2.12 is the latest release."!
>     What is your version?
>
>     How did you trace these USB issues?
>
>     Another question, after flashing code using debugger, I have to
>     unplug/plug debugger and MCU  otherwise when I launch avarice I
>     have "set paramater command failed: DEBUGWIRE SYNC FAILED", have
>     you some tips in order to solve this issue?
>
>     Cheers
>     Lah
>
>     Le 09/12/2014 10:08, Armin Otterstätter a écrit :
>>     Which Version of avarice are you using?
>>     I had similar problems when using the avarice that came with an
>>     apt-get install on a recent ubuntu (Version 2.11). I traced it
>>     down to some USB timeout issue. But the problem is resolved in
>>     trunk. Just get the most recent version from sf.net <http://sf.net>.
>>     If you're on the trunk already then it'll probably be something
>>     different...
>>
>>     Cheers,
>>     Armin
>>
>>     2014-12-09 9:54 GMT+01:00 Rémi Pincent <mr....@la...
>>     <mailto:mr....@la...>>:
>>
>>         Hi all,
>>
>>         I'm debugging ATmega328p with avarice + avr-gdb + avrdragon
>>         using debugWire.
>>         My binary is compiled with following options : -g2 -gstabs -O0
>>         -ffunction-sections -fdata-sections -std=gnu99
>>         All is right... But debugging is very slow, stepping is
>>         awfully slow
>>         (~5s), and breaking is also quite slow (~2s).
>>         Moreover if have often to reflash code, it seems flash get
>>         corrupted
>>         when debug sessions does not finish cleanly.
>>
>>         I've written topic about this issue here
>>         http://www.avrfreaks.net/forum/avrdragon-debugwire-atmega328p-nice-unusable
>>         But for now, I haven't found any people working with a usable
>>         debugging
>>         environment with debugWire and avr-gdb... Suggestions are
>>         about changing
>>         toolchain and debugging tools in order to use some
>>         proprietary solutions...
>>
>>         Have you got some suggestions in order to debug efficiently?
>>
>>         Regards.
>>
>>
>>
>>         ------------------------------------------------------------------------------
>>         Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>>         from Actuate! Instantly Supercharge Your Business Reports and
>>         Dashboards
>>         with Interactivity, Sharing, Native Excel Exports, App
>>         Integration & more
>>         Get technology previously reserved for billion-dollar
>>         corporations, FREE
>>         http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>>         _______________________________________________
>>         avarice-user mailing list
>>         ava...@li...
>>         <mailto:ava...@li...>
>>         https://lists.sourceforge.net/lists/listinfo/avarice-user
>>
>>
>
>

Re: [AVaRICE-user] debugWire : debug slow...

[Armin O. <arm...@gm...>]

I assume you're on Linux?
I did the Tracing with Wireshark (http://wiki.wireshark.org/CaptureSetup/USB).
There you can set the time-display to "relative to previous captured
packet" (or similar) and then you can quickly see where the USB is hanging.

Hmm the DEBUGWIRE SYNC FAILD doesn't sound too good. When I'm downloading I
don't have to unplug. Maybe there is some problem with the DebugWire
communication alltogether. Do you have anything connected to Reset apart
from the AVR Dragon?

Cheers,
Armin

PS.: sorry missed the reply-all in the first response... so now back to the
mailinglist...

2014-12-09 10:14 GMT+01:00 Rémi Pincent <mr....@la...>:

>  Hi Armin,
>
> I'm using AVaRICE version 2.13, Sep 19 2014 09:15:10.
> According to sf status "AVaRICE 2.12 is the latest release."!
> What is your version?
>
> How did you trace these USB issues?
>
> Another question, after flashing code using debugger, I have to
> unplug/plug debugger and MCU  otherwise when I launch avarice I have "set
> paramater command failed: DEBUGWIRE SYNC FAILED", have you some tips in
> order to solve this issue?
>
> Cheers
> Lah
>
> Le 09/12/2014 10:08, Armin Otterstätter a écrit :
>
>  Which Version of avarice are you using?
> I had similar problems when using the avarice that came with an apt-get
> install on a recent ubuntu (Version 2.11). I traced it down to some USB
> timeout issue. But the problem is resolved in trunk. Just get the most
> recent version from sf.net.
>  If you're on the trunk already then it'll probably be something
> different...
>
>  Cheers,
> Armin
>
> 2014-12-09 9:54 GMT+01:00 Rémi Pincent <mr....@la...>:
>
>> Hi all,
>>
>> I'm debugging ATmega328p with avarice + avr-gdb + avrdragon using
>> debugWire.
>> My binary is compiled with following options : -g2 -gstabs -O0
>> -ffunction-sections -fdata-sections -std=gnu99
>> All is right... But debugging is very slow, stepping is awfully slow
>> (~5s), and breaking is also quite slow (~2s).
>> Moreover if have often to reflash code, it seems flash get corrupted
>> when debug sessions does not finish cleanly.
>>
>> I've written topic about this issue here
>>
>> http://www.avrfreaks.net/forum/avrdragon-debugwire-atmega328p-nice-unusable
>> But for now, I haven't found any people working with a usable debugging
>> environment with debugWire and avr-gdb... Suggestions are about changing
>> toolchain and debugging tools in order to use some proprietary
>> solutions...
>>
>> Have you got some suggestions in order to debug efficiently?
>>
>> Regards.
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>> Get technology previously reserved for billion-dollar corporations, FREE
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>> _______________________________________________
>> avarice-user mailing list
>> ava...@li...
>> https://lists.sourceforge.net/lists/listinfo/avarice-user
>>
>
>
>

[AVaRICE-user] debugWire : debug slow...

[Rémi P. <mr....@la...>]

Hi all,

I'm debugging ATmega328p with avarice + avr-gdb + avrdragon using debugWire.
My binary is compiled with following options : -g2 -gstabs -O0 
-ffunction-sections -fdata-sections -std=gnu99
All is right... But debugging is very slow, stepping is awfully slow 
(~5s), and breaking is also quite slow (~2s).
Moreover if have often to reflash code, it seems flash get corrupted 
when debug sessions does not finish cleanly.

I've written topic about this issue here 
http://www.avrfreaks.net/forum/avrdragon-debugwire-atmega328p-nice-unusable
But for now, I haven't found any people working with a usable debugging 
environment with debugWire and avr-gdb... Suggestions are about changing 
toolchain and debugging tools in order to use some proprietary solutions...

Have you got some suggestions in order to debug efficiently?

Regards.

[AVaRICE-user] avarice not working with --detach on Linux

[Matthijs K. <mat...@st...>]

Hi folks,

while trying to use avarice with the --detach option, I ran into read
timeouts, whereas everything works without --detach (using a JTAGICE3).
Someone mentioned this before on this list (IIRC), but didn't look for
the real cause. I decided to dig in.

I've found that the actual act of forking directly breaks all
communication. If I moved the forking a lot up to before the creation of
the jtag3 object, things still worked. Moving it down until after the
creation (but before the initJtagBox call) broke the initial signon
command with a read timeout.

Digging further, I've found that the USB communication, as initialized
in jtag::openUSB, uses pthreads. It seems these do not play well with
fork():

	The fork(2) function creates a copy of the process, all memory
	pages are copied, open file descriptors are copied etc. All this
	stuff is intuitive for a UNIX programmer. One important thing
	that differs the child process from the parent is that the child
	has only one thread.

From http://www.linuxprogrammingblog.com/threads-and-fork-think-twice-before-using-them

So the problem seems obvious: forking after creating threads does not
work. I tried re-creating the threads after the fork, which appears to
work, but gave an error at shutdown:

*** Error in `avarice': double free or corruption (fasttop): 0x000000000086a730 ***

That's probably libusb that doesn't like being cut short halfway through
a blocking call.


It seems the proper solution here is to fork early, and then let the
parent process wait for SIGUSR1 before exiting (and letting the forked
process send that signal after initialization is complete). Does that
sound reasonable?

It seems this is similar what the pre-pthread implementation did, except
that that used a child process for just the usb communication and a
persistent parent process, and this would just be short-term
arrangement, with the child process doing all the work.

How does this sound?

Gr.

Matthijs

Re: [AVaRICE-user] Debugging 4-Page Erase Devices (tiny1634, tiny841, tiny441)

[Joerg W. <j...@ur...>]

As Knut Schwichtenberg wrote:

> maybe I'm wrong, but isn't Studio 6.2 using EDBG debugging? If that is 
> true and you try to use an "EDBG infected" ICE3 with avarice you are 
> lost.

Working on that! :)
-- 
cheers, Joerg               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/
Never trust an operating system you don't have sources for. ;-)

Re: [AVaRICE-user] Debugging 4-Page Erase Devices (tiny1634, tiny841, tiny441)

[Knut S. <ks...@we...>]

Hi,

maybe I'm wrong, but isn't Studio 6.2 using EDBG debugging? If that is 
true and you try to use an "EDBG infected" ICE3 with avarice you are 
lost. The firmware is updated in a way which avarice is currently unable 
to handle.

Cheers, Knut

Am 17.10.2014 um 21:29 schrieb Armin Otterstätter:
> I had the chance to trace usb-communication on a windows PC with AVR 
> Studio 6.2.
> There the set device description looks a little different mainly i 
> found these telegrams:

Re: [AVaRICE-user] Debugging 4-Page Erase Devices (tiny1634, tiny841, tiny441)

[Armin O. <arm...@gm...>]

I had the chance to trace usb-communication on a windows PC with AVR Studio
6.2.
There the set device description looks a little different mainly i found
these telegrams:

1b 05 00 23 00 00 00 0e
36 02 00 1f 10 00 00 20
00 00 00 00 00 00 00 fe
01 00 00 01 00 02 04 01
04 00 00 00 27 1f 1e 1c
1d 57 00 56 0a

1b 06 00 0c 00 00 00 0e
36 80 00 08 ff ff ff ff
fb ff ff ff 55 81

1b 07 00 0c 00 00 00 0e
36 88 00 08 df bf fe ff
fb ff 7f fa 0a 00

1b 08 00 18 00 00 00 0e
36 81 00 14 ff ff ff ff
fe ff fe ff ff ff ff ff
ff fe ff ff ff ff ff ff
20 cf

1b 09 00 18 00 00 00 0e
36 89 00 14 ff ff 0f ff
be ff be ff fa ff ff ff
ff fe ff ff ff ff ff ff
d6 6c

The command will always be send as set XMegaParms (although we're talking
about an attiny here). The last four look like the ordinary SFR-Maps for
Read and Write access (although no Shadow-List here).
The first one looks to me as what is described as jtag3_device_desc_type in
jtag.h. The most interesting here is that the byte defined as always_one
now is 4. Which perfectly matches with my earlier thought about how that
information that 4 buffers need to be filled per page-erase gets to the
Dragon.

So i simply patched those commands into the setDeviceDescriptor like copied
below and it works just fine.
For a cleaner solution of course some way has to be found to merge these
four commands into the device-description structure.
And by the way when I patched those lines, it occurred to me as if there is
a delete [] missing after the call to doJtagCommand. But I'm not an c++
expert, since mostly working on µC with C.

I hope this helps... at least somebody ;-)

Armin

        uchar msg1[] = {0x36, 0x02, 0x00, 0x1f, 0x10, 0x00, 0x00, 0x20,
0x00, 0x00, 0x00, 0x00,
                        0x00, 0x00, 0x00, 0xfe, 0x01, 0x00, 0x00, 0x01,
0x00, 0x02, 0x04, 0x01,
                        0x04, 0x00, 0x00, 0x00, 0x27, 0x1f, 0x1e, 0x1c,
0x1d, 0x57, 0x00 };
        uchar msg2[] = {0x36, 0x80, 0x00, 0x08, 0xff, 0xff, 0xff, 0xff,
0xfb, 0xff, 0xff, 0xff};
        uchar msg3[] = {0x36, 0x88, 0x00, 0x08, 0xdf, 0xbf, 0xfe, 0xff,
0xfb, 0xff, 0x7f, 0xfa};
        uchar msg4[] = {0x36, 0x81, 0x00, 0x14, 0xff, 0xff, 0xff, 0xff,
0xfe, 0xff, 0xfe, 0xff,
                        0xff, 0xff, 0xff, 0xff, 0xff, 0xfe, 0xff, 0xff,
0xff, 0xff, 0xff, 0xff};
        uchar msg5[] = {0x36, 0x89, 0x00, 0x14, 0xff, 0xff, 0x0f, 0xff,
0xbe, 0xff, 0xbe, 0xff,
                        0xfa, 0xff, 0xff, 0xff, 0xff, 0xfe, 0xff, 0xff,
0xff, 0xff, 0xff, 0xff};

        //doJtagCommand(command, devdescrlen, response, respSize);
        doJtagCommand(msg1, sizeof(msg1), response, respSize); delete []
response;
        doJtagCommand(msg2, sizeof(msg2), response, respSize); delete []
response;
        doJtagCommand(msg3, sizeof(msg3), response, respSize); delete []
response;
        doJtagCommand(msg4, sizeof(msg4), response, respSize); delete []
response;
        doJtagCommand(msg5, sizeof(msg5), response, respSize); delete []
response;

Re: [AVaRICE-user] JTAG ICE: Cannot synchronise

[Joerg W. <j...@ur...>]

As Philip Mulrane wrote:

> > avrdude: jtagmkII_setparm(): bad response to set parameter command: 
> > RSP_FAILED

OK, so it's exactly the same as with AVaRICE.

> Then I saw that my cabling was not correct and I tried this cabling:
> http://www.avrfreaks.net/comment/715428#comment-715428

Just keep in mind that the JTAGICEmkII uses a different pinout for PDI
than the JTAGICE3.  For the mkII, use the white-colored PDI adapter.
-- 
cheers, Joerg               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/
Never trust an operating system you don't have sources for. ;-)

Re: [AVaRICE-user] JTAG ICE: Cannot synchronise

[Philip M. <in...@bi...>]

Avrdude was running in JTAG mode, I tried it in PDI mode:

> avrdude -p x128a1 -cjtag2pdi -P usb -U 
> flash:w:\Projects\XMega\test\Debug\test.hex
> avrdude: jtagmkII_setparm(): bad response to set parameter command: 
> RSP_FAILED
>
> avrdude done.  Thank you.

Then I saw that my cabling was not correct and I tried this cabling:
http://www.avrfreaks.net/comment/715428#comment-715428

Still the same response, then I saw this:
http://www.avrfreaks.net/comment/716360#comment-716360
>
> I got PDI to work on the Xplained A1 Board by disabling the JTAGEN 
> fuse. PDI is apparently made to take priority over JTAG, however this 
> does not seem to be the case for whatever reason on the A1 Board.
>
> As of right now i can program and debug with JTAG with the Dragon, Use 
> PDI (When JTAGEN fuse is disabled) With AVRISP MII.
>
So, it looks like it's the setup of my board. I will stick to JTAG for 
the moment.
Thanks!




On 14.10.2014 16:00, Joerg Wunsch wrote:
> As Philip Mulrane wrote:
>
>> command[0x02, 1]: 02 03 06
>> recv: 0x1b
>> recv: 0x01
>> recv: 0x00
>> recv: 0x01
>> recv: 0x00
>> recv: 0x00
>> recv: 0x00
>> recv: 0x0e
>> sDATA: reading 1 bytes
>> read:  a0
>> recv: 0xcf
>> recv: 0xa2
>> CRC OK
>> Got message seqno 1 (command_sequence == 1)
>> response: A0
> That's trying to switch the emulator mode to PDI, which is
> responded by a very informative "failed" (0xa0). :(
>
> There's unfortunately not much AVaRICE can do here about it.
>
> You told that AVRDUDE can successfully talk to the chip through PDI,
> so this suggests the cabling were OK.  Can you verify the initial
> command sequence between AVRDUDE and AVaRICE?  I tried it here, and
> the initial sequence is mostly the same: right after the "sign on"
> command, it sets parameter 3 (emulator mode) to value 6 (PDI).


-- 
Bittrace14 UG
Immanuel-Kant Str.59b
31812 Bad Pyrmont

Fax: +49 32223945096

HRB 209338 Amtsger. Hannover

Geschäftsführer
Pauline Atkinson

Re: [AVaRICE-user] JTAG ICE: Cannot synchronise

[Joerg W. <j...@ur...>]

As Philip Mulrane wrote:

> command[0x02, 1]: 02 03 06
> recv: 0x1b
> recv: 0x01
> recv: 0x00
> recv: 0x01
> recv: 0x00
> recv: 0x00
> recv: 0x00
> recv: 0x0e
> sDATA: reading 1 bytes
> read:  a0
> recv: 0xcf
> recv: 0xa2
> CRC OK
> Got message seqno 1 (command_sequence == 1)
> response: A0

That's trying to switch the emulator mode to PDI, which is
responded by a very informative "failed" (0xa0). :(

There's unfortunately not much AVaRICE can do here about it.

You told that AVRDUDE can successfully talk to the chip through PDI,
so this suggests the cabling were OK.  Can you verify the initial
command sequence between AVRDUDE and AVaRICE?  I tried it here, and
the initial sequence is mostly the same: right after the "sign on"
command, it sets parameter 3 (emulator mode) to value 6 (PDI).
-- 
cheers, Joerg               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/
Never trust an operating system you don't have sources for. ;-)

Re: [AVaRICE-user] JTAG ICE: Cannot synchronise

[Philip M. <in...@bi...>]

OK,
thanks, I figured as much, just curious as to the reason. BTW the 
example was JTAG programming and not PDI (maybe I labeled it incorrectly 
in my original mail). For reference I have attached a dump of a run 
attempting to start avarice as a debugger front-end, but in PDI mode. 
Here the response seems to be A0.
WRT the programming, consider it dropped, I'll stick to AvrDude for that.
Br,
Philip

avarice -X -2 -j usb :4242 -P atxmega128a1
-----------------------------------
Found JTAG ICE, serno: 00B0000024B9
Attempting synchronisation at bitrate 19200

command[0x01, 1]: 01
recv: 0x1b
recv: 0x00
recv: 0x00
recv: 0x1c
recv: 0x00
recv: 0x00
recv: 0x00
recv: 0x0e
sDATA: reading 28 bytes
read:  86 01 ff 24 07 00 ff 24 07 01 00 b0 00 00 24 b9 4a 54 41 47 49 43 
45 6d 6b 49 49 00
recv: 0x9a
recv: 0x30
CRC OK
Got message seqno 0 (command_sequence == 0)
response: 86 01 FF 24 07 00 FF 24 07 01 00 B0 00 00 24 B9 4A 54 41 47 49 
43 45 6D 6B 49 49 00
JTAG ICE mkII sign-on message:
Communications protocol version: 1
M_MCU:
   boot-loader FW version:        255
   firmware version:              7.36
   hardware version:              0
S_MCU:
   boot-loader FW version:        255
   firmware version:              7.36
   hardware version:              1

command[0x02, 1]: 02 03 06
recv: 0x1b
recv: 0x01
recv: 0x00
recv: 0x01
recv: 0x00
recv: 0x00
recv: 0x00
recv: 0x0e
sDATA: reading 1 bytes
read:  a0
recv: 0xcf
recv: 0xa2
CRC OK
Got message seqno 1 (command_sequence == 1)
response: A0

command[0x02, 2]: 02 03 06
recv: 0x1b
recv: 0x02
recv: 0x00
recv: 0x01
recv: 0x00
recv: 0x00
recv: 0x00
recv: 0x0e
sDATA: reading 1 bytes
read:  a0
recv: 0x1f
recv: 0x28
CRC OK
Got message seqno 2 (command_sequence == 2)
response: A0

command[0x02, 3]: 02 03 06
recv: 0x1b
recv: 0x03
recv: 0x00
recv: 0x01
recv: 0x00
recv: 0x00
recv: 0x00
recv: 0x0e
sDATA: reading 1 bytes
read:  a0
recv: 0xa0
recv: 0xa9
CRC OK
Got message seqno 3 (command_sequence == 3)
response: A0

command[0x02, 4]: 02 03 06
recv: 0x1b
recv: 0x04
recv: 0x00
recv: 0x01
recv: 0x00
recv: 0x00
recv: 0x00
recv: 0x0e
sDATA: reading 1 bytes
read:  a0
recv: 0xae
recv: 0x35
CRC OK
Got message seqno 4 (command_sequence == 4)
response: A0

command[0x02, 5]: 02 03 06
recv: 0x1b
recv: 0x05
recv: 0x00
recv: 0x01
recv: 0x00
recv: 0x00
recv: 0x00
recv: 0x0e
sDATA: reading 1 bytes
read:  a0
recv: 0x11
recv: 0xb4
CRC OK
Got message seqno 5 (command_sequence == 5)
response: A0

command[0x02, 6]: 02 03 06
recv: 0x1b
recv: 0x06
recv: 0x00
recv: 0x01
recv: 0x00
recv: 0x00
recv: 0x00
recv: 0x0e
sDATA: reading 1 bytes
read:  a0
recv: 0xc1
recv: 0x3e
CRC OK
Got message seqno 6 (command_sequence == 6)
response: A0

command[0x02, 7]: 02 03 06
recv: 0x1b
recv: 0x07
recv: 0x00
recv: 0x01
recv: 0x00
recv: 0x00
recv: 0x00
recv: 0x0e
sDATA: reading 1 bytes
read:  a0
recv: 0x7e
recv: 0xbf
CRC OK
Got message seqno 7 (command_sequence == 7)
response: A0

command[0x02, 8]: 02 03 06
recv: 0x1b
recv: 0x08
recv: 0x00
recv: 0x01
recv: 0x00
recv: 0x00
recv: 0x00
recv: 0x0e
sDATA: reading 1 bytes
read:  a0
recv: 0xcc
recv: 0x0e
CRC OK
Got message seqno 8 (command_sequence == 8)
response: A0

command[0x02, 9]: 02 03 06
recv: 0x1b
recv: 0x09
recv: 0x00
recv: 0x01
recv: 0x00
recv: 0x00
recv: 0x00
recv: 0x0e
sDATA: reading 1 bytes
read:  a0
recv: 0x73
recv: 0x8f
CRC OK
Got message seqno 9 (command_sequence == 9)
response: A0

command[0x02, 10]: 02 03 06
recv: 0x1b
recv: 0x0a
recv: 0x00
recv: 0x01
recv: 0x00
recv: 0x00
recv: 0x00
recv: 0x0e
sDATA: reading 1 bytes
read:  a0
recv: 0xa3
recv: 0x05
CRC OK
Got message seqno 10 (command_sequence == 10)
response: A0
AVaRICE version 2.12, Dec 12 2011 15:48:09

JTAG config starting.
Found a device: JTAGICEmkII
Serial number:  00:b0:00:00:24:b9
JTAG ICE: Cannot synchronise
AVaRICE version 2.12, Dec 12 2011 15:48:09


-------------------------------------

Re: [AVaRICE-user] JTAG ICE: Cannot synchronise

[Joerg W. <j...@ur...>]

As Philip Mulrane wrote:

> avarice -x -2 -j usb -P atxmega128a1 -e -p -f

Programming through AVaRICE command-line options is deprecated
(use AVRDUDE for this), and no longer maintained.

> command[0x13, 1]: 13
> recv: 0x1b
> recv: 0x06
> recv: 0x00
> recv: 0x01
> recv: 0x00
> recv: 0x00
> recv: 0x00
> recv: 0x0e
> sDATA: reading 1 bytes
> read:  aa
> recv: 0x9b
> recv: 0x91
> CRC OK
> Got message seqno 6 (command_sequence == 6)
> response: AA

Command 0x13 is a chip erase (your -e option), and response
0xaa is "Illegal command".  Offhand, I've got no idea why
PDI won't be willing to chip erase, but simply drop it.
Program using AVRDUDE, and/or update the flash using GDB's
"load" command.
-- 
cheers, Joerg               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/
Never trust an operating system you don't have sources for. ;-)

[AVaRICE-user] JTAG ICE: Cannot synchronise

[Philip M. <in...@bi...>]

Hi,
I am trying to move from ATMega to xMega, and I am working with an 
XMega-A1 Xplained board and a JtagICE MkII (firmware 7.36) . I am using 
it under Win7 64bit (8Gb i5-2520 @ 2.5Ghz).
What works:
debugging with gdb using Jtag.
What does not work:
debugging with gdb using PDI.
programming the flash memory from a hex file (AvrDude work OK for this).

I get a 'Cannot synchronise' message in both cases, I have attached a 
dump of a '-d' run of avarice trying to program the flash memory:
avarice -x -2 -j usb -P atxmega128a1 -e -p -f 
/Projects/XMega/test/Debug/test.hex
I have tried various options, no change in the behavior. Anyone got an 
idea what is going wrong?
Br,
Philip
---------------------------------------------------------------------------------------------------------
Found JTAG ICE, serno: 00B0000024B9
Attempting synchronisation at bitrate 19200

command[0x01, 1]: 01
recv: 0x1b
recv: 0x00
recv: 0x00
recv: 0x1c
recv: 0x00
recv: 0x00
recv: 0x00
recv: 0x0e
sDATA: reading 28 bytes
read:  86 01 ff 24 07 00 ff 24 07 01 00 b0 00 00 24 b9 4a 54 41 47 49 43 
45 6d 6b 49 49 00
recv: 0x9a
recv: 0x30
CRC OK
Got message seqno 0 (command_sequence == 0)
response: 86 01 FF 24 07 00 FF 24 07 01 00 B0 00 00 24 B9 4A 54 41 47 49 
43 45 6D 6B 49 49 00
JTAG ICE mkII sign-on message:
Communications protocol version: 1
M_MCU:
   boot-loader FW version:        255
   firmware version:              7.36
   hardware version:              0
S_MCU:
   boot-loader FW version:        255
   firmware version:              7.36
   hardware version:              1

command[0x02, 1]: 02 03 05
recv: 0x1b
recv: 0x01
recv: 0x00
recv: 0x01
recv: 0x00
recv: 0x00
recv: 0x00
recv: 0x0e
sDATA: reading 1 bytes
read:  80
recv: 0xcd
recv: 0x83
CRC OK
Got message seqno 1 (command_sequence == 1)
response: 80

command[0x0a, 1]: 0A 01
recv: 0x1b
recv: 0x02
recv: 0x00
recv: 0x01
recv: 0x00
recv: 0x00
recv: 0x00
recv: 0x0e
sDATA: reading 1 bytes
read:  80
recv: 0x1d
recv: 0x09
CRC OK
Got message seqno 2 (command_sequence == 2)
response: 80
recv: 0x1b
recv: 0xff
recv: 0xff
recv: 0x08
recv: 0x00
recv: 0x00
recv: 0x00
recv: 0x0e
sDATA: reading 8 bytes
read:  e0 00 00 01 00 40 00 00
recv: 0x25
recv: 0x1b
CRC OKAutomatic device detection:
command[0x03, 1]: 03 0E
recv: 0x1b
recv: 0x03
recv: 0x00
recv: 0x05
recv: 0x00
recv: 0x00
recv: 0x00
recv: 0x0e
sDATA: reading 5 bytes
read:  81 3f c0 74 79
recv: 0xce
recv: 0x67
CRC OK
Got message seqno 3 (command_sequence == 3)
response: 81 3F C0 74 79
JTAG id = 0x7974C03F : Ver = 0x7 : Device = 0x974c : Manuf = 0x1f
Looking for device: atxmega128a1

command[0x36, 1]: 36 02 00 2F 00 00 80 00 00 00 82 00 00 00 8C 00 20 00 
8F 00 27 00 8F 00 00 04 8E 00 00 02 8E 00 00 00 00 01 00 00 02 00 00 20 
00 02 00 08 20 C0 01 90 00
recv: 0x1b
recv: 0x04
recv: 0x00
recv: 0x01
recv: 0x00
recv: 0x00
recv: 0x00
recv: 0x0e
sDATA: reading 1 bytes
read:  80
recv: 0xac
recv: 0x14
CRC OK
Got message seqno 4 (command_sequence == 4)
response: 80

command[0x14, 1]: 14
recv: 0x1b
recv: 0x05
recv: 0x00
recv: 0x01
recv: 0x00
recv: 0x00
recv: 0x00
recv: 0x0e
sDATA: reading 1 bytes
read:  80
recv: 0x13
recv: 0x95
CRC OK
Got message seqno 5 (command_sequence == 5)
response: 80

command[0x13, 1]: 13
recv: 0x1b
recv: 0x06
recv: 0x00
recv: 0x01
recv: 0x00
recv: 0x00
recv: 0x00
recv: 0x0e
sDATA: reading 1 bytes
read:  aa
recv: 0x9b
recv: 0x91
CRC OK
Got message seqno 6 (command_sequence == 6)
response: AA

command[0x13, 2]: 13
recv: 0x1b
recv: 0x07
recv: 0x00
recv: 0x01
recv: 0x00
recv: 0x00
recv: 0x00
recv: 0x0e
sDATA: reading 1 bytes
read:  aa
recv: 0x24
recv: 0x10
CRC OK
Got message seqno 7 (command_sequence == 7)
response: AA

command[0x13, 3]: 13
recv: 0x1b
recv: 0x08
recv: 0x00
recv: 0x01
recv: 0x00
recv: 0x00
recv: 0x00
recv: 0x0e
sDATA: reading 1 bytes
read:  aa
recv: 0x96
recv: 0xa1
CRC OK
Got message seqno 8 (command_sequence == 8)
response: AA

command[0x13, 4]: 13
recv: 0x1b
recv: 0x09
recv: 0x00
recv: 0x01
recv: 0x00
recv: 0x00
recv: 0x00
recv: 0x0e
sDATA: reading 1 bytes
read:  aa
recv: 0x29
recv: 0x20
CRC OK
Got message seqno 9 (command_sequence == 9)
response: AA

command[0x13, 5]: 13
recv: 0x1b
recv: 0x0a
recv: 0x00
recv: 0x01
recv: 0x00
recv: 0x00
recv: 0x00
recv: 0x0e
sDATA: reading 1 bytes
read:  aa
recv: 0xf9
recv: 0xaa
CRC OK
Got message seqno 10 (command_sequence == 10)
response: AA

command[0x13, 6]: 13
recv: 0x1b
recv: 0x0b
recv: 0x00
recv: 0x01
recv: 0x00
recv: 0x00
recv: 0x00
recv: 0x0e
sDATA: reading 1 bytes
read:  aa
recv: 0x46
recv: 0x2b
CRC OK
Got message seqno 11 (command_sequence == 11)
response: AA

command[0x13, 7]: 13
recv: 0x1b
recv: 0x0c
recv: 0x00
recv: 0x01
recv: 0x00
recv: 0x00
recv: 0x00
recv: 0x0e
sDATA: reading 1 bytes
read:  aa
recv: 0x48
recv: 0xb7
CRC OK
Got message seqno 12 (command_sequence == 12)
response: AA

command[0x13, 8]: 13
recv: 0x1b
recv: 0x0d
recv: 0x00
recv: 0x01
recv: 0x00
recv: 0x00
recv: 0x00
recv: 0x0e
sDATA: reading 1 bytes
read:  aa
recv: 0xf7
recv: 0x36
CRC OK
Got message seqno 13 (command_sequence == 13)
response: AA

command[0x13, 9]: 13
recv: 0x1b
recv: 0x0e
recv: 0x00
recv: 0x01
recv: 0x00
recv: 0x00
recv: 0x00
recv: 0x0e
sDATA: reading 1 bytes
read:  aa
recv: 0x27
recv: 0xbc
CRC OK
Got message seqno 14 (command_sequence == 14)
response: AA

command[0x13, 10]: 13
recv: 0x1b
recv: 0x0f
recv: 0x00
recv: 0x01
recv: 0x00
recv: 0x00
recv: 0x00
recv: 0x0e
sDATA: reading 1 bytes
read:  aa
recv: 0x98
recv: 0x3d
CRC OK
Got message seqno 15 (command_sequence == 15)
response: AA
AVaRICE version 2.12, Dec 12 2011 15:48:09

Defaulting JTAG bitrate to 250 kHz.

JTAG config starting.
Found a device: JTAGICEmkII
Serial number:  00:b0:00:00:24:b9
Reported JTAG device ID: 0x974C
Configured for device ID: 0x974C atxmega128a1 -- Matched with atxmega128a1
JTAG config complete.
Erasing program memory.
JTAG ICE: Cannot synchronise
AVaRICE version 2.12, Dec 12 2011 15:48:09

Defaulting JTAG bitrate to 250 kHz.

---------------------------------------------------------------------------------------------------------

[AVaRICE-user] Debugging 4-Page Erase Devices (tiny1634, tiny841, tiny441)

[Armin O. <arm...@gm...>]

Hi there,

I was wondering if anybody succeeded yet in debugging an AVR-Device which
has the 4-Page Erase behavior?
I tried to extend the devdescr.cc to the best of my knowledge but somehow
the debugging doesn't work. I didn't have enough time to investigate the
debug-output yet. So instead of reinventing the wheel I thought I first ask
if somebody already worked this out?

>From the Atmel xml files there is a new parameter in the OCD section:
<property name="BUFFERS_PER_FLASH_PAGE" value="4"/>
Since it is in the OCD section I think it is necessary for the Debugger to
know. Which also makes sense since with debugging through debugWire
essentially the flash gets reprogrammed. For that not only one buffer but
all 4 have to be written back. I would assume that the (in my case) AVR
Dragon handles this but for that it at least needs to know about it
somehow. And I don't think its a Device ID filter in the Dragon-Firmware as
this would have to be upgraded with each new Device? So maybe some
additional Command that has to be send from avarice?

Anyways tomorrow I'll try to update my Dragon maybe that helps, since it
has a rather old Version (6.11).

Regards,
Armin

PS.: I'm new to this mailing list so please forgive if the request/content
is not in the right place/format.