Re: [AVaRICE-user] JTAGICE mkII Communication with Avr-Dragon and xmega-devices fails
As Detlev Kraft wrote: A communication analysis between Avarice Dragon and on the other hand Studio5 Dragon shows a lot of differences. Thanks so much for analyzing this, Detlev! There are new, undocumented commands and parameters(Avr-Note 067). Avarice is not usable anymore! Curious: does that statement also apply to debug classic AVRs (ATmega devices with JTAG, ATtiny devices with debugWIRE), or only to Xmega devices? The latter have never really been supported in AVaRICE, due to the lack of documentation, and due to the many differences in the way Xmegas are handled. - is there a need to adapt the protocol changes in Avarice in general? Probably, yes, though the answer depends on the answer to my question above. If the new (AVR Studio 5 based) firmware is backwards compatible enough for classic AVRs, then I wouldn't see an immediate need to change AVaRICE. If they are broken by the new firmware, then yes, we have to cope with it, which probably means to detect the new firmware by its version number (which is easy), and then talk different pieces of protocol where needed, depending on which firmware level we are talking to. While AVR Studio is in a position to dictate the firmware level of their ICEs, we have to live with what we are getting presented by the user, and should adjust our view appropriately. (We already acted that way in the past, have a look into src/jtag2io.cc, the way the various length of the device descriptor are handled, based on the firmware found in the ICE. The device descriptor has been extended over time by Atmel.) - are there any plans to implement the new and extended protocol in Avarice? The question is merely whether there are enough developers around willing to work on that ... I'm afraid I won't have enough manpower to manage all of that alone. - does anybody own an newer protocol documentation? newer Avr-Note 067 than 11/2009? The Atmel folks in Trondheim? ;-) (Yes, I know, you've already been asking them ...) -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free Love Thy Logs t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ avarice-user mailing list avarice-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/avarice-user
Re: [AVaRICE-user] Change of VCS
As Paul Klapperich wrote: On the other hand, Subversion does have a long known random commit corruption bug, which makes an old commit and a few after it unusable. Interesting, thanks for the warning. I've never heard about (or experienced) that myself. That might be reason enough to stay away from it, though. I'll give Mercurial another thought. I first have to dig up the exact steps that need to be done on sourceforge for the transition. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) -- Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ ___ avarice-user mailing list avarice-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/avarice-user
Re: [AVaRICE-user] Change of VCS
As Joerg Wunsch wrote: Now that AVaRICE 2.11 has been shipped, I'd consider changing away from CVS. ... ..., I'd rather simply use Subversion which I'm most used to. I finally did it. AVaRICE is using Subversion now! Please do no longer use the old CVS repository. (I disabled it in the SF.net feature list, but have no idea whether it would still be accessible using ssh.) In order to checkout a fresh copy of the SVN trunk, use: svn co https://avarice.svn.sourceforge.net/svnroot/avarice/trunk/avarice Read-only checkouts require no authentication, and can be performed by anyone. Committing changes to the repository (i.e., developer access) does not use the SSH keys as it has been the case with CVS, but instead uses HTTP/S, together with your sourceforge.net username and HTTP/S password (the same you use to log into the Web API). -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ avarice-user mailing list avarice-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/avarice-user
[AVaRICE-user] First release candiate for AVaRICE 2.12
Thanks to Detlev Kraft's reverse engineering of the way AVR Studio 5 talks with the JTAGICEmkII/AVRDRAGON, and thanks to his detailed analysis of that communication, I could add support for ICE firmware versions 7.x to AVaRICE. (With Detlev's permission, I added his document to the doc/ folder in SVN. Sorry, it's in German only.) In particular, this improves the situation for Xmega devices a lot. For the first time, I'd claim that AVaRICE now supports Xmega devices (but only if you had a chance to upgrade your ICE firmware to 7.x). Sorry, data breakpoints (watchpoints in GDB terminology) are not supported on Xmega devices. This appears to be a limitation of the ICE firmware right now, AVR Studio 5 does not support data breakpoints at all (not even for MegaAVR devices, where we continue supporting it). I also added some minor performance improvements, in particular PC caching, so AVaRICE finally makes use of the BREAK event the ICE sends whenever it stops the target CPU, thus eliminating the need to send another CMND_READ_PC again. In some areas, I think we might now even be faster than AVR Studio 5 (e.g. AVR Studio issues 32 separate ICE commands to read the CPU registers, while we read all 32 registers in one request). Given that the changes are a little more intrusive than they used to be in previous releases, I'd ask everyone to give the release candidate a try. Obviously, people who'd like to test the new features with version 7.x firmware are very welcome, but likewise, I'd like to know whether everything else still works the way it used to previously (i.e., all Tiny/Mega devices should continue to work as before, for any supported ICE firmware version). For the convenience of Windows users, I could find a Windows machine to compile it under Cygwin, and provide a Windows .exe file (in the .zip archive). You propably need an installed Cygwin to resolve the various cyg*.dll dependencies, sorry, but that's unavoidable the way AVaRICE is written (which is fairly Posix-centric, using fork(), unnamed pipes, IO multiplexing and all this). If you encounter any bugs, please do not hesitate to fill in a bug tracker item on sourceforge.net. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ avarice-user mailing list avarice-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/avarice-user
Re: [AVaRICE-user] First release candiate for AVaRICE 2.12
As Joerg Wunsch wrote: Given that the changes are a little more intrusive than they used to be in previous releases, I'd ask everyone to give the release candidate a try. According to Sourceforge's download statistics, a number of people downloaded both, the source tarball as well as the Win32 zip file. In the hope that at least some of those who picked up the files had a chance to test it, and given that no bug report came in, I'd like to release AVaRICE 2.12 tonight. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ avarice-user mailing list avarice-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/avarice-user
[AVaRICE-user] Version 2.13 is released
As threatened before, I just released version 2.13, after applying a number of outstanding patches. Enjoy! Here's the top of the NEWS file: # $Id: NEWS 308 2012-11-05 16:41:14Z joerg_wunsch $ Summary of changes in AVaRICE 2.13 == . Rearrange the entire error handling to use exceptions, rather than a mix between error code returns, and prematurely exiting the program from deep inside, without any attempt to cleanup the JTAG ICE connection status. This is a lot cleaner now, with a much reduced chance to leave the ICE in an unworkable state when exiting the program. . New devices: ATxmega128B1, ATxmega128B3, ATxmega64B1, ATxmega64B3, ATmega16M1, ATmega64M1, ATmega64C1, ATxmega128A3, ATxmega32A4 . Deprecate target programming (downloading) from the ELF file. It must be explicitly enabled now by the --enable-target-programming configure option. If not enabled, AVaRICE no longer depends on libbfd and its prerequisites. Use AVRDUDE for device programming. . Added IO register definitions (for GDB's info io_registers command) for the following devices: ATmega323, ATmega64, AT90CAN128, ATmega164p, ATmega324p, ATmega644, ATmega325, ATmega3250, ATmega645, ATmega6450, ATmega329, ATmega3290, ATmega649, ATmega6490, ATmega640, ATmega1280, ATmega1281, ATmega2560, ATmega2561, ATmega48, ATmega88, ATmega168, ATtiny13, ATtiny2313, AT90PWM2, AT90PWM3, AT90PWM2B, AT90PWM3B, ATmega32M1, ATmega32C1, ATtiny24, ATtiny44, ATtiny84, ATtiny25, ATtiny45, ATtiny85, ATtiny261, ATtiny461, ATtiny861, AT90CAN32, AT90CAN64, AT90PWM216, AT90PWM316, AT90USB1287, AT90USB162, AT90USB646, AT90USB647, ATmega1284P, ATmega165, ATmega165P, ATmega168P, ATmega16HVA, ATmega3250P, ATmega325P, ATmega328P, ATmega3290P, ATmega329P, ATmega32HVB, ATmega32U4, ATmega406, ATmega48P, ATmega644P, ATmega88P, ATtiny167, ATtiny43U, ATtiny48, ATtiny88, ATmega128RFA1 = -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) -- LogMeIn Central: Instant, anywhere, Remote PC access and management. Stay in control, update software, and manage PCs from one command center Diagnose problems and improve visibility into emerging IT issues Automate, monitor and manage. Do more in less time with Central http://p.sf.net/sfu/logmein12331_d2d ___ avarice-user mailing list avarice-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/avarice-user
Re: [AVaRICE-user] AVR dragon desynchronizing with GDB
As Francois Lorrain wrote:
That's why I am calling my modification a hack :-) I couldn't even figure
out how to tell the configure script to look for libusb-1.0 instead of
libusb.
Have a look into AVRDUDE's configure.ac, I've already done it there.
For the regular command / response processing, I just used the synchronous
interface of libusb-1.0. It seemed like an overkill since the AVR Dragon
just answers to the command and there does not seem to be any unexpected
answers.
Sorry, that's not the case.
There's something the JTAG ICE calls an event: it is *not* triggered
by a command synchronously (*), but by the ICE itself. The obvious
situation where this happens is reaching a breakpoint during normal
program run. AVaRICE has to wait for this in parallel to waiting for
new input from GDB (since it could as well be the user hitting ^C to
break the program), this happens in jtag2run.cc here:
int numfds = select(maxfd + 1, readfds, 0, 0, 0);
if (numfds 0)
throw jtag_exception(GDB/JTAG ICE communications failure);
if (gdbFileDescriptor != -1 FD_ISSET(gdbFileDescriptor, readfds))
{
int c = getDebugChar();
if (c == 3) // interrupt
{
debugOut(interrupted by GDB\n);
gdbInterrupt = true;
}
else
debugOut(Unexpected GDB input `%02x'\n, c);
}
if (FD_ISSET(jtagBox, readfds))
{
expectEvent(breakpoint, gdbInterrupt);
}
(*) Actually, some commands do trigger a BREAK event in addition to the
regular response frame. Actually, that's more a nuisance than helpful.
There are more possible events than just reaching a breakpoint: device
entering/leaving sleep, power cycle, unsolicited reset (external or
watchdog, for example).
I used the asynchronous interface when the target is running and you need
to poll for either a GDB interrupt packet or the Break packet coming from
the AVR Dragon.
OK, that's what I meant. Basically, you just have to know which Unix
filedescriptor to poll for in the select() statement above.
libusb-0.1 didn't allow for this, 1.0 does. As such, it obviates the
need for a separate thread or process to handle the USB communication.
One thing which is leftover from the serial interface is the fact that
avarice will try to resend the command after a timeout if it did not get an
answer, this is definitely a No-No for USB, repeating the command packet
does confuse the AVR dragon ...
Well, what do you want to do if the ICE doesn't answer? Just sit there?
I changed this quite a bit lately, I think it's more robust now.
Quick question : When you have a Jtag2 interface, is it always connected
via USB or can you have the JtagIce connected via serial ?
As the JTAGICEmkII does offer an RS-232 connector, we should be able to
handle it. (The AVR Dragon and JTAGICE3 don't have it anymore.)
--
cheers, Jorg .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_nov
___
avarice-user mailing list
avarice-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/avarice-user
Re: [AVaRICE-user] Debug trace the next
As Andreas Løhre wrote: I was still not able to start a session on the 1284P. OK, I'm interested in seeing the debug traces for that. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ avarice-user mailing list avarice-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/avarice-user
Re: [AVaRICE-user] Debug trace the next
As Andreas Løhre wrote: The full output is: An interesting list, thanks! [jtag2rw.cc:180]: (error) Memory leak: response [jtag3rw.cc:182]: (error) Memory leak: response Both these are actually the same (with the jtag3 code being cloned from the jtag2 implementation). All this looks confusing, and I have to think about it again (there's a usage of resp versus response inside these functions). [jtag2usb.cc:422]: (error) Mismatching allocation and deallocation: devnamecopy Created as an array, but deleted as a non-array. Fixed. [jtag2usb.cc:302]: (error) Memory leak: devnamecopy Yes, in cas of an error; fixed. [jtag3io.cc:495]: (error) Array 'cmd[4]' accessed at index 4, which is out of bounds As you've guessed, 0, 1, 2, 3 is the correct sequence. Besides accessing the array out of bounds, the bug lead to the request for applying an external reset (throgh nSRST) not being obeyed at all. Fixed. I'm afraid the next step would be to strace both invocations, and see what is done differently in the version as compiled by GCC 4.7. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ avarice-user mailing list avarice-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/avarice-user
Re: [AVaRICE-user] Debug trace the next
As Andreas Løhre wrote:
I have attached an strace for 4.6.3 (same behaviour as 4.7.2), but I won't
be able to do the one for 4.7/4.4/4.5 before tomorrow.
Thanks to all who helped narrowing this down.
I could eventually reproduce it myself with a GCC 4.7, and then find
and fix it.
It's been a pointer aliasing problem. The device parameter field was
filled in like:
uchar *param, paramsize;
...
{
jtag3_device_desc_type d3;
param = (uchar *)d3;
paramsize = sizeof d3;
memset((void *)d3, 0, sizeof d3);
// fill in params here:
d3.flash_size ...
d3.flash_page_size
...
}
setJtagParameter(SCOPE_AVR, 2, PARM3_DEVICEDESC, param, paramsize);
GCC 4.7 decided that every assignment to d3 after the initial
memset() would result in values that are not used, as d3 was out
of scope at that point. Thus, a null parameter block has been
sent.
Moving the definition of d3 to the next outer scope helped.
OK, I'd like to hear about any other issues people have with it ...
In case it dies after some debugging actions, it would be interesting
to see the -d trace of the actions taken.
--
cheers, Jorg .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
--
Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and
much more. Get web development skills now with LearnDevNow -
350+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122812
___
avarice-user mailing list
avarice-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/avarice-user
Re: [AVaRICE-user] Ubuntu no usb device (2)
As Wojtek wrote: I tried to add symlink for my device according to post: You are not supposed to add that symlink, you completely misunderstood. This link is only meaningful for devices which are accessed through a standard serial port, like the first JTAGICE, or the JTAGICEmkII when connected through RS-232. did not find any USB device usb USB device not fount Could you suggest me where to search a problem? Does /sbin/lsusb find the device? Did you tell your udev configuration to pass ownership of the device to you, so it can be accessed without root-only permissions? -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ avarice-user mailing list avarice-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/avarice-user
Re: [AVaRICE-user] AVR Dragon not working with atxmega16d4
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: 00A27BFE 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
Re: [AVaRICE-user] AVR Dragon not working with atxmega16d4
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. ;-) -- ___ avarice-user mailing list avarice-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/avarice-user
Re: [AVaRICE-user] Support of new Atmel-ICE and future support of JTAGICE3
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 avarice-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/avarice-user
Re: [AVaRICE-user] Atmel ICE issue
As Tomek wrote: > Then I invoked > $ avarice --edbg --debugwire --ignore-intr :4242 > > > AVaRICE version 2.13svn20160229, Mar 3 2016 14:04:24 > JTAG config starting. > Found a device, serial number: J41800031019 > initJtagBox() failed: JTAG ICE timeout exception Hmm, so far I tried it on FreeBSD and Linux (Ubuntu 14.04), where it worked: % ./src/avarice --edbg --debugwire --ignore-intr :4242 AVaRICE version 2.13svn20160229, Mar 3 2016 21:50:21 JTAG config starting. Found a device, serial number: ATML2323040200015056 Reported device ID: 0x950F Configured for device ID: 0x950F atmega328p JTAG config complete. Preparing the target device for On Chip Debugging. Waiting for connection on port 4242. Here's the trace with --debug: % ./src/avarice --edbg --debugwire --ignore-intr --debug :4242 AVaRICE version 2.13svn20160229, Mar 3 2016 21:50:21 Found HID PID:VID 0x03eb:0x2145, serno ATML2323040200015056 Probing for HID max. packet size Setting max. packet size to 64 from DAP_Info HID thread started JTAG config starting. command "sign-on" [0x01, 0x10] 0E 00 00 00 01 10 00 Received 0x81 0x11 0x00 0x06 0x0e 0x00 read: 0e 00 00 01 80 00 Got message seqno 0 (command_sequence == 0) response: 01 80 00 command "get info (serial number)" [0x00, 0x00] 0E 00 01 00 00 00 00 81 Received 0x81 0x11 0x00 0x1a 0x0e 0x01 read: 0e 01 00 00 81 00 41 54 4d 4c 32 33 32 33 30 34 30 32 30 30 30 31 35 30 35 36 Got message seqno 1 (command_sequence == 1) response: 00 81 00 41 54 4D 4C 32 33 32 33 30 34 30 32 30 30 30 31 35 30 35 36 Found a device, serial number: ATML2323040200015056 command "get parameter" [0x01, 0x02] 0E 00 02 00 01 02 00 00 00 05 Received 0x81 0x11 0x00 0x0c 0x0e 0x02 read: 0e 02 00 01 84 01 00 01 04 3b 00 00 Got message seqno 2 (command_sequence == 2) response: 01 84 01 00 01 04 3B 00 00 ICE hardware version: 0 ICE firmware version: 1.04 (rel. 59) command "set parameter" [0x12, 0x01] 0E 00 03 00 12 01 00 00 00 01 01 Received 0x81 0x11 0x00 0x06 0x0e 0x03 read: 0e 03 00 12 80 00 Got message seqno 3 (command_sequence == 3) response: 12 80 00 command "set parameter" [0x12, 0x01] 0E 00 04 00 12 01 00 00 01 01 02 Received 0x81 0x11 0x00 0x06 0x0e 0x04 read: 0e 04 00 12 80 00 Got message seqno 4 (command_sequence == 4) response: 12 80 00 command "set parameter" [0x12, 0x01] 0E 00 05 00 12 01 00 01 00 01 05 Received 0x81 0x11 0x00 0x06 0x0e 0x05 read: 0e 05 00 12 80 00 Got message seqno 5 (command_sequence == 5) response: 12 80 00 command "AVR sign-on" [0x12, 0x10] 0E 00 06 00 12 10 00 00 Received 0x81 0x11 0x00 0x0b 0x0e 0x06 read: 0e 06 00 12 84 00 0f 95 00 00 00 Got message seqno 6 (command_sequence == 6) response: 12 84 00 0F 95 00 00 00 AVR sign-on responded with device ID = 0x950F Reported device ID: 0x950F Configured for device ID: 0x950F atmega328p Automatic device detection: command "set parameter" [0x12, 0x01] 0E 00 07 00 12 01 00 02 00 1F 80 00 00 80 00 00 00 00 00 00 00 3F 00 00 00 01 00 04 04 01 01 00 00 00 00 22 21 1F 20 00 46 Received 0x81 0x11 0x00 0x06 0x0e 0x07 read: 0e 07 00 12 80 00 Got message seqno 7 (command_sequence == 7) response: 12 80 00 JTAG config complete. Preparing the target device for On Chip Debugging. command "set parameter" [0x12, 0x01] 0E 00 08 00 12 01 00 03 00 01 00 Received 0x81 0x11 0x00 0x06 0x0e 0x08 read: 0e 08 00 12 80 00 Got message seqno 8 (command_sequence == 8) response: 12 80 00 command "start debugging" [0x12, 0x13] 0E 00 09 00 12 13 00 01 Received 0x81 0x11 0x00 0x06 0x0e 0x09 read: 0e 09 00 12 80 00 Got message seqno 9 (command_sequence == 9) response: 12 80 00 command "reset" [0x12, 0x30] 0E 00 0A 00 12 30 00 01 Received 0x81 0x11 0x00 0x06 0x0e 0x0a read: 0e 0a 00 12 80 00 Got message seqno 10 (command_sequence == 10) response: 12 80 00 read: 0e 00 02 00 12 40 c5 01 00 00 01 00 00 Event serial 0x0002 ignoring break event Waiting for connection on port 4242. Try finding out where it fails. Maybe it's some kind of timing issue. 73! -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) -- ___ avarice-user mailing list avarice-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/avarice-user
Re: [AVaRICE-user] EDBG/ATATMEL-ICE support
As Philip Mulrane wrote: > I don't actually have a PC-based Linux installation (would avarice run > on a Raspberry Pi? I never tried it, but I think it might run there, provided libusb and libhidapi are available. In addition, the only resources AVaRICE is using are pipes and Posix threads, which I think won't be a problem on the RPi. I've got an older RPi around, where I could try that as well. > Are there any recommended > Virtual PC solutions that are better from the point of view that the USB > will also be virtual? I've always made the best experiences regarding USB using VMware. I've got a couple of Windows guests running on Linux hosts that way, and e.g. even firmware upgrades from within Atmel Studio do work. The VMware Player (without "plus") is free of charge, but pretty well hidden on the VMware website. ;-) It's main missing feature compared to the pay version is that it cannot handle snapshots. -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) -- ___ avarice-user mailing list avarice-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/avarice-user
Re: [AVaRICE-user] EDBG/ATATMEL-ICE support
As Philip Mulrane wrote: > Can this also be used with the mEDBG of the xlpained mini? It > apparently supports debug wire? Yes, I added fragmentation / reassembly support yesterday, which is required for mEDBG since they only support 64 bytes endpoint size, and some transfers are (much) longer. However, there's currently still some issue where programming over debugWIRE (through GDB's "load" command) doesn't work since AVaRICE first attempts a flash erase which is not supported in debugWIRE mode, and thus triggers an exception. Attaching to a pre-flashed device, and debugging it, is possible though. There are some other cases where in some situations exceptions are thrown. These have to be cleaned up before a new release can be prepared. -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) -- Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140 ___ avarice-user mailing list avarice-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/avarice-user
Re: [AVaRICE-user] EDBG/ATATMEL-ICE support
As Philip Mulrane wrote: > For what it's worth, the XplainedMini appears in Microsofts USB Device > Viewer utility, and when I installed the filter for libUsb for the > relevant endpoints of the XplainedMini, they also showed up in > "install-filter-win.exe" Yes, it appears there, but it never answers if you try to talk to it. Been there, done that (in AVRDUDE). Plain libusb doesn't work for HIDs on Windows or OSX. Only FreeBSD and Linux can access it that way. Thus, for AVaRICE, I simplified the implementation (compared to AVRDUDE) by requiring libhidapi for the CMSIS-DAP/EDBG stuff. -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) -- Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140 ___ avarice-user mailing list avarice-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/avarice-user
Re: [AVaRICE-user] New thread on avr freaks
As Tomasz Wawer wrote: > Please have a look, maybe you could help with this: Well, I told you that code downloading through debugWIRE currently doesn't work, neither in AVRDUDE nor in AVaRICE through GDB's "load" command. Sorry, I have no real idea so far *why* it fails. It pretends to write the first data block, but it never gets written, and then the AVR communication with the ICE is lost it seems. I have USB traces that show what Atmel Studio is doing, and need quite some time to compare them to what AVRDUDE does (the Studio trace is really huge). 73! -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) -- Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://makebettercode.com/inteldaal-eval ___ avarice-user mailing list avarice-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/avarice-user
Re: [AVaRICE-user] Atmel ICE issue
As sq5rix wrote: > Now it works (Ubuntu 14.04) > > Sorry for trouble, it was some transient error. --debug helped! I'm glad it works, good luck! 73! -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) -- ___ avarice-user mailing list avarice-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/avarice-user
Re: [AVaRICE-user] AVaRICE with AVRDragon and AtMEGA8u2, debugWire
As Brian wrote: > got asynchronous event: 0xf7 > recv: timeout This is an #define EVT_ERROR_PHY_RECEIVE_TIMEOUT 0xF7 meaning the debugWIRE transport timed out (between the Dragon and the target). > So...is this something to do with telling AVaRICE it's an atmega48 when > it's really an atmega8u2? Very unlikely. Btw., when debugging an 8 KiB device (ATmega8U2), better pick another 8 KiB device for -P, like the ATmega88. > Suffice it to mention that using Atmel Studio > under Windows works flawlessly. Then the only way to find out is (unfortunately) to trace Atmel Studio's actions when initializing the AVR Dragon, and compare it to what AVaRICE does. I'd more suspect the actual debugWIRE connection at first though. You can try experiment with pullup resistors on /RESET. I've seen target working more reliably with 4.7 kΩ or 10 kΩ pullups, but I've also seen target working best without any additional component between the ICE (i.e. your Dragon) and the /RESET line. Also make sure to use at most the standard STK500 cable length between the Dragon and the target (about 15 cm), as the Dragon's line drivers are known to be quite weak. -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) -- Mobile security can be enabling, not merely restricting. Employees who bring their own devices (BYOD) to work are irked by the imposition of MDM restrictions. Mobile Device Manager Plus allows you to control only the apps on BYO-devices by containerizing them, leaving personal data untouched! https://ad.doubleclick.net/ddm/clk/304595813;131938128;j ___ avarice-user mailing list avarice-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/avarice-user
Re: [AVaRICE-user] Building avarice on (Gentoo)-Linux with usb suport
As Olaf Dreyer wrote: > But the resulting binary tells me, that it was build without usb support. > Do I have to make some settings during the configure step? You need to have a libusb around, including the required headers to compile against it. On most Linux distributions, this means you'd have to have the respective "-dev" or "-devel" package installed. AVRDUDE's configure script auto-detects the environment, and prints a summary like this: Configuration summary: -- DO HAVElibelf DO HAVElibusb DO HAVElibusb_1_0 DO HAVElibftdi1 DON'T HAVE libftdi DON'T HAVE libhid DO HAVElibhidapi DO HAVEpthread DISABLED doc ENABLEDparport DISABLED linuxgpio Make sure libusb has a "DO HAVE" there. Note that libhid there is Windows-only, and only relates to USBasp. In order to get support for the recent Atmel tools that are als HIDs, libhidapi support is needed. -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) -- ___ avarice-user mailing list avarice-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/avarice-user
Re: [AVaRICE-user] AVARICE and JTAGICE3 on Linux not working
As Stephan Meyer wrote: > command "reset" [0x12, 0x30] > 0E 00 0D 00 12 30 00 01 > Received 0x81 0x11 0x00 0x07 0x0e 0x0d > read: 0e 0d 00 12 a0 00 50 > > Got message seqno 13 (command_sequence == 13) > response: 12 A0 00 50 > retrying reset ... > > command "reset" [0x12, 0x30] > 0E 00 0E 00 12 30 00 01 > Received 0x81 0x11 0x00 0x07 0x0e 0x0e > read: 0e 0e 00 12 a0 00 50 > > Got message seqno 14 (command_sequence == 14) > response: 12 A0 00 50 It fails to reset the target, that's why it terminates subsequently. Response code 0x50 is listed as: AVR8_FAILURE_NO_OCD_CONTROL = 0x50, //! Device is not under control in the Atmel documentation. Whatever that might mean ... -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) -- ___ avarice-user mailing list avarice-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/avarice-user
Re: [AVaRICE-user] Bug in AVaRICE 2.13
As Marian Buschsieweke wrote: > My point is: SourceForge.net is a platform that really scares me away from an > open source project, no matter how cool it is. Other coders and potential > contributors may feel the same way about it. Maybe with teahub.io a good > alternative will (hopefully) emerge some day in the (hopefully) not too > distant > future. Maybe that is worth for AVaRICE to look into, when it becomes > available? Seriously, AVaRICE has bigger problems but its hosting platform or indentation style (or VCS, in case anyone's asking for Git now ...). Sourceforge hasn't been my decision, I merely inherited the project that way, but for just distributing the software, it doesn't matter much anyway which platform it is lying on. So far, there are *zero* active developers, plus a number of things that require a rewrite of larger portions of the code. Namely, the entire handling of the AtmelICE (and JTAGICE-3 in HID mode, as well as all the embedded debuggers of the various Xplained boards) is just alpha quality, and could be considered flakey at best. This is way more important than stylistic things (as important as they might be to you personally), because it affects the core functionality of the tool for the only existing current Atmel debugging hardware. I don't have the time to do anything on it, sorry. I can probably merge the current patch (which is a trivial one), and I could also be willing to just roll out a new release if needed, but that's it. If there's anyone going to jump in, who wants to *seriously* (and long-term) maintain AVaRICE, it would be their decision where to host the project (or just keep it on SF.net). They are then also free to migrate to the VCS they feel most comfortable with, and to fix stylistic issues. -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ avarice-user mailing list avarice-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/avarice-user
Re: [AVaRICE-user] Source no longer available?
As Marian Buschsieweke wrote: > the SVN server is now again operational. Confirmed (as well as the outage before). -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) ___ avarice-user mailing list avarice-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/avarice-user
[AVaRICE-user] AVaRICE 2.14 released
Hello * this is just to inform you that I finally rolled a new release of AVaRICE, 2.14. Not much has been done to the code base during the recent four (or so) years, unfortunately. I've never been fully confident with the state of EDBG handling (i.e., Atmel-ICE and the EDBG versions found on a number of demo boards by Atmel/Microchip). The code handling it (activated by option "-4", as it logically succeeds the earlier JTAGICE3 protocol, even though JTAGICE3 now also runs EDBG protocol) has always been a bit fragile to me. However, changing this requires so much reorganization of the code, I never found the time and energy for that. I also contemplated moving everything to OpenOCD (which seems to be able to handle the Atmel-ICE flawlessly for Cortex-M devices), but adding the AVR debugging support there is likely going to be not less work. So here we are now, EDBG is at the very least there (and has been in the tree for many years now). I picked all the patches and bug reports from the respective trackers that could be applied without risking any breakage or incompatibilities. Thanks to everyone involved there, this is much appreciated! I'm particularly happy to see some documentation updates that came in - an area that is often neglected a bit. So enjoy, I'm sorry I did not find time to make more improvements, but I hope the new release will be quite an improvement to many AVR developers anyway. -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) ___ avarice-user mailing list avarice-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/avarice-user
Re: [AVaRICE-user] avr-gdb connects,but there is no prompt.
As Istvan Retaller wrote: > > /usr/bin/avr-objcopy -j .text \ -j .data > > \ -O ihex testburst.out testburst.hex /usr/bin/avrdude -F -c jtag2isp > > -P usb -B 10 -b 115200 -p t45 -e -U flash:w:testburst.hex -U > lfuse:w:0x62:m -U hfuse:w:0x9f:m -U efuse:w:0xff:m avrdude: Only as a side note: you can do all of this straight from the ELF file, no need to objcopy into an Intel hex file. As another side note, since you are already in debugWIRE mode: fuses cannot be programmed at all in this mode. (Technically, debugWIRE is a kind of ROM-based monitor program, so it can only access those resources the CPU can reach. Fuses and lock bits don't belong to that.) In your case, the fuse "programming" just passes since they are not changed at all. > *I start avr-gdb in a new terminal** > **The gdbinit content is_as follows:* > /target remote localhost:4242// > //break main// > //continue/ Well, for a first test, you'd better leave out the gdbinit file. > Pressing ^C I get a prompt and now gdb accepts commands. > However I do not know how got to this point and what was done to get there. > > > > Program received signal SIGINT, Interrupt. 0x0194 in __vector_3 () > > at testburst.c:122 122 } (gdb) Your gdbinit doesn't only attach to AVaRICE, but sets a breakpoint on main and tries proceeding there. As that breakpoint is never reached, you have to manually stop it with ^C, and then it is presumably inside the timer 1 compare A interrupt vector. Something appears to not really match here: if main() really hasn't ever been reached, how would interrupts become enabled so it could hit an ISR? Maybe the actual flashing by AVRDUDE didn't work, so you are debugging an entirely different firmware? What you could try: target remote :4242 display/i $pc then repeatedly use the si (step CPU instruction) command, and watch the CPU instructions passing by, comparing them with you disassemble file. Also, you could use the "disas" GDB instruction, or "x" the hexdump the flash contents, and compare it to what you think ought to be there. -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) ___ avarice-user mailing list avarice-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/avarice-user
Re: [AVaRICE-user] problems debugging with brand new Atmel-ICE
As Matthias B. wrote: > I don't know if the output *IDR dirty:... *does have any negative > effects or how to solve it!? I've just seen this the very first debug > session, might be not relevant. It's just an event posted by the ICE, and AVaRICE translates it. Probably not relevant. > Starting a debug session now often fails after "Preparing the target > device for On Chip Debugging." and a second call of avarice --jtag usb > --edbg :4242 mostly succeeds. That's a bit strange. The entire CMSIS-DAP related code leaves quite a bit to be desired. However, changing it would basically require a full rewrite since many of the underlying concepts and ideas do not match 1:1 to the way the CMSIS-DAP protocol is working. I don't have the time and energy to do this, alas. (OpenOCD definitely got that handling better, debugging ARMs with the Atmel-ICE works flawlessly.) > Another thing I've never seen before are lots of *Target went to sleep > *and *Target went out of sleep *prints in the shell during debugging. Likewise, events posted by the ICE. I'm not quite sure, I think the -E option might help you. -E, --event List of events that do not interrupt. JTAG ICE mkII and AVR Dragon only. Default is "none,run,target_power_on,target_sleep,target_wakeup" Just experiment a bit with that. -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) ___ avarice-user mailing list avarice-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/avarice-user
Re: [AVaRICE-user] [avarice:code] New commit [r397] by jputcu
As AVaRICE SVN repository wrote: > Support code formatting using clang-format While I agree it's good to have some code formatting rules, please do not apply code formatting onto arbitrary files just for the purpose of changing the formatting. Gratuitously changing just the formatting of some files generates a bunch of irrelevant diffs if you are going to traverse that change later on, thus potentially hiding the actual code changes. (FreeBSD did this mistake once, more than 25 years ago, by removing all trailing white space throughout the entire tree.) -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) ___ avarice-user mailing list avarice-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/avarice-user
[AVaRICE-user] HEADSUP: Repository migrated to Github
Hello everyone, I just migrated the SVN repository to Github. New location is: https://github.com/avrdudes/avarice I have disabled developer write access to the SVN repo, so it remains merely as a reference for the existing code base (even though I believe the Git repository to contain everything that used to be in SVN). I'm still about to investigate how to / how many migrate issue trackers there as well. -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) ___ avarice-user mailing list avarice-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/avarice-user
