AVR Freaks

OK. After tinkering a bit with the patchy stuff from  #90 by TT_ZX I got a successful build (make) and installation (make install). Verified this far:

mint@mint ~/AVR/avarice-2.13 $ which avarice
/usr/local/bin/avarice


mint@mint ~/AVR/avarice-2.13 $ avarice
AVaRICE version 2.13, Jul 28 2017 19:47:49

Defaulting JTAG bitrate to 250 kHz.

Failed to open /dev/avrjtag

mint@mint ~/AVR/avarice-2.13 $

So this really looks promising. (I've thought and said that before.. This time it looks even better. Let's hope it does not end up even worse.. ;-) )

@clawson:

Funny.. I couldn't restrain myself (another mug of coffee helped...) so I dug out the Dragon. Tried and it also failed, and then I thought "sudo!" but no dice:

int@mint ~/AVR/avarice-2.13 $ sudo avarice
AVaRICE version 2.13, Jul 28 2017 19:47:49

Defaulting JTAG bitrate to 250 kHz.

Failed to open /dev/avrjtag

I assumed, since it by default tries to open /deb/avrjtag, that no paremeters/switches where needed for this small test. But this:

mint@mint ~/AVR/avarice-2.13 $ sudo avarice --dragon
AVaRICE version 2.13, Jul 28 2017 19:47:49

Defaulting JTAG bitrate to 250 kHz.

JTAG config starting.
Found a device: AVRDRAGON
Serial number:  00:a2:00:01:46:33
Reported JTAG device ID: 0x9801
Configured for device ID: 0x9801 atmega2560
JTAG config complete.

Sorry for screaming, but... SUCCESS!!!

Now it's really time to stop for tonight.

Next stint will be:

• Set up Atmel Toolchain for Linux
• Write and build a "blinky" of some kind.
• Test actual flash programming (AVRDUDE)

The "big one" will then be

• Test actual debugging. I expect some frustration and clinch-fighting when I get to that. I'm on my way back to Colin O'Flynns very old tutorial PDF (2003!), and the AVARICE man page.

One "interesting" observation:

The Atmel-ICE showed up under /dev on Linux Mit. The Dragon does not show up as far as I can see - still it works...

Also, AVRDUDE will not work after the successful bAVARICE start. I guess AVARICE is still running and "holding" the Dragon and I need to stop it so that the Dragon is released. It's been years since I meddled with processes on Linux.. ps and kill, here I come..

Hmmm.. AVARICE does not seem to be running. At least it is not in a listing from 'ps'.

At first I was stupid and managed to recall the AVRDUDE command for Atmel-ICE while I now have the Dragon on the bench.

But even with correct parameters to AVRDUDE it failed. A power cycle of the Dragon and/or target solved this:

mint@mint ~ $ sudo avrdude -c dragon_jtag -p ATmega2560

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9801 (probably m2560)

avrdude: safemode: Fuses OK (E:FF, H:11, L:E0)

avrdude done.  Thank you.

That mistake with trying to drive the Dragon as an Atmel-ICE is the telltale sign of me getting to tired, so it's really time to stop.

A very good day it has been, though! Good night in this thread!

Todays progress:

On my new "dual booted" Linux Mint

• "Installed" toolchain (Atmel Toolchain for Linux)
• Did a build of AVRDUDE
• Installed NetBeans

and then

• Did a test build of "blinky" in terminal (i.e. "command prompt"). Success!
• Set up the toolchain in Netbeans, and a small "LEDs follows switches" was tested there. After a bit of tinkering I got that working.
• Set up the Dragon and the STK600 with an ATmega2560 and successfully ran AVRDUDE. Reading fuses, writing fuses, programming flash. Success!

I'm very happy with that progress for a couple of hours of tinkering!

I now feel close to getting into what I was starting out to try (more than 100 posts ago...): On-chip debugging. Yes, finally!

Hello TT_ZX!

Haven't seen anything of you here for a while. I'd like to thank you for some invaluable help - specifically the patches to AVARICE but also encouragement in general!

What is the output of:

avarice --help

Haven't done a build of AVARICE yet so can't tell right now. I believe I have a build on the Mint memory stick so let me boot from that and have a look..

I'm curious about your curiosity ;-) What is it you're looking for?

I'm interested to see if you get this in your output:

  -3, --jtag3                 Connect to JTAGICE3 (Firmware 2.x)
  -4, --edbg                  Atmel-ICE, or JTAGICE3 (firmware 3.x), or EDBG Integrated Debugger

I wasn't getting this when I was building AVaRICE [...]

I did ./configure, of that I am sure. Can't remember doing the ./Bootstrap, have to look into my memory notes..

If you didn't get the above output from your own build, then where did you get it from?

Yes, my build is using the sources of the latest release, not the HEAD of the SVN.

I know Jörg Wunsch (known here as 'dl8dtl') has done work on implementing EDBG, but am not sure if it is on the AVARICE trunk yet, or still in a branch.

Now that I'm getting comfortable with the building process, I could take a stab looking at the AVARICE SVN history and have a go at building from HEAD or some branch with EDBG. I to am very interested in getting JTAGICE3 and EDBG/Atmel-ICE going!

Latest commit (r363) on branch jwunsch_edbg is dated 2016-03-03, so that is quite a while since: https://sourceforge.net/p/avaric...

That commit (r363) was merged to trunk in (r364) on the same day. This makes me think that, SVN-wise, whatever EDBG/Atmel-ICE support there is is on trunk and in HEAD. Could be some setting before/during build is required..

I have other pressing things today, but will try a build from SVNs HEAD at my first convenience!

No-no-no!

After a better web search:

The aclocal is a program that needs to be installed! A simple

sudo apt install automake

made this go much better:

johan@Mint-Latitude-E6330 ~/AVR/avarice/avarice-code-372-trunk $ ./Bootstrap
+ aclocal
+ autoheader
+ autoconf
+ [ -d config-aux ]
+ mkdir config-aux
+ automake -a -c
configure.ac:35: installing 'config-aux/compile'
configure.ac:38: installing 'config-aux/config.guess'
configure.ac:38: installing 'config-aux/config.sub'
configure.ac:31: installing 'config-aux/install-sh'
configure.ac:31: installing 'config-aux/missing'
src/Makefile.am: installing 'config-aux/depcomp'
+ rm -f config.cache

and after a

./configure

I now have a Makefile! A make seems to go OK (havent noticed before that the avarice executable ends up in the src subdirectory, but it does. Double checked with 2.13 and that build does the same.)

Aaaaannnyyywayyyy, heres the good stuff:

johan@Mint-Latitude-E6330 ~/AVR/avarice/avarice-code-372-trunk/src $ ./avarice -?
AVaRICE version 2.13svn20160229, Jul 31 2017 12:33:45

Usage: ./avarice [OPTION]... [[HOST_NAME]:PORT]

Options:
  -h, --help                  Print this message.
  -1, --mkI                   Connect to JTAG ICE mkI (default)
  -2, --mkII                  Connect to JTAG ICE mkII
  -3, --jtag3                 Connect to JTAGICE3 (Firmware 2.x)
  -4, --edbg                  Atmel-ICE, or JTAGICE3 (firmware 3.x), or EDBG Integrated Debugger
  -B, --jtag-bitrate <rate>   Set the bitrate that the JTAG box communicates
                                with the avr target device. This must be less
                                than 1/4 of the frequency of the target. Valid
                                values are 1000/500/250/125 kHz (mkI),
                                or 22 through 6400 kHz (mkII).
                                (default: 250 kHz)
  -C, --capture               Capture running program.
                                Note: debugging must have been enabled prior
                                to starting the program. (e.g., by running
                                avarice earlier)
  -c, --daisy-chain <ub,ua,bb,ba> Daisy chain settings:
                                <units before, units after,
                                bits before, bits after>
  -D, --detach                Detach once synced with JTAG ICE
  -d, --debug                 Enable printing of debug information.
  -e, --erase                 Erase target.
  -E, --event <eventlist>     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"
  -g, --dragon                Connect to an AVR Dragon rather than a JTAG ICE.
                                This implies --mkII, but might be required in
                                addition to --debugwire when debugWire is to
                                be used.
  -I, --ignore-intr           Automatically step over interrupts.
                                Note: EXPERIMENTAL. Can not currently handle
                                devices fused for compatibility.
  -j, --jtag <devname>        Port attached to JTAG box (default: /dev/avrjtag).
  -k, --known-devices         Print a list of known devices.
  -L, --write-lockbits <ll>   Write lock bits.
  -l, --read-lockbits         Read lock bits.
  -P, --part <name>           Target device name (e.g. atmega16)

  -r, --read-fuses            Read fuses bytes.
  -R, --reset-srst            External reset through nSRST signal.
  -V, --version               Print version information.
  -w, --debugwire             For the JTAG ICE mkII, connect to the target
                                using debugWire protocol rather than JTAG.
  -W, --write-fuses <eehhll>  Write fuses bytes.
  -x, --xmega                 AVR part is an ATxmega device, using JTAG.
  -X, --pdi                   AVR part is an ATxmega device, using PDI.
HOST_NAME defaults to 0.0.0.0 (listen on any interface).
":PORT" is required to put avarice into gdb server mode.

e.g. ./avarice --erase --program --file test.bin --jtag /dev/ttyS0 :4242

We have JTAGICE3! We have EDBG!

Now my guesting family will go whopping mad since I must test this some late evening or night in the coming week!

And so I'm over, again, to the PM I'm maintaining to add a few notes on this last "discovery"!

Once again, big thanks to everybody that are involved here!

Not only have I gotten valuable hard advice and encouragement. It just struck me that without you being my "rubber ducks" I would probably have gotten lost, frustrated and given up about a week ago! So: Once again, thank you all!

Stay tuned for an upcoming test run of AVARICE and GDB. And then hopefully NetBeans (or any GDB-enabled IDE) on top of that!

Aside: By Golly!, do I like my shiny new Mint! It's almost like a VAX/VMS system... ;-)

Long time..

This has been pushed to the backlog for quite a while now, but I've picked it up again, at least temporarily. I should read through the thread to see what I've told, but it's late so here's just a short update and a few questions:

• I am now concentrating fully on getting this to work on Linux Mint (but am using Windows occasionally to verify working hardware etc). 
• As reported earlier, I have successfully built both AVRDUDE and AVaRICE on Linux Mint.

After a quick survey of NetBeans, CodeBlocks and latest Eclipse (Oxygen) I actually ended up with going for Eclipse with the AVR Plugin for now. It was what worked best "out-of-the-box".

Current hardware setup is an Atmel-ICE connected to an ATmega2560 on the JTAG interface.

Regarding AVRDUDE

I couldn't get AVRDUDE to actually program the AVR. I went back to Windows and checked the setup using Atmel Studio. It prompted for an update of the Atmel-ICE firmware so did that, and the setup worked. Device signature and fuses read successfully.

Next, I tried AVRDUDE on Windows. After installing a filter driver I succeeded.

I returned to Linux Mint and foolishly assumed something like a filter driver was necessary there too, but Googling gave nothing. On a whim I then tried running AVRDUDE again and succeeded! I strongly suspect that it was the  firmware upgrade that did it. Foolishly I didn't take good notes on what the old firmware version was but IIRC it was very low i.e. 1.0.0 or some such.

Question 1: Can anyone (Morten, are you here?!?) confirm that early versions of the Atmel-ICE firmware will not work with "current" AVRDUDE? If I'm correct re this, does anyone know at what firmware version the "crucial" change was made? (Need this for my eventual "write-up").

Question 2: Somewhere (I know, I know..., but I've missed to take notes on where) I've read that to connect AVRDUDE to Atmel-ICE the last four digits of the ICE serial number needs to be given on the command line, like so:

C:\...\avrdude-6.3-mingw32> avrdude -c atmelice -P usb:47:35 -p ATmega2560

By sheer accident I left that out when testing on Linux Mint and AVRDUDE did behave well without it:

~/Build/avr/avarice/avarice-code-372-trunk/src $ avrdude -c atmelice -p m2560

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.07s

avrdude: Device signature = 0x1e9801 (probably m2560)

avrdude: safemode: Fuses OK (E:FF, H:11, L:E2)

avrdude done.  Thank you.

Is this something that was required but is not required with current AVRDUDE? OR is it varying with operating system? (I have not returned to Windows to test there, yet...)

Regarding AVARICE

I'm trying to make sense of the AVaRICE command line. Bear in mind that I'm a total novice using AVaRICE.

I was hoping I could verify that AVaRICE connected to the Atmel-ICE and that it in turn communicated with the AVR. The AVaRICE --help about the -r switch says 

-r, --read-fuses                     Read fuses bytes.

 

so I was hoping that by doing e.g.

~/Build/avr/avarice/avarice-code-372-trunk/src $ ./avarice -4 -P atmega2560 -j usb -r

I could verify "the whole chain", but it yields nothing but

AVaRICE version 2.13svn20160229, Aug  2 2017 14:55:02

Defaulting JTAG bitrate to 250 kHz.

~/Build/avr/avarice/avarice-code-372-trunk/src $

i.e. no "reaction" at all indicating any successful attachment/communication, and return immediately to command line. It's not a matter of "sudo" - I've tried that. Also tried specifying a port - same result. Also tried -C for "capture  running program" - same result.

Question 3: Am I "mis-assuming" what the -r switch should do? Is there any other way to verify that AVaRICE talks properly to the AVR?

I'm not even sure that the above connects even to the Atmel-ICE. I'd like to have some way to verify that, and connection with the AVR, before I move on..

(Yes, I've checked the JTAG fuse: Running the fuse bytes, read out with AVRDUDE, through http://www.engbedded.com/fusecalc verifies that JTAG is enabled.)

Testing AVRDUDE programming and AVaRICE debugging

I am doing some serious testing using two dongles

• Dragon
• Atmel-ICE

and three target systems

• ATmega88 (sitting on a STK500, but essentially just for power and ease of connection - e.g am not using the STK500 on-board ISP (yet?))
• ATmega328P (on an Arduion Uno)
• ATmega2560 (sitting on a STK600, again just for power)

I am testing both AVRDUDE and AVaRICE. For AVaRICE I am just trying to get it to the state where it says "waiting for connection on port nnnn", i.e it is ready for GDB to connect.

This gives me 14 test cases, since I am testing both AVRDUDE and AVaRICE:

AVRDUDE

• 6 cases using AVRDUDE, ISP programming (3 devices x 2 dongles)
• 2 cases using AVRDUDE, JTAG programming (1 device x 2 dongles)

AVaRICE

• 4 cases using AVaRICE, DebugWire debugging (2 devices x 2 dongles)
• 2 cases using AVaRICE, JTAG debugging (1 device x 2 dongles)

The (tentative) results

AVRDUDE works for all 8 cases.

AVaRICE works when using the Dragon doing JTAG debugging on the mega2560, but not for the other 4 cases. It seems to boil down to these two problems:

• debugWire devices can not enter/initiate a debugging session (regardless of dongle and device used).
• JTAG debugging does not work for the Atmel-ICE (regardless of the device used). AVaRICE just reports version and bitrate and then silently exits.

As you can see, these two overlap somewhat, but I believe the latter is a sign of AVaRICE not having support for Atmel-ICE (or it is buggy). I will try to investigate this further (I do have the source, and if I fail I will try to ask Jörg nicely for some help...)

For the debugWire problem I still need to cross-check and verify that dW debugging works for my hardware in Atmel Studio. I wonder if it is the case that AVaRICE will not do the enabling of the DWEN fuse? (I just might risk messing with the fuse, having Studio leaving it programmed and then switch back to Linux to test again.)

The good part!

I have one setup/combo where everything works (both AVRDUDE and AVaRICE): The Dragon + ATmega2560. I will try to proceed to actually getting a GDB on top of AVaRICE using that, so I'm still moving forward! (But by golly, is this tedious... ;-)

Well, Jim..

I've been taking this monster on several times, and given up, but this time is different (I hope). The crucial change is that I'm now on Linux 95% of the time. If I can get OCD working it'll be 99% - and a sense of security for the future (no Windows 10!).

I've never been this close before, and as long as I'm seeing possible progress I'll stick to it - time permitting.

Also, as you may deduce from the 100+ posts above, I'm seldom for doing things "by cook-book". I want to understand and feel that I master what I'm doing. I have this "rule": If I know something well enough that I can explain it to someone else - then I know it. That plays a part in why this takes so long.

I'm amazed that some of you are still following this, and not disappointed by the fact(?) that most probably have given up on my ramblings. I still write, since composing a "post of progress" is a way to make sure I my thoughts are in good order. For me, writing just does that..

Thanks for the encouragement!

@gchapman: Thank you! vI'll have a better look at all that when time permits. But at a first glance I see no coverage of debugging for AVRs in "Unified Debugger". I find lots and lots of ARM stuff though, so it is interesting in the longer term! Under Boards, Atmel I see only SAM ARM stuff, and under Boards, Arduino are only ARM-based Arduinos.

I do have the ambition to get SAM ARM debugging going eventually, and I expect this to not be the same struggle as with AVRs since there is a cross-manufacturer standard (CMSIS-DAP).

Let's stay with AVRs here, please. I'll be happy to start an SAM ARM on-chip debugging thread, if you want to contribute more on that matter! As I said, I'm interested in going for the SAM ARMs eventually but need to concentrate on one thing at a time.

Nothing but AVRs, please...?

Again, I'll be happy to start a thread where we can deal with "the rest". Also, I admit to sometimes being "all over the place", but my concern here is that this thread is at ~150 posts, and there will be more.

So.. Please?

Perhaps, but seeing is believing. Until then, it's vapour-ware.

And since PlatformIO is open source (yes?) then why do they need contact with Atmel? They could just adopt AVaRICE?