Menu
▾
▴
avarice-user — AVaRICE Users
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(11) |
Dec
(11) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(5) |
Feb
(3) |
Mar
(3) |
Apr
(9) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2003 |
Jan
|
Feb
(11) |
Mar
(29) |
Apr
(27) |
May
(21) |
Jun
(24) |
Jul
(18) |
Aug
(30) |
Sep
(8) |
Oct
(15) |
Nov
(33) |
Dec
(15) |
| 2004 |
Jan
(14) |
Feb
(29) |
Mar
(16) |
Apr
(2) |
May
(8) |
Jun
(3) |
Jul
(1) |
Aug
(29) |
Sep
(16) |
Oct
(8) |
Nov
(53) |
Dec
(47) |
| 2005 |
Jan
(70) |
Feb
(15) |
Mar
(5) |
Apr
(44) |
May
(17) |
Jun
(12) |
Jul
(8) |
Aug
(15) |
Sep
(11) |
Oct
(9) |
Nov
(6) |
Dec
(4) |
| 2006 |
Jan
(6) |
Feb
(20) |
Mar
(5) |
Apr
(35) |
May
|
Jun
(17) |
Jul
(5) |
Aug
(9) |
Sep
(9) |
Oct
(11) |
Nov
(13) |
Dec
(2) |
| 2007 |
Jan
|
Feb
(3) |
Mar
(9) |
Apr
(7) |
May
(9) |
Jun
(7) |
Jul
(15) |
Aug
|
Sep
|
Oct
(1) |
Nov
(4) |
Dec
(5) |
| 2008 |
Jan
(58) |
Feb
(25) |
Mar
(18) |
Apr
(38) |
May
(24) |
Jun
(6) |
Jul
(3) |
Aug
|
Sep
(5) |
Oct
(5) |
Nov
(2) |
Dec
(2) |
| 2009 |
Jan
(2) |
Feb
|
Mar
(1) |
Apr
(6) |
May
|
Jun
(4) |
Jul
(5) |
Aug
(21) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2010 |
Jan
(4) |
Feb
|
Mar
|
Apr
(3) |
May
(3) |
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
(2) |
Nov
(2) |
Dec
(3) |
| 2011 |
Jan
|
Feb
(1) |
Mar
(11) |
Apr
(5) |
May
(2) |
Jun
|
Jul
|
Aug
(12) |
Sep
(11) |
Oct
|
Nov
(1) |
Dec
(13) |
| 2012 |
Jan
(5) |
Feb
(6) |
Mar
(9) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(7) |
Sep
(2) |
Oct
(4) |
Nov
(33) |
Dec
(2) |
| 2013 |
Jan
(35) |
Feb
(3) |
Mar
(5) |
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
| 2014 |
Jan
(6) |
Feb
(10) |
Mar
(10) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
(11) |
Nov
|
Dec
(9) |
| 2015 |
Jan
(1) |
Feb
(6) |
Mar
(1) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(8) |
Oct
(12) |
Nov
(1) |
Dec
|
| 2016 |
Jan
|
Feb
(2) |
Mar
(31) |
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
(6) |
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
(4) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(6) |
Aug
|
Sep
(3) |
Oct
(1) |
Nov
|
Dec
(4) |
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
|
Dec
(1) |
| 2022 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Jessica C. <je...@fe...> - 2015-10-31 20:31:42
|
Has there been any work recently to support EDBG? It's rather annoying not being able to debug using my Atmel-ICE on Linux. -- Jessica Creighton je...@fe... |
|
From: Jörg W. <j...@ur...> - 2015-10-22 06:52:07
|
Am 21. Oktober 2015 21:52:39 MESZ, schrieb "Jörg Wunsch" <j...@ur...>: >You could try fiddling a custom cable with serial terminators (about >100 ohms) on each driving (tx) side of a line (TDO, TCK, TDI) to reduce >ringing. Sorrry, that was related to JTAG which has dedicated signal lines. PDI uses the data line bidirectionally, so it is difficult to terminate at the tx side. Maybe it already helps to insert the resistor into the PDCLK line. -- Viele Grüße, Jörg |
|
From: Jörg W. <j...@ur...> - 2015-10-21 19:53:15
|
Am 21. Oktober 2015 02:08:01 MESZ, schrieb Element Green <el...@el...>: >I'm thinking of looking into a different programmer. This one seems >too >problematic. The Dragon works,but its drivers are not very strong. You could try fiddling a custom cable with serial terminators (about 100 ohms) on each driving (tx) side of a line (TDO, TCK, TDI) to reduce ringing. > Not a lot of options though it seems for debugging over >PDI >in Linux. Apart from the older JTAGICEmkII, right now, that would only be the JTAGICE3 running the older (non-HID) firmware version. It ought to be possible to also get the newer HID firmware working (and thus also support the much cheaper Atmel-ICE, its bare PCB is even cheaper than the Dragon), but I didn't find the time and energy doing so, and obviously, there's noone else who would start that project. -- Viele Grüße, Jörg |
|
From: Element G. <el...@el...> - 2015-10-21 00:08:28
|
Thank you for the info. I just tried it again with avrdude with the short 2" cable and the xmega128d4 development board and it managed to get pretty far in the programming process (unlike before), but failed on data verification. It still completely fails to even start with my development board with the same 0xAE error code as avarice. I'm thinking of looking into a different programmer. This one seems too problematic. Not a lot of options though it seems for debugging over PDI in Linux. I was mistaken in my previous email when I mentioned that a debugger could be found for $43 online, seems its more like $127 for ones which have debugging capability (several of the MKII clones look identical but have different capabilities apparently). Best regards, Element Green On Tue, Oct 20, 2015 at 5:44 PM, Arnim Littek <li...@si...> wrote: > FWIW, I’m operating a Dragon to an ATxmega128a4u over ca. 40mm of ribbon > cable reliably. You also have a speed setting in avrdude to fiddle with. > Mine is running at > > /usr/bin/avrdude -B 2.0 -p atxmega128a4u -P usb -c dragon_pdi.... > > but that can be slowed down in problematic cases. > > > > Arnim > > > > > > *From:* Element Green [mailto:el...@el...] > *Sent:* Wednesday, 21 October 2015 12:40 p.m. > *To:* Joerg Wunsch; > *Subject:* Re: [AVaRICE-user] AVR Dragon not working with atxmega16d4 > > > > Hello Joerg, > > > > On Tue, Oct 20, 2015 at 9:49 AM, Element Green < > el...@el...> wrote: > > > How long's your cable? The levelshifters/drivers on the Dragon are > known to be fairly weak. In general, the cables that come with an STK500 > work well, they are about 15 cm long. Anything longer might cause > troubles. > > > > > > I had that thought as well about the cable length after reading something > to that effect on a forum post. My guess is that that is the issue now > that you mention it again, though I got sidetracked by the thought that it > was a version incompatibility. The cable I have came with a ZeptoProg II > programmer and is probably about 10 inches long. I'll get some shorter > ones and see if that makes a difference. Perhaps the 0xAE code can be used > to identify cable length issues. Guess I will see. > > > > > > > > So I shortened the cable by removing the connector, cut it to about 4 > inches and then put the connector back on. It still was getting the same > error code with my custom PCB, but it goes through a motherboard > interconnect plus a few extra inches. So I then tried it on the little > development board I have and it came back with a device ID which is > currently unsupported (the xmega128d4) which it was not doing with a longer > cable. So it seems like it would likely work if the interconnect was not > there. I cut the cable to 2 inches and still same 0xAE error code. > > > > I'm thinking of getting an MKII clone like this one since they seem to be > available for under $43 online: > > http://www.wvshare.com/product/USB-AVR-JTAGICE-XPII.htm > > > > Any idea if those will work OK with debugging or if it might work better > than the Dragon in regards to cable length? Guess the easiest thing to do > is just try it. > > > > > > > > -- > cheers, Joerg .-.-. --... ...-- -.. . DL8DTL > > > > > > > > Cheers. > > > > Element > > > |
|
From: Arnim L. <li...@si...> - 2015-10-20 23:56:57
|
FWIW, I’m operating a Dragon to an ATxmega128a4u over ca. 40mm of ribbon cable reliably. You also have a speed setting in avrdude to fiddle with. Mine is running at /usr/bin/avrdude -B 2.0 -p atxmega128a4u -P usb -c dragon_pdi.... but that can be slowed down in problematic cases. Arnim From: Element Green [mailto:el...@el...] Sent: Wednesday, 21 October 2015 12:40 p.m. To: Joerg Wunsch; Subject: Re: [AVaRICE-user] AVR Dragon not working with atxmega16d4 Hello Joerg, On Tue, Oct 20, 2015 at 9:49 AM, Element Green <el...@el...<mailto:el...@el...>> wrote: How long's your cable? The levelshifters/drivers on the Dragon are known to be fairly weak. In general, the cables that come with an STK500 work well, they are about 15 cm long. Anything longer might cause troubles. I had that thought as well about the cable length after reading something to that effect on a forum post. My guess is that that is the issue now that you mention it again, though I got sidetracked by the thought that it was a version incompatibility. The cable I have came with a ZeptoProg II programmer and is probably about 10 inches long. I'll get some shorter ones and see if that makes a difference. Perhaps the 0xAE code can be used to identify cable length issues. Guess I will see. So I shortened the cable by removing the connector, cut it to about 4 inches and then put the connector back on. It still was getting the same error code with my custom PCB, but it goes through a motherboard interconnect plus a few extra inches. So I then tried it on the little development board I have and it came back with a device ID which is currently unsupported (the xmega128d4) which it was not doing with a longer cable. So it seems like it would likely work if the interconnect was not there. I cut the cable to 2 inches and still same 0xAE error code. I'm thinking of getting an MKII clone like this one since they seem to be available for under $43 online: http://www.wvshare.com/product/USB-AVR-JTAGICE-XPII.htm Any idea if those will work OK with debugging or if it might work better than the Dragon in regards to cable length? Guess the easiest thing to do is just try it. -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL Cheers. Element |
|
From: Element G. <el...@el...> - 2015-10-20 23:39:26
|
Hello Joerg, On Tue, Oct 20, 2015 at 9:49 AM, Element Green <el...@el...> wrote: > >> How long's your cable? The levelshifters/drivers on the Dragon are >> known to be fairly weak. In general, the cables that come with an STK500 >> work well, they are about 15 cm long. Anything longer might cause >> troubles. >> > > > I had that thought as well about the cable length after reading something > to that effect on a forum post. My guess is that that is the issue now > that you mention it again, though I got sidetracked by the thought that it > was a version incompatibility. The cable I have came with a ZeptoProg II > programmer and is probably about 10 inches long. I'll get some shorter > ones and see if that makes a difference. Perhaps the 0xAE code can be used > to identify cable length issues. Guess I will see. > > So I shortened the cable by removing the connector, cut it to about 4 inches and then put the connector back on. It still was getting the same error code with my custom PCB, but it goes through a motherboard interconnect plus a few extra inches. So I then tried it on the little development board I have and it came back with a device ID which is currently unsupported (the xmega128d4) which it was not doing with a longer cable. So it seems like it would likely work if the interconnect was not there. I cut the cable to 2 inches and still same 0xAE error code. I'm thinking of getting an MKII clone like this one since they seem to be available for under $43 online: http://www.wvshare.com/product/USB-AVR-JTAGICE-XPII.htm Any idea if those will work OK with debugging or if it might work better than the Dragon in regards to cable length? Guess the easiest thing to do is just try it. > > >> -- >> cheers, Joerg .-.-. --... ...-- -.. . DL8DTL >> >> > Cheers. Element |
|
From: Element G. <el...@el...> - 2015-10-20 15:49:33
|
Hello Joerg, On Tue, Oct 20, 2015 at 9:35 AM, Joerg Wunsch <j...@ur...> wrote: > As Element Green wrote: > > > Thank you for your reply. I downgraded the firmware to 7.21 (from AVR > > Studio 5). > > I just upgraded another Dragon to 7.38 (decimal), and it works without > troubles using AVaRICE (SVN version) on my ATxmega16D4 board. > > Good to hear that it's not related to the version. > > I attempted to use the Dragon to connect to 2 different XMEGA devices, > one > > is a custom PCB I made with an xmega16d4, the other is a development > board > > with an xmega128d4 using AVR Studio 7 in programming mode. It could read > > the reference voltage but not the device ID. > > That somehow smells like connection issues on the PDI level. > > The target voltage is sensed on the Dragon itself, without the need > for a working PDI link. This error code 0xAE is likely an indication > for PDI link issues - but still, you might ask Atmel explicitly about > that. While the JTAGICEmkII protocol is officially documented in an > appnote, the Xmega protocol isn't. > > How long's your cable? The levelshifters/drivers on the Dragon are > known to be fairly weak. In general, the cables that come with an STK500 > work well, they are about 15 cm long. Anything longer might cause > troubles. > I had that thought as well about the cable length after reading something to that effect on a forum post. My guess is that that is the issue now that you mention it again, though I got sidetracked by the thought that it was a version incompatibility. The cable I have came with a ZeptoProg II programmer and is probably about 10 inches long. I'll get some shorter ones and see if that makes a difference. Perhaps the 0xAE code can be used to identify cable length issues. Guess I will see. > -- > cheers, Joerg .-.-. --... ...-- -.. . DL8DTL > > Cheers! Element Green |
|
From: Joerg W. <j...@ur...> - 2015-10-20 15:35:38
|
As Element Green wrote: > Thank you for your reply. I downgraded the firmware to 7.21 (from AVR > Studio 5). I just upgraded another Dragon to 7.38 (decimal), and it works without troubles using AVaRICE (SVN version) on my ATxmega16D4 board. > I attempted to use the Dragon to connect to 2 different XMEGA devices, one > is a custom PCB I made with an xmega16d4, the other is a development board > with an xmega128d4 using AVR Studio 7 in programming mode. It could read > the reference voltage but not the device ID. That somehow smells like connection issues on the PDI level. The target voltage is sensed on the Dragon itself, without the need for a working PDI link. This error code 0xAE is likely an indication for PDI link issues - but still, you might ask Atmel explicitly about that. While the JTAGICEmkII protocol is officially documented in an appnote, the Xmega protocol isn't. How long's your cable? The levelshifters/drivers on the Dragon are known to be fairly weak. In general, the cables that come with an STK500 work well, they are about 15 cm long. Anything longer might cause troubles. -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) |
|
From: Element G. <el...@el...> - 2015-10-19 23:17:38
|
Hello Joerg, Thank you for your reply. I downgraded the firmware to 7.21 (from AVR Studio 5). It performed differently in that it got receive timeouts when attempting additional commands. I'll spare you the likely useless dumps of debug data that accompanied these tests. Even with this firmware version though, it would still get a return code of 0xAE in certain situations, so at least far back as 7.21 this error code exists. Your output shows 7.24, so.. Hmm. I attempted to use the Dragon to connect to 2 different XMEGA devices, one is a custom PCB I made with an xmega16d4, the other is a development board with an xmega128d4 using AVR Studio 7 in programming mode. It could read the reference voltage but not the device ID. So I think something is wrong with the interface or I don't know what I'm doing (or both). I'm giving up for now and will have to proceed with the painful process of debugging my code without a real debugger (GPIO ports and a scope). Both of these boards program fine with AVRDUDE and a ZeptoProg II, so the physical interface should work at least. My impression is, that if you can program with the PDI interface, then you should be able to debug with it too right? At least as far as the physical interface goes. Or perhaps there is something I should pay attention to in the design of my PCB circuit? For reference, I tried programming the device with AVR dude and it also returned the same 0xAE error code with the AVR Dragon. As I said though, works fine with the ZeptoProg II. Thanks again and cheers! Element Green On Mon, Oct 19, 2015 at 3:33 PM, Joerg Wunsch <j...@ur...> wrote: > > response: AE > > set paramater command failed: Unknwon response code 0xae > > Failed to activate PDI debugging protocol > > That (sadly) probably means they have broke^H^H^H^H^Hchanged the > protocol with their new firmware version. As an indication, error > codes known to me (for the JTAGICEmkII/Dragon protocol) go to 0xAD > by now, so it appears they have added a new code here. > > You might try requesting some explanation from Atmel by opening a case > on their support web site, albeit I'm not very enthuasiastic about the > success of such an inquiry. > > Next step would be to reverse-engineer how Atmel Studio is handling > this situation, sigh. :( > > Here's the transcript from my older Dragon firmware (note that Atmel > usually writes firmware versions in Hex, while AVRDUDE and AVaRICE > in Decimal): > > % ./src/avarice -g -j usb -X -d > AVaRICE version 2.13svn20141210, Jul 13 2015 21:28:57 > > Found JTAG ICE, serno: 00A200007BFE > JTAG config starting. > Attempting synchronisation at bitrate 19200 > > command[0x01, 1]: 01 > recv: 0x1b > recv: 0x00 > recv: 0x00 > recv: 0x1a > recv: 0x00 > recv: 0x00 > recv: 0x00 > recv: 0x0e > sDATA: reading 26 bytes > read: 86 01 ff 18 07 01 ff 18 07 07 00 a2 00 00 7b fe 41 56 52 44 52 41 > 47 4f 4e 00 > recv: 0xfb > recv: 0x39 > CRC OK > Got message seqno 0 (command_sequence == 0) > response: 86 01 FF 18 07 01 FF 18 07 07 00 A2 00 00 7B FE 41 56 52 44 52 > 41 47 4F 4E 00 > Found a device: AVRDRAGON > Serial number: 00:a2:00:00:7b:fe > JTAG ICE mkII sign-on message: > Communications protocol version: 1 > M_MCU: > boot-loader FW version: 255 > firmware version: 7.24 > hardware version: 1 > S_MCU: > boot-loader FW version: 255 > firmware version: 7.24 > hardware version: 7 > > 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: 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 ff ff 00 00 40 00 00 > recv: 0xee > recv: 0x63 > CRC OKAutomatic device detection: jtagRead > command[0x14, 1]: 14 > recv: 0x1b > recv: 0x03 > recv: 0x00 > recv: 0x01 > recv: 0x00 > recv: 0x00 > recv: 0x00 > recv: 0x0e > sDATA: reading 1 bytes > read: 80 > recv: 0xa2 > recv: 0x88 > CRC OK > Got message seqno 3 (command_sequence == 3) > response: 80 > > command[0x05, 1]: 05 B4 03 00 00 00 00 00 00 00 > recv: 0x1b > recv: 0x04 > recv: 0x00 > recv: 0x04 > recv: 0x00 > recv: 0x00 > recv: 0x00 > recv: 0x0e > sDATA: reading 4 bytes > read: 82 1e 94 42 > recv: 0x4e > recv: 0x99 > CRC OK > Got message seqno 4 (command_sequence == 4) > response: 82 1E 94 42 > > command[0x15, 1]: 15 > 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 > Reported PDI device ID: 0x9442 > Configured for device ID: 0x9442 atxmega16d4 > > command[0x36, 1]: 36 02 00 2F 00 00 80 00 00 40 80 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 40 00 00 00 10 00 01 > 00 04 20 C0 01 90 00 > recv: 0x1b > recv: 0x06 > recv: 0x00 > recv: 0x01 > recv: 0x00 > recv: 0x00 > recv: 0x00 > recv: 0x0e > sDATA: reading 1 bytes > read: 80 > recv: 0xc3 > recv: 0x1f > CRC OK > Got message seqno 6 (command_sequence == 6) > response: 80 > JTAG config complete. > > command[0x37, 1]: 37 00 00 00 00 00 00 00 00 00 00 00 00 00 > recv: 0x1b > recv: 0x07 > recv: 0x00 > recv: 0x01 > recv: 0x00 > recv: 0x00 > recv: 0x00 > recv: 0x0e > sDATA: reading 1 bytes > read: 80 > recv: 0x7c > recv: 0x9e > CRC OK > Got message seqno 7 (command_sequence == 7) > response: 80 > > command[0x08, 1]: 08 > recv: 0x1b > recv: 0x08 > recv: 0x00 > recv: 0x01 > recv: 0x00 > recv: 0x00 > recv: 0x00 > recv: 0x0e > sDATA: reading 1 bytes > read: 80 > recv: 0xce > recv: 0x2f > CRC OK > Got message seqno 8 (command_sequence == 8) > response: 80 > > command[0x23, 1]: 23 > recv: 0x1b > recv: 0x09 > recv: 0x00 > recv: 0x01 > recv: 0x00 > recv: 0x00 > recv: 0x00 > recv: 0x0e > sDATA: reading 1 bytes > read: 80 > recv: 0x71 > recv: 0xae > CRC OK > Got message seqno 9 (command_sequence == 9) > response: 80 > > command[0x00, 1]: 00 > recv: 0x1b > recv: 0x0a > recv: 0x00 > recv: 0x01 > recv: 0x00 > recv: 0x00 > recv: 0x00 > recv: 0x0e > sDATA: reading 1 bytes > read: 80 > recv: 0xa1 > recv: 0x24 > CRC OK > Got message seqno 10 (command_sequence == 10) > response: 80 > > > -- > cheers, Joerg .-.-. --... ...-- -.. . DL8DTL > > http://www.sax.de/~joerg/ > Never trust an operating system you don't have sources for. ;-) > |
|
From: Joerg W. <j...@ur...> - 2015-10-19 21:33:52
|
As Element Green 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: ae > recv: 0xb1 > recv: 0x4b > CRC OK > Got message seqno 1 (command_sequence == 1) > response: AE > set paramater command failed: Unknwon response code 0xae > Failed to activate PDI debugging protocol That (sadly) probably means they have broke^H^H^H^H^Hchanged the protocol with their new firmware version. As an indication, error codes known to me (for the JTAGICEmkII/Dragon protocol) go to 0xAD by now, so it appears they have added a new code here. You might try requesting some explanation from Atmel by opening a case on their support web site, albeit I'm not very enthuasiastic about the success of such an inquiry. Next step would be to reverse-engineer how Atmel Studio is handling this situation, sigh. :( Here's the transcript from my older Dragon firmware (note that Atmel usually writes firmware versions in Hex, while AVRDUDE and AVaRICE in Decimal): % ./src/avarice -g -j usb -X -d AVaRICE version 2.13svn20141210, Jul 13 2015 21:28:57 Found JTAG ICE, serno: 00A200007BFE JTAG config starting. Attempting synchronisation at bitrate 19200 command[0x01, 1]: 01 recv: 0x1b recv: 0x00 recv: 0x00 recv: 0x1a recv: 0x00 recv: 0x00 recv: 0x00 recv: 0x0e sDATA: reading 26 bytes read: 86 01 ff 18 07 01 ff 18 07 07 00 a2 00 00 7b fe 41 56 52 44 52 41 47 4f 4e 00 recv: 0xfb recv: 0x39 CRC OK Got message seqno 0 (command_sequence == 0) response: 86 01 FF 18 07 01 FF 18 07 07 00 A2 00 00 7B FE 41 56 52 44 52 41 47 4F 4E 00 Found a device: AVRDRAGON Serial number: 00:a2:00:00:7b:fe JTAG ICE mkII sign-on message: Communications protocol version: 1 M_MCU: boot-loader FW version: 255 firmware version: 7.24 hardware version: 1 S_MCU: boot-loader FW version: 255 firmware version: 7.24 hardware version: 7 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: 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 ff ff 00 00 40 00 00 recv: 0xee recv: 0x63 CRC OKAutomatic device detection: jtagRead command[0x14, 1]: 14 recv: 0x1b recv: 0x03 recv: 0x00 recv: 0x01 recv: 0x00 recv: 0x00 recv: 0x00 recv: 0x0e sDATA: reading 1 bytes read: 80 recv: 0xa2 recv: 0x88 CRC OK Got message seqno 3 (command_sequence == 3) response: 80 command[0x05, 1]: 05 B4 03 00 00 00 00 00 00 00 recv: 0x1b recv: 0x04 recv: 0x00 recv: 0x04 recv: 0x00 recv: 0x00 recv: 0x00 recv: 0x0e sDATA: reading 4 bytes read: 82 1e 94 42 recv: 0x4e recv: 0x99 CRC OK Got message seqno 4 (command_sequence == 4) response: 82 1E 94 42 command[0x15, 1]: 15 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 Reported PDI device ID: 0x9442 Configured for device ID: 0x9442 atxmega16d4 command[0x36, 1]: 36 02 00 2F 00 00 80 00 00 40 80 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 40 00 00 00 10 00 01 00 04 20 C0 01 90 00 recv: 0x1b recv: 0x06 recv: 0x00 recv: 0x01 recv: 0x00 recv: 0x00 recv: 0x00 recv: 0x0e sDATA: reading 1 bytes read: 80 recv: 0xc3 recv: 0x1f CRC OK Got message seqno 6 (command_sequence == 6) response: 80 JTAG config complete. command[0x37, 1]: 37 00 00 00 00 00 00 00 00 00 00 00 00 00 recv: 0x1b recv: 0x07 recv: 0x00 recv: 0x01 recv: 0x00 recv: 0x00 recv: 0x00 recv: 0x0e sDATA: reading 1 bytes read: 80 recv: 0x7c recv: 0x9e CRC OK Got message seqno 7 (command_sequence == 7) response: 80 command[0x08, 1]: 08 recv: 0x1b recv: 0x08 recv: 0x00 recv: 0x01 recv: 0x00 recv: 0x00 recv: 0x00 recv: 0x0e sDATA: reading 1 bytes read: 80 recv: 0xce recv: 0x2f CRC OK Got message seqno 8 (command_sequence == 8) response: 80 command[0x23, 1]: 23 recv: 0x1b recv: 0x09 recv: 0x00 recv: 0x01 recv: 0x00 recv: 0x00 recv: 0x00 recv: 0x0e sDATA: reading 1 bytes read: 80 recv: 0x71 recv: 0xae CRC OK Got message seqno 9 (command_sequence == 9) response: 80 command[0x00, 1]: 00 recv: 0x1b recv: 0x0a recv: 0x00 recv: 0x01 recv: 0x00 recv: 0x00 recv: 0x00 recv: 0x0e sDATA: reading 1 bytes read: 80 recv: 0xa1 recv: 0x24 CRC OK Got message seqno 10 (command_sequence == 10) response: 80 -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) |
|
From: Element G. <el...@el...> - 2015-10-19 16:51:26
|
I've added some debugging output below. For testing purposes I modified the code to ignore the unknown 0xAE return code being hopeful that it would work anyways, which it didn't. The return code 0xA4 which occurs with the next command indicates RSP_ILLEGAL_EMULATOR_MODE, so it would seem there is something wrong with assigning the PDI emulator mode. Knowing the meaning of the 0xAE return code would probably help figure out what is wrong. Could there be an incompatibility with this version of the firmware (7.39 it seems)? I may try downgrading to some older version. If anyone knows what version is a good candidate for me to try, that would be helpful. Of note is that the avarice is silent about the error occurring with the command following the emulator mode assignment. It wasn't apparent to me what was wrong (if anything) until I was stepping through the application with gdb. Best regards, Element Green On Mon, Oct 19, 2015 at 2:29 AM, Element Green <el...@el...> wrote: > Hello, > > I built AVaRICE 2.13 from source and am trying to debug an xmega16d4 using > an AVR Dragon. I first upgraded the firmware on the Dragon board to 7.23 > (I think - I'll need to double check that), using a friends Windows system. > > I'm running the command as "avarice -g -X", but it fails with the > following output: > > AVaRICE version 2.13, Oct 18 2015 20:56:43 > > JTAG config starting. > Found a device: AVRDRAGON > Serial number: 00:a2:00:06:06:5f > set paramater command failed: Unknwon response code 0xae > Failed to activate PDI debugging protocol > > It does not matter if the Dragon is connected to the target board or not, > same error. It also seems like the Dragon is power cycling when the > avarice command is executed (both LEDs go out, then the larger one comes up > Orange, then goes Red and then the smaller Green LED blinks and stays lit). > > My system is running Ubuntu 15.04. > > Thank you in advance for any help with this. I'm new to avarice, so I may > just be doing something wrong. > > Best regards, > > Element Green > AVaRICE version 2.13, Oct 18 2015 20:56:43 Found JTAG ICE, serno: 00A20006065F JTAG config starting. Attempting synchronisation at bitrate 19200 command[0x01, 1]: 01 recv: 0x1b recv: 0x00 recv: 0x00 recv: 0x1a recv: 0x00 recv: 0x00 recv: 0x00 recv: 0x0e sDATA: reading 26 bytes read: 86 01 ff 27 07 01 ff 27 07 07 00 a2 00 06 06 5f 41 56 52 44 52 41 47 4f 4e 00 recv: 0x70 recv: 0x9b CRC OK Got message seqno 0 (command_sequence == 0) response: 86 01 FF 27 07 01 FF 27 07 07 00 A2 00 06 06 5F 41 56 52 44 52 41 47 4F 4E 00 Found a device: AVRDRAGON Serial number: 00:a2:00:06:06:5f JTAG ICE mkII sign-on message: Communications protocol version: 1 M_MCU: boot-loader FW version: 255 firmware version: 7.39 hardware version: 1 S_MCU: boot-loader FW version: 255 firmware version: 7.39 hardware version: 7 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: ae recv: 0xb1 recv: 0x4b CRC OK Got message seqno 1 (command_sequence == 1) response: AE set paramater command failed: Unknwon response code 0xae Failed to activate PDI debugging protocol 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: a4 recv: 0x3b recv: 0x6e CRC OK Got message seqno 2 (command_sequence == 2) response: A4 command[0x23, 1]: 23 recv: 0x1b recv: 0x03 recv: 0x00 recv: 0x01 recv: 0x00 recv: 0x00 recv: 0x00 recv: 0x0e sDATA: reading 1 bytes read: 80 recv: 0xa2 recv: 0x88 CRC OK Got message seqno 3 (command_sequence == 3) response: 80 command[0x00, 1]: 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 |
|
From: Element G. <el...@el...> - 2015-10-19 08:29:41
|
Hello, I built AVaRICE 2.13 from source and am trying to debug an xmega16d4 using an AVR Dragon. I first upgraded the firmware on the Dragon board to 7.23 (I think - I'll need to double check that), using a friends Windows system. I'm running the command as "avarice -g -X", but it fails with the following output: AVaRICE version 2.13, Oct 18 2015 20:56:43 JTAG config starting. Found a device: AVRDRAGON Serial number: 00:a2:00:06:06:5f set paramater command failed: Unknwon response code 0xae Failed to activate PDI debugging protocol It does not matter if the Dragon is connected to the target board or not, same error. It also seems like the Dragon is power cycling when the avarice command is executed (both LEDs go out, then the larger one comes up Orange, then goes Red and then the smaller Green LED blinks and stays lit). My system is running Ubuntu 15.04. Thank you in advance for any help with this. I'm new to avarice, so I may just be doing something wrong. Best regards, Element Green |
|
From: Cristiano <cri...@ho...> - 2015-09-24 20:39:36
|
In the meantime, if you apply the latest patches to avarice and gdb (see Tickets), the performance of the mkii is pretty good (I'd say surprisingly good). Ciao, Cristiano On 09/23/2015 08:59 AM, Wiebe Cazemier wrote: > ----- Original Message ----- >> From: "Joerg Wunsch" <j...@ur...> >> To: ava...@li... >> Sent: Wednesday, 23 September, 2015 12:06:41 AM >> Subject: Re: [AVaRICE-user] Support of new Atmel-ICE and future support of JTAGICE3 >> >>> What about the Dragon? Does AVR Studio also change that firmware? >> The Dragon (or its ancestor JTAGICEmkII) are fine, but they are slower >> than the recent devices (due to less processing power inside, and due >> to a USB 1.1 connection only), and they don't offer you the upgrade >> path to ARM devices. > For what I do, I don't mind that much. My bigger concern is it's fragility. > >> Again, it's not completely out of the question to have AVaRICE talk >> to an Atmel-ICE, it's just it takes someone to implement it. I'm >> sorry, but currently it doesn't seem I'm the person who's going to >> be able to spend the time into that. > How would one go about it? Is there documentation, or another good starting point? As long as it doesn't require reverse engineering, I'd be interested in giving it a go. > > I didn't realise so much of AVR on Linux was all on one person BTW. You do deserve some thanks :) > > ------------------------------------------------------------------------------ > Monitor Your Dynamic Infrastructure at Any Scale With Datadog! > Get real-time metrics from all of your servers, apps and tools > in one place. > SourceForge users - Click here to start your Free Trial of Datadog now! > http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140 > _______________________________________________ > avarice-user mailing list > ava...@li... > https://lists.sourceforge.net/lists/listinfo/avarice-user > > |
|
From: Cristiano <cri...@ho...> - 2015-09-24 20:21:30
|
The documentation of the EDBG is here: http://www.atmel.com/webdoc/protocoldocs/index.html It also seems supported by avrdude (for programming). On 09/23/2015 08:59 AM, Wiebe Cazemier wrote: > ----- Original Message ----- >> From: "Joerg Wunsch" <j...@ur...> >> To: ava...@li... >> Sent: Wednesday, 23 September, 2015 12:06:41 AM >> Subject: Re: [AVaRICE-user] Support of new Atmel-ICE and future support of JTAGICE3 >> >>> What about the Dragon? Does AVR Studio also change that firmware? >> The Dragon (or its ancestor JTAGICEmkII) are fine, but they are slower >> than the recent devices (due to less processing power inside, and due >> to a USB 1.1 connection only), and they don't offer you the upgrade >> path to ARM devices. > For what I do, I don't mind that much. My bigger concern is it's fragility. > >> Again, it's not completely out of the question to have AVaRICE talk >> to an Atmel-ICE, it's just it takes someone to implement it. I'm >> sorry, but currently it doesn't seem I'm the person who's going to >> be able to spend the time into that. > How would one go about it? Is there documentation, or another good starting point? As long as it doesn't require reverse engineering, I'd be interested in giving it a go. > > I didn't realise so much of AVR on Linux was all on one person BTW. You do deserve some thanks :) > > ------------------------------------------------------------------------------ > Monitor Your Dynamic Infrastructure at Any Scale With Datadog! > Get real-time metrics from all of your servers, apps and tools > in one place. > SourceForge users - Click here to start your Free Trial of Datadog now! > http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140 > _______________________________________________ > avarice-user mailing list > ava...@li... > https://lists.sourceforge.net/lists/listinfo/avarice-user > > |
|
From: Wiebe C. <wi...@ha...> - 2015-09-23 06:59:12
|
----- Original Message ----- > From: "Joerg Wunsch" <j...@ur...> > To: ava...@li... > Sent: Wednesday, 23 September, 2015 12:06:41 AM > Subject: Re: [AVaRICE-user] Support of new Atmel-ICE and future support of JTAGICE3 > > > What about the Dragon? Does AVR Studio also change that firmware? > > The Dragon (or its ancestor JTAGICEmkII) are fine, but they are slower > than the recent devices (due to less processing power inside, and due > to a USB 1.1 connection only), and they don't offer you the upgrade > path to ARM devices. For what I do, I don't mind that much. My bigger concern is it's fragility. > > Again, it's not completely out of the question to have AVaRICE talk > to an Atmel-ICE, it's just it takes someone to implement it. I'm > sorry, but currently it doesn't seem I'm the person who's going to > be able to spend the time into that. How would one go about it? Is there documentation, or another good starting point? As long as it doesn't require reverse engineering, I'd be interested in giving it a go. I didn't realise so much of AVR on Linux was all on one person BTW. You do deserve some thanks :) |
|
From: Joerg W. <j...@ur...> - 2015-09-22 22:06:49
|
As Wiebe Cazemier wrote: > So if you have a JTAGICE3, is it a matter of not using it with AVR > Studio and you're fine? I don't know which kind of firmware the most recent JTAGICE3s have been shipping with. If it's still the older one (VID/PID 0x3EB/0x2110), then yes, as long as you don't allow Atmel Studio to upgrade that firmware, it will work. Should they already ship with a newer firmware (USB PID 0x2140), then you'd have to downgrade it, which gets you the difficulty about how to obtain the older firmware officially. Personally, I think the 0x2110 firmware was even better performing than the current one. The reason is that this HID cr*p triggers a lot of USB traffic that just contains nothing, whereas their previous private protocol concentrated on those things thar are important. But since Windows used to only offer HIDs a generic driver (sure, how else would your Windows sysadmin proceed if keyboard or mice drivers where asking for a vendor driver? ;-), all the (Windows) world is a "human interface" these days. :-( > What about the Dragon? Does AVR Studio also change that firmware? The Dragon (or its ancestor JTAGICEmkII) are fine, but they are slower than the recent devices (due to less processing power inside, and due to a USB 1.1 connection only), and they don't offer you the upgrade path to ARM devices. Again, it's not completely out of the question to have AVaRICE talk to an Atmel-ICE, it's just it takes someone to implement it. I'm sorry, but currently it doesn't seem I'm the person who's going to be able to spend the time into that. -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) |
|
From: Rick M. <rm...@la...> - 2015-09-22 20:22:59
|
Hey Joerg, I just wanted to say thank you for all your work on AVaRICE and AVRDUDE. It's people like you who make open source bearable, and useable on my Mac, for which I am ever grateful. Keep up the great work! And if there's a place to donate to your efforts, please let me know. -- Rick > On Sep 22, 2015, at 12:01 , Joerg Wunsch <j...@ur...> wrote: > > As Wiebe Cazemier wrote: > >> It is kind of unclear (to me) whether the new Atmel-ICE debugger >> ([2]) is supported by AvaRICE or not. > > Unfortunately not (not yet). > >> I would get a JTAGICE3 >> instead, but it's no longer available. Plus, there is some concern >> ([1]) that Atmel is going to release a firmware upgrade for the >> JTAGICE3, rendering it unusable with AvaRICE? > > Yes, that's the case. The firmware Atmel Studio pushes onto it gets > at JTAGICE3 very close to the way the Atmel-ICE works, i.e. they > changed the product ID, and implemented a completely different > protocol (based on HID - everything in Windows is a "human interface", > isn't it?). > > It's not that it's completely out of the question to implement the > stuff needed. After all, the higher-level protocol is not that much > different from what the JTAGICE3 is using. It's the low-level > transport that makes it different. > > I did implement the Atmel-ICE support in AVRDUDE, but I'm not very > happy with the way I did it. It works under FreeBSD, it mostly > works under Linux, it has a hard time working under Windows or OSX > though. The better way to do it were to base it on libhidapi (rather > than libusb), as OpenOCD does. > > My idea was to first switch AVRDUDE to make it use libhidapi, and > thus avoid doing the work twice in AVaRICE. Alas, that idea has > been sitting around in my head for one and a half year now, without > finding a sufficiently large enough timeslot to actually materialize. > -- > cheers, Joerg .-.-. --... ...-- -.. . DL8DTL > > http://www.sax.de/~joerg/ > Never trust an operating system you don't have sources for. ;-) > > ------------------------------------------------------------------------------ > _______________________________________________ > avarice-user mailing list > ava...@li... > https://lists.sourceforge.net/lists/listinfo/avarice-user -- Rick Mann rm...@la... |
|
From: Wiebe C. <wi...@ha...> - 2015-09-22 20:09:05
|
----- Original Message ----- > From: "Joerg Wunsch" <j...@ur...> > To: ava...@li... > Sent: Tuesday, 22 September, 2015 9:01:42 PM > Subject: Re: [AVaRICE-user] Support of new Atmel-ICE and future support of JTAGICE3 > > > I would get a JTAGICE3 > > instead, but it's no longer available. Plus, there is some concern > > ([1]) that Atmel is going to release a firmware upgrade for the > > JTAGICE3, rendering it unusable with AvaRICE? > > Yes, that's the case. The firmware Atmel Studio pushes onto it gets > at JTAGICE3 very close to the way the Atmel-ICE works, i.e. they > changed the product ID, and implemented a completely different > protocol (based on HID - everything in Windows is a "human interface", > isn't it?). So if you have a JTAGICE3, is it a matter of not using it with AVR Studio and you're fine? What about the Dragon? Does AVR Studio also change that firmware? |
|
From: Joerg W. <j...@ur...> - 2015-09-22 19:17:51
|
As Wiebe Cazemier wrote: > It is kind of unclear (to me) whether the new Atmel-ICE debugger > ([2]) is supported by AvaRICE or not. Unfortunately not (not yet). > I would get a JTAGICE3 > instead, but it's no longer available. Plus, there is some concern > ([1]) that Atmel is going to release a firmware upgrade for the > JTAGICE3, rendering it unusable with AvaRICE? Yes, that's the case. The firmware Atmel Studio pushes onto it gets at JTAGICE3 very close to the way the Atmel-ICE works, i.e. they changed the product ID, and implemented a completely different protocol (based on HID - everything in Windows is a "human interface", isn't it?). It's not that it's completely out of the question to implement the stuff needed. After all, the higher-level protocol is not that much different from what the JTAGICE3 is using. It's the low-level transport that makes it different. I did implement the Atmel-ICE support in AVRDUDE, but I'm not very happy with the way I did it. It works under FreeBSD, it mostly works under Linux, it has a hard time working under Windows or OSX though. The better way to do it were to base it on libhidapi (rather than libusb), as OpenOCD does. My idea was to first switch AVRDUDE to make it use libhidapi, and thus avoid doing the work twice in AVaRICE. Alas, that idea has been sitting around in my head for one and a half year now, without finding a sufficiently large enough timeslot to actually materialize. -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) |
|
From: Wiebe C. <wi...@ha...> - 2015-09-22 18:02:27
|
Hello, It is kind of unclear (to me) whether the new Atmel-ICE debugger ([2]) is supported by AvaRICE or not. I would get a JTAGICE3 instead, but it's no longer available. Plus, there is some concern ([1]) that Atmel is going to release a firmware upgrade for the JTAGICE3, rendering it unusable with AvaRICE? >From how it appears, it looks like all Linux support for debugging is or will be gone. Is that true? Regards, Wiebe [1] http://www.avrfreaks.net/comment/1667181 [2] http://www.atmel.com/tools/atatmel-ice.aspx |
|
From: Cristiano <cri...@ho...> - 2015-04-22 23:19:55
|
> On 03/31/2015 11:47 PM, Cristiano wrote: > I think I've found the issue. I have a patch that supersedes > 0004-Implement-range-stepping-GDB-7.7.patch > <http://sourceforge.net/p/avarice/patches/29/attachment/0004-Implement-range-stepping-GDB-7.7.patch> > submitted in ticket #29 Range stepping for GDB 7.7+. > > What is the best method to submit my patch? > > Regards, Cristiano Other than a patch amending the one described above I can also submit another patch implementing a new --mask-intr option. These are some comments from my sources: Mask interrupts while (range) stepping, like in AVR Studio. Note that, while running to address, interrupts may be re-enabled, for example by executing a SEI or RETI instruction. In this case the ICE would break in the vectors table so it looks a good idea to always use --ignore-intr in conjunction with this option (or maybe this option should imply --ignore-intr). Even if interrupts are not re-enabled, they can still occur during a GDB step/next command if the ICE breaks due to a normal change of program flow while running to address. When this happens, control temporarily returns to GDB which, in order to complete the step/next command, may for example set a breakpoint and continue. Interrupts will then be serviced, invisible to the user, until the device hits a breakpoint (which might not be the one just set by GDB). The same feature was implemented to single stepping where Avarice knows the instruction that was stepped allowing to "restore" the right value of the global interrupt flag. Regards, Cristiano |
|
From: Cristiano <cri...@ho...> - 2015-04-09 21:22:13
|
On 03/31/2015 11:47 PM, Cristiano wrote: > On 07/10/2014 11:05 PM, Cristiano wrote: >> Hi, I've applied the patches to the latest SVN snapshot. I use GDB >> 7.7.1. Great job! Stepping is now super fast. I'm debugging from >> Eclipse and the experience is now decent. The patch for the GDB >> disassemble is here: >> https://sourceware.org/bugzilla/show_bug.cgi?id=13519 >> >> Thanks for AVARICE and these patches. -Cristiano >> >>> Hello, >>> >>> as suggested the patches have been uploaded to the patch >>> tracker! >> > > I'm trying the debugging experience, using the above setup, on a LUFA > project. After tweaking a little bit the LUFA makefile and resorting > using the Atmel AVR toolchain v3.4.5 for Linux, I can confirm the > experience is still quite good. Stepping is fast if compared with a > vanilla Avarice but... > > Sometimes, stepping (gdb `next' or `step' commands) from the return > statement of a function ends in the __vectors jump table. Another > `next' from here stops avr-gdb in the USB ISR. > > This is somewhat surprising because I launch Avarice with the > --ignore-intr switch. Note that interrupts are usually skipped but > there are pathological case where they are not, systematically. I think I've found the issue. I have a patch that supersedes 0004-Implement-range-stepping-GDB-7.7.patch <http://sourceforge.net/p/avarice/patches/29/attachment/0004-Implement-range-stepping-GDB-7.7.patch> submitted in ticket #29 Range stepping for GDB 7.7+. What is the best method to submit my patch? Regards, Cristiano |
|
From: Cristiano <cri...@ho...> - 2015-03-31 21:48:03
|
On 07/10/2014 11:05 PM, Cristiano wrote: > Hi, I've applied the patches to the latest SVN snapshot. I use GDB > 7.7.1. Great job! Stepping is now super fast. I'm debugging from > Eclipse and the experience is now decent. The patch for the GDB > disassemble is here: > https://sourceware.org/bugzilla/show_bug.cgi?id=13519 > > Thanks for AVARICE and these patches. -Cristiano > >> Hello, >> >> as suggested the patches have been uploaded to the patch tracker! > I'm trying the debugging experience, using the above setup, on a LUFA project. After tweaking a little bit the LUFA makefile and resorting using the Atmel AVR toolchain v3.4.5 for Linux, I can confirm the experience is still quite good. Stepping is fast if compared with a vanilla Avarice but... Sometimes, stepping (gdb `next' or `step' commands) from the return statement of a function ends in the __vectors jump table. Another `next' from here stops avr-gdb in the USB ISR. This is somewhat surprising because I launch Avarice with the --ignore-intr switch. Note that interrupts are usually skipped but there are pathological case where they are not, systematically. Returning from the function, from the same return statement above, with `finish' or returning through a sequence of `nexti' or `stepi' produces the expected result, returning to the function caller. There must be something wrong with the patches or maybe this is a known issue. If I run the same debug session above using a vanilla Avarice 2.10 (Linux Mint package), with the same options, everything works as expected (if you have the patience of waiting 5-10 seconds for a step). Since these patches make a big difference in debugging (stepping is 5x faster) I'd like to help debugging this issue. Below is the disassembled function. I can provide gdb and avarice logs if needed. Regards, Cristiano CALLBACK_HID_Device_CreateHIDReport: 000004a6: push r16 000004a8: push r17 000004aa: push r28 000004ac: push r29 000004ae: in r28, 0x3d ; 61 000004b0: in r29, 0x3e ; 62 000004b2: sbiw r28, 0x0f ; 15 000004b4: in r0, 0x3f ; 63 000004b6: cli 000004b8: out 0x3e, r29 ; 62 000004ba: out 0x3f, r0 ; 63 000004bc: out 0x3d, r28 ; 61 000004be: std Y+8, r25 ; 0x08 000004c0: std Y+7, r24 ; 0x07 000004c2: std Y+10, r23 ; 0x0a 000004c4: std Y+9, r22 ; 0x09 000004c6: std Y+11, r20 ; 0x0b 000004c8: std Y+13, r19 ; 0x0d 000004ca: std Y+12, r18 ; 0x0c 000004cc: std Y+15, r17 ; 0x0f 000004ce: std Y+14, r16 ; 0x0e 167 uint8_t* Data = (uint8_t*)ReportData; 000004d0: ldd r24, Y+12 ; 0x0c 000004d2: ldd r25, Y+13 ; 0x0d 000004d4: std Y+2, r25 ; 0x02 000004d6: std Y+1, r24 ; 0x01 168 uint8_t CurrLEDMask = LEDs_GetLEDs(); 000004d8: call 0x26c ; 0x26c <LEDs_GetLEDs> 000004dc: std Y+3, r24 ; 0x03 169 hal_rx_frame_t *frame = NULL; 000004de: std Y+5, r1 ; 0x05 000004e0: std Y+4, r1 ; 0x04 171 HAL_ENTER_CRITICAL_REGION(); 000004e2: ldi r24, 0x5F ; 95 000004e4: ldi r25, 0x00 ; 0 000004e6: movw r30, r24 000004e8: ld r24, Z 000004ea: std Y+6, r24 ; 0x06 000004ec: cli 172 frame = (hal_rx_frame_t*) list_pop(hal_rx_frame_queue); 000004ee: lds r24, 0x0100 000004f2: lds r25, 0x0101 000004f6: call 0x14bc ; 0x14bc <list_pop> 000004fa: std Y+5, r25 ; 0x05 000004fc: std Y+4, r24 ; 0x04 173 HAL_LEAVE_CRITICAL_REGION(); 000004fe: ldi r24, 0x5F ; 95 00000500: ldi r25, 0x00 ; 0 00000502: ldd r18, Y+6 ; 0x06 00000504: movw r30, r24 00000506: st Z, r18 175 if (frame != NULL) { 00000508: ldd r24, Y+4 ; 0x04 0000050a: ldd r25, Y+5 ; 0x05 0000050c: sbiw r24, 0x00 ; 0 0000050e: breq .+14 ; 0x51e <CALLBACK_HID_Device_CreateHIDReport+120> 177 LEDs_ToggleLEDs(LEDS_LED4); 00000510: ldi r24, 0x04 ; 4 00000512: call 0x23c ; 0x23c <LEDs_ToggleLEDs> 178 hal_rx_frame_free(frame); 00000516: ldd r24, Y+4 ; 0x04 00000518: ldd r25, Y+5 ; 0x05 0000051a: call 0xd98 ; 0xd98 <hal_rx_frame_free> 181 if (changed) 0000051e: lds r24, 0x0122 00000522: and r24, r24 00000524: brne .+2 ; 0x528 <CALLBACK_HID_Device_CreateHIDReport+130> 00000526: rjmp .+134 ; 0x5ae <CALLBACK_HID_Device_CreateHIDReport+264> 183 changed = false; 00000528: sts 0x0122, r1 185 Data[0] = ((CurrLEDMask & LEDS_LED1) ? 1 : 0); 0000052c: ldd r24, Y+3 ; 0x03 0000052e: adc r24, r24 00000530: eor r24, r24 00000532: adc r24, r24 00000534: mov r18, r24 00000536: ldd r24, Y+1 ; 0x01 00000538: ldd r25, Y+2 ; 0x02 0000053a: movw r30, r24 0000053c: st Z, r18 186 Data[1] = ((CurrLEDMask & LEDS_LED2) ? 1 : 0); 0000053e: ldd r24, Y+1 ; 0x01 00000540: ldd r25, Y+2 ; 0x02 00000542: adiw r24, 0x01 ; 1 00000544: ldd r18, Y+3 ; 0x03 00000546: mov r18, r18 00000548: ldi r19, 0x00 ; 0 0000054a: andi r18, 0x20 ; 32 0000054c: eor r19, r19 0000054e: ldi r20, 0x01 ; 1 00000550: cp r18, r1 00000552: cpc r19, r1 00000554: brne .+2 ; 0x558 <CALLBACK_HID_Device_CreateHIDReport+178> 00000556: ldi r20, 0x00 ; 0 00000558: mov r18, r20 0000055a: movw r30, r24 0000055c: st Z, r18 187 Data[2] = ((CurrLEDMask & LEDS_LED3) ? 1 : 0); 0000055e: ldd r24, Y+1 ; 0x01 00000560: ldd r25, Y+2 ; 0x02 00000562: adiw r24, 0x02 ; 2 00000564: ldd r18, Y+3 ; 0x03 00000566: mov r18, r18 00000568: ldi r19, 0x00 ; 0 0000056a: andi r18, 0x08 ; 8 0000056c: eor r19, r19 0000056e: ldi r20, 0x01 ; 1 00000570: cp r18, r1 00000572: cpc r19, r1 00000574: brne .+2 ; 0x578 <CALLBACK_HID_Device_CreateHIDReport+210> 00000576: ldi r20, 0x00 ; 0 00000578: mov r18, r20 0000057a: movw r30, r24 0000057c: st Z, r18 188 Data[3] = ((CurrLEDMask & LEDS_LED4) ? 1 : 0); 0000057e: ldd r24, Y+1 ; 0x01 00000580: ldd r25, Y+2 ; 0x02 00000582: adiw r24, 0x03 ; 3 00000584: ldd r18, Y+3 ; 0x03 00000586: mov r18, r18 00000588: ldi r19, 0x00 ; 0 0000058a: andi r18, 0x04 ; 4 0000058c: eor r19, r19 0000058e: ldi r20, 0x01 ; 1 00000590: cp r18, r1 00000592: cpc r19, r1 00000594: brne .+2 ; 0x598 <CALLBACK_HID_Device_CreateHIDReport+242> 00000596: ldi r20, 0x00 ; 0 00000598: mov r18, r20 0000059a: movw r30, r24 0000059c: st Z, r18 190 *ReportSize = GENERIC_REPORT_SIZE; 0000059e: ldd r24, Y+14 ; 0x0e 000005a0: ldd r25, Y+15 ; 0x0f 000005a2: ldi r18, 0x08 ; 8 000005a4: ldi r19, 0x00 ; 0 000005a6: movw r30, r24 000005a8: std Z+1, r19 ; 0x01 000005aa: st Z, r18 000005ac: rjmp .+10 ; 0x5b8 <CALLBACK_HID_Device_CreateHIDReport+274> 193 *ReportSize = 0; 000005ae: ldd r24, Y+14 ; 0x0e 000005b0: ldd r25, Y+15 ; 0x0f 000005b2: movw r30, r24 000005b4: std Z+1, r1 ; 0x01 000005b6: st Z, r1 196 return true; 000005b8: ldi r24, 0x01 ; 1 197 } 000005ba: adiw r28, 0x0f ; 15 000005bc: in r0, 0x3f ; 63 000005be: cli 000005c0: out 0x3e, r29 ; 62 000005c2: out 0x3f, r0 ; 63 000005c4: out 0x3d, r28 ; 61 000005c6: pop r29 000005c8: pop r28 000005ca: pop r17 000005cc: pop r16 000005ce: ret |
|
From: Joerg W. <j...@ur...> - 2015-02-10 17:59:57
|
As István Rétallér wrote:
> I do probably misunderstand something. Starting avr-gdb with -x
> option means the parameters are taken from that particular file,
> isn't it?
Yes, the man page of GDB says:
-x FILE, -command=FILE
Execute GDB commands from file file.
> gdbinit: $(GDBINITFILE)
>
> $(GDBINITFILE): $(TRG)
> @echo "file $(TRG)" > $(GDBINITFILE)
> @echo "target remote localhost:4242" >> $(GDBINITFILE)
> @echo "load" >> $(GDBINITFILE)
> @echo "break main" >> $(GDBINITFILE)
> @echo "continue" >> $(GDBINITFILE)
So, drop the echo line with "load" from that Makefile, in order
to prevent GDB from re-flashing the memory.
--
cheers, Joerg .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/
Never trust an operating system you don't have sources for. ;-)
|
|
From: István R. <ist...@gm...> - 2015-02-10 17:11:03
|
2015-02-09 23:41 keltezéssel, Joerg Wunsch írta:
>
> 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.
I do probably misunderstand something. Starting avr-gdb with -x option
means the parameters are taken from that particular file, isn't it?
gdbinit: $(GDBINITFILE)
$(GDBINITFILE): $(TRG)
@echo "file $(TRG)" > $(GDBINITFILE)
@echo "target remote localhost:4242" >> $(GDBINITFILE)
@echo "load" >> $(GDBINITFILE)
@echo "break main" >> $(GDBINITFILE)
@echo "continue" >> $(GDBINITFILE)
gdbserver: gdbinit
avarice -2 -j usb -P $(MCU) $(DW) localhost:4242 &
gdb: gdbserver gdbinit
sleep 3
avr-gdb -x $(GDBINITFILE)
--
|
13 messages has been excluded from this view by a project administrator.
