Once again: Debugging with GDB

Go To Last Post
166 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Freaks!

 

 

 

I'm pondering taking a new stab (far-fetched pun intended) on finding a complete development environment for AVRs other than Atmel Studio. The critical thing is on-chip debugging. The goal is to move away from Windows before the only viable Windows-alternative is the dreaded Windows 10.

 

I'm thinking of this as a multi-stage rocket. To begin with I will work on Windows to have a setup that does not rely on Studio, but will use things that came with the Studio install (toolchain, system libs and headers...).

 

My IDE of choice to begin with will likely be NetBeans. I already have it working with the C compiler targeting Windows (i.e. to write programs that executes on Windows). I am confident I will get it working with the Atmel toolchain that came with Atmel Studio.

 

Programming/debugging hardware will be an Atmel-ICE (and, if that is too new for AVRDUDE, then I can fall back to a Dragon).

 

Starting out:

 

1. Get NetBeans working with the toolchain from the Studio install to build an ELF.

 

2. Convince NetBeans to create the Intel Hex file from the ELF.

 

Flash programming:

 

3. I am content with running AVRDUDE from the command line to begin with.

 

Debugging:

 

4. Get a debugging stack running, with ATBACKEND as the "driver" for the Atmel-ICE. I'm hoping to be able to connect to a target system running code downloaded with AVRDUDE. (This is, of-course an intermediary solution.)

 

5. Get the same debugging stack running with AVARICE as the driver. Possible sub-steps:
5a) Get GDB-AVARICE-AtmelICE-target working. Check with simple GDB commands.
5b) Get NetBeans to talk to the stack from 5a.

 

6. Flash programming as first step of debugging session: Get AVARICE to program the firmware when starting a debug session.

 

7. Explore actual debugging possibilities with this setup. How do you watch a variable? A SFR? Breakpoints. Stepping. Etc etc..

 

Once this is working, I might consider moving from Windows to GNU/Linux. At this stage I'm hoping to be familiar with the ins and outs of setting up the stack, and what I can expect of the debugging experience.

The subject has been raised many times here at AVRfreaks, several times by me. I have done some searches for previous threads and found some of them, but not all. I am convinced there was a thread where someone described, in detail, how to set this up, but I'm stumped trying to locate it again.

 

Any hands-on info on how to go about this, explanations on how such a debug stack actually fits together (roles, parameters, ports talked on, etc etc) will be gratefully accepted!

 

I have lost an old list of links to relevant threads on the subject. If anyone has links that are not in my list below, I'm happy if you post them.

 

War-cry: No Windows 10 for me!! I can gladly accept that the debugging experience will not be as "smooth" as in Atmel Studio, if that is what it takes to avoid Windows 10.

 

Promise: If I get this working in any reasonable way I promise I will write and publish a guide/howto on the subject for others to prosper from.

 

Any advice or hard facts that will help me conquer this beast is welcome!

 

[Grovel version: Help! Please...]

 

 



APPENDIX - Some previous threads
 

(Long list!)

 

For any-ones reference, below is a bunch of threads I've found.

 

Format:

    <date> <author>
    <title>
    <link>

    <resume, notes etc>

 


2014-10-03 johanekdahl (me!)
Atmel AVR 8-bitters debugging and GDB
https://www.avrfreaks.net/forum/a...

 

Where I ask questions about how to run a debugging session with GDB, and Morten gives some sweeping "politically correct" answers. [Morten, please don't take that as offensive! I fully understand the position you're in ;-) ]


2017-05-10 mojo-chan
Debugger
https://www.avrfreaks.net/forum/l...

 

Where mojo-chan and clawson has an interesting discussion on debugging on Linux with a stack like <Some IDE> - <avr-gdb> - <avarice> - <debug dongle> - <target AVR>. I chime in with some brou-ha-ha. 

Then Morten mentions a "debug adapter for Visual Studio Code". VSC can run on other platforms than Windows, but the "debug adapter" only talks to atbackend so that seems to be a dead end for Linux. (Besides, I'm after something that plugs into any of the cross-platform IDES like Eclipse, NetBeans, CodeBlocks...)

THere are hints of a Linux build of atbackend being built and existing inside Atmel/Microchip, but again (fully understandably) Morten is secretive.

Morten then goes into specifics about the atbackend "upwards" protocol - its based on TCF (an open Eclipse standard - http://www.eclipse.org/tcf/ ). I'm not sure what to make out of that. Yet..


2016-03-03 sq5rix 
Atmel-ICE, avarice, Eclipse and debugging in Ubuntu
https://www.avrfreaks.net/forum/a...

 

sq5rix has built AVARICE on GNU/Linux, and got the connection between AVARICE and GDB working. He then runs Eclipse but fails to start a debugging session. I have not dug into what he's experiencing - I'm just to inexperienced with this to "get it".


PDF: Howto develop AVR programs using the Code:Blocks IDE
https://www.avrfreaks.net/sites/d...

 

I'm sure that there is a link to this PDF in some thread, but have not been able to locate it...

And I have still to read it.


2007-04-23 nleahcim
debugging with winAVR?
https://www.avrfreaks.net/forum/d...

 

An older discussion where debugging is touched upon. INcluded here just because Cliff uses the term "Porcine aviation" which I find wonderful.. ;-)


2013-08-10 Microgala
AVR GCC Debug in Eclipse
https://www.avrfreaks.net/forum/a...

 

In post #28 I (!) claim to have a stack of <GDB>-<AVARICE>-<Dragon> up and running. I have no memory whatsoever about doing that! (But can see no point in lying about it so I suppose it's true - this was shortly after I did some work on LuminaryStellaris, and wrestled with integrating OpenOCD and GDB in a stack beneath Eclipse, so I might have known something then that I've forgotten by now..) In the post I speculate about using stuff from the WinAVR distribution, so no good way forward now..


2011-08-31 johanekdahl (me!)
Anyone actually using AVaRice?
https://www.avrfreaks.net/forum/a...

 

A rather old thread, talking about using stuff in WinAVR. Not a path to go down now...


2012-12-22 martinus26
AVR eclipse linux hw debug
https://www.avrfreaks.net/forum/a...

 

An attempt at <Eclipse>-<GDB>-<AVARICE>-<Dragon> . Fails in Eclipse "at 97%"..


2015-10-04 Vcros
Debugging Atmega128 in NetBeans IDE
https://www.avrfreaks.net/forum/d...

 

Asking about debugging using NetBeans.

I answer in general terms. Comes to nothing..


2016-03-02 PaulVdBergh
Debugging with Dragon in Eclipse under Debian 8
https://www.avrfreaks.net/forum/d...

 

Paul asks the eternal question. Does not come to anything specific..


2015-12-05 dallas_clement
debugging SAM D21 with gdb / openocd
https://www.avrfreaks.net/forum/d...

 

Talks about debugging SAM D21 using OPENOCD. Not re AVRs as such, but included here as it might hint to the general structure of the "stack setup".


jps 2010-10-20
Debugging with AVR plugin for Eclipse
https://www.avrfreaks.net/forum/d...

 

Claims successful - using "AVR plugin for Eclipse". See  http://avr-eclipse.sourceforge.n... ! A detailed description of involved software and setup.

I have still to read this in detail..


END OF LIST

 

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

More power to you, Johan!

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Following with anticipation!

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

May you create joy!

 

JohanEkdahl wrote:
Programming/debugging hardware will be an Atmel-ICE (and, if that is too new for AVRDUDE, then ...
Atmel-ICE is in AVRDUDE 6.3 and AVaRICE (post 2.13, r358 and subsequent)

AVaRICE r347 (post 2.13) has JTAGICE3.

JohanEkdahl wrote:
4. Get a debugging stack running, with ATBACKEND as the "driver" for the Atmel-ICE.
In the interim, acceptable to operate a virtual machine?  (macOS or Linux host, Windows guest running atbackend.exe)

Reasons :

  • zero price Windows 10 virtual machines; not zero cost due to watermarks, nags, and periodic re-installs of Atmel Studio 7.
  • zero price Windows 8.1 virtual machines

JohanEkdahl wrote:
5a) Get GDB-AVARICE-AtmelICE-target working.
Eclipse-GDB-AVaRICE-JTAGICE3-Arduino should work via PlatformIO 2 but:

  • AVR GDB was removed from PlatformIO 3 replaced by a unified debugger for ARM Cortex-M and TI MSP430.
  • PlatformIO is for a subset of AVR (some megaAVR, some tinyAVR, no XMEGA AVR)

 

P.S.

JohanEkdahl wrote:
The goal is to move away from Windows before the only viable Windows-alternative is the dreaded Windows 10.
There are ways to put Windows 10 in its place.

Otherwise, by operating Windows 8.1 one can kick the can down the road to 2023-Jan.

macOS has greater desktop and notebook usage than Linux; someone could likewise create for macOS (not me for I'm not a macOS operator)

AVaRICE 2.13 (AVR JTAGICE2, AVR Dragon) is in CrossPack AVR with a macOS Xcode 5 integration.

AVRDUDE 6.3 is in macOS Homebrew.

Xcode apparently has a command line GDB interface.

more at https://www.avrfreaks.net/forum/avr-studio-mac-linux

 


AVR Downloader/UploaDEr - News: AVRDUDE 6.3 released

http://savannah.nongnu.org/forum/forum.php?forum_id=8461

...

 

* New programmers supported:

...

- Atmel-ICE (ARM/AVR), JTAG, PDI, debugWIRE, ISP modi

 

...

https://sourceforge.net/p/avarice/code/commit_browser

https://packages.debian.org/stretch/avarice (Debian, stable, AVaRICE, 2.13+svn347-4)

Microsoft

Microsoft

Windows app development

Download a Windows 10 virtual machine

https://developer.microsoft.com/en-us/windows/downloads/virtual-machines

Discover Vagrant Boxes

https://app.vagrantup.com/boxes/search?utf8=%E2%9C%93&sort=downloads&provider=&q=Windows+8.1

via

Vagrant by HashiCorp

https://www.vagrantup.com/

(Find Boxes button)

http://www.ikravets.com/computer-life/programming/2014/06/20/building-and-debugging-atmel-avr-arduino-based-project-using-eclipse-ideplatformio 

PlatformIO Unified Debugger

http://docs.platformio.org/en/latest/plus/debugging.html

Texas Instruments

MSPDS MSP Debug Stack

http://www.ti.com/tool/mspds

http://docs.platformio.org/en/latest/platforms/atmelavr.html#packages 

http://docs.platformio.org/en/latest/ide/netbeans.html

Microsoft

Microsoft

Support Lifecycle

Windows 8.1 Pro

https://support.microsoft.com/en-us/lifecycle/search/17648

https://github.com/obdev/CrossPack-AVR

http://braumeister.org/formula/avrdude (macOS, Homebrew packages, AVRDUDE)

Apple

Developer

GDB and LLDB Command Examples

https://developer.apple.com/library/content/documentation/IDEs/Conceptual/gdb_to_lldb_transition_guide/document/lldb-command-examples.html

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Everyone: Thank you for the cheers!

 


 

I've been trawling the net a lot, and my trawl-fu has not been good. I hoped for some tutorial'/article/whatever that explains a GDB stack in general (not necessarily specific to AVRs), and how things fit together in detail. What to configure. What kind of traffic goes where. What "format" it has.

 

It seems there is a bunch of people "in the know" who never  talk to us that are not in the know.

 

Frustrating. I need to understand this thoroughly in order to work with it..

 


 

gchapman wrote:
There are ways to put Windows 10 in its place.

[Perhaps, but

1) MS seems to invent new cushions for those kicks, as evident by several posts here, making this an eternal kick-boxing fight, and

2) I'm not interested in kick-boxing with Windows10

Please keep that discussion out of here. Lets focus on the ultimate goal of having a truly cross platform debugging setup.

 

I'm starting out on Windows, trying to get debugging going, just to not have too many variables changing at one time. Once/if I get a non-Studio debugging solution up and running it'll be time to move it to GNU/Linux. (Just following my own "small steps" advice..)

 

Likewise, using ATBACKEND is such an intermediary step - just for the learning experience. Interim Windows<whatever> in virtual machines are not contributing to any learning experience.

 

quote=gchapman]macOS has greater desktop and notebook usage than Linux

 

Since all recent Mac OSes are Unix/BSD based then I anticipate a GNU/Linux solution would not be that hard to carry over to Macs.

 

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

6 - don't.
.
Avarice actually says "do the programming with (maintained) avrdude, not this"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Status report:

 

  • Searching the net, reading, thinking and trying to create a "knowledge map" so that I can get some structure to this. I am still in somewhat of a mist here..
  • Fiddling with NetBeans to get it to build an avr-gcc project. I have a problem with make not behaving. Could be something with incompatible versions, NetBeans emitting a makefile that my Make does not like. Sorry no details, but this one does not scare me much. I'll get that sorted.
  • When the Make issue is sorted, I'll turn to generating the .hex file. I am confident I'll get that sorted too - i.e. run objcopy with fitting switches and parameters.

 

Doing the build in NetBeans is not something that is strictly necessary for getting debugging going - but it would be nice. If I, for some weird reason, does not get the build working in NetBeans I can fall back to e.g. running Make on the command line. Again, I'm not worried about Make per se, and the wonderful MFile utility makes this easy.. (-:

 

I will probably let this rest for a day or two no, as I have some unrelated stuff to tend to.

 

But if you have anything to contribute, then please do so. I can use all the help I can get! (-:

 

clawson wrote:
6 - don't. . Avarice actually says "do the programming with (maintained) avrdude, not this"

Noted. I was hoping that starting AVaRICE with the "correct" parameters would be a one-stop for getting the firmware flashed and the session started... So now it looks like

  1. Flash with AVRDUDE
  2. Start AVaRICE
  3. "Attach" GDB
  4. Test debugging with the GDB command line.
     
  5. When that works, move to getting an IDE (e.g. NetBeans) on top of this and debugging from there.

 

This last step is the one I'm excited and curious about. What will the experience be? Can I effortlessly watch variables? Can I watch registers (both GP/CPU and SF/IO)?

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Last Edited: Sun. Jul 2, 2017 - 04:29 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Johan. You do know that there is a switch in AS7 where you can switch between their debugger and avr-gdb? If you switch that in theory you don't actually see any difference in the top level debugging experience. So the bottom line is that, if done right, it shouldn't really feel any different whether AS7 or Eclipse or NetBeans etc. (though I guess each is subtly different in their UI?)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes Cliff, but it's more about what the IDE caters for the experience than what GDB offers. It's obvious that Atmel has put a lot of code into getting some of the debug views nice. Processor and the SFR views especially. I'm just curious re how it will look in another IDE that knows nothing specific about AVRs.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Oh you can't expect SFR/IO like views in non-AS7. What's more you are going to see RAM vars as 0x800060 based (or whatever)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Oh you can't expect SFR/IO like views in non-AS7.
Microsoft Visual Studio has been extended to add some AVR IO :

VisualGDB

Developing firmware for AVR devices with Visual Studio

April 1, 2016

https://visualgdb.com/tutorials/avr/

...

13. You can use the Hardware Registers window to view and quickly change the values of various registers. ...

...

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Oh you can't expect SFR/IO like views in non-AS7.

I understand that. I'm till curious as to how/what I actually can see.

 

gchapman wrote:
Microsoft Visual Studio has been extended to add some AVR IO

Yes, gchapman, but I'm not interested in Visual Studio. Can we please keep it out of this thread? Please?

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:

Microsoft Visual Studio has been extended to add some AVR IO :

JohanEkdahl wrote:

Lets focus on the ultimate goal of having a truly cross platform debugging setup.

Is MVS available for non-Windows platforms (other than Mac)?

 

Never mind...  I have to read/type faster ;-)

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Last Edited: Sun. Jul 2, 2017 - 06:43 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have only a very limited knowledge of GDB But I'm running linux exlusively now for several years.

I'm not much into all the "sophisitaded stuff" and still use self written make files.

Not because I like them, but because of the flexibility they offer.

They let me easily switch between whatever IDE I fancy at any given time without much reconfiburing.

I'm not programming much lately, but I like QT creator for AVR development.

 

Maybe I should update it someday, but this version caters for my needs:

Qt Creator 3.0.1
Based on Qt 5.2.1 (GCC 4.8.2, 64 bit)
Built on Apr 9 2014 at 09:12:59
Copyright 2008-2014 Digia Plc. All rights reserved.

GDB is divided in front ends and back ends, which communicate to each other over a tcp/ip port.

They can both be on localhost, but there can also be a long cable between them for remote debugging.

You can interact with GDB via the command line (handy for testing) but it's usually done via some graphical / mouse clickable  -interface.

Some ide's have direct support for GDB, but you can also use it standalone.

 

My only dabble with debugging an AVR was via a clone of the original avr jtag V1 a long time ago.

Never got it to work (But I also didn't try very hard).

 

Over a year ago I was experimenting a bit with STM32.

I followed the tutorial from "pandafruits", which I truly find marvellous.

A part of the tutorial was getting GDB to connect to the uC via ST-Link V2.

I got this part working in 10 minutes or so.

Unfortunately I haven't had a good project to put these skills to use and most of my knowledge has faded a lot.

I haven't yet tried to connect to it from the QT Creator IDE.

Paul van der Hoeven.
Bunch of old projects with AVR's:
http://www.hoevendesign.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This would be really great! I've always used CLI with avrdude and custom Makefiles after the fall of WinAVR, but keeping the toolchain updated is tricky. Moving from AVR to ARM has caused me to use Atmel Studio to get a feel for things, meaning Windows instead of Linux, and AS7 crashes constantly and doesn't play well with my preferred directory structure. I've done my best to make some crazy Make chains based on Dean's DMBS that auto generate libraries for various architectures and such, cross- compatible with mega and tiny chips... testing with cortex-M0 now.

Respectfully,
Kurt E. Clothier

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

kurt.e.clothier wrote:
but keeping the toolchain updated is tricky
But Atmel keep making "Atmel Toolchain for Linux" available as .tar.gz, what's "tricky" about taking those updates?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

kurt.e.clothier wrote:
but keeping the toolchain updated is tricky
But Atmel keep making "Atmel Toolchain for Linux" available as .tar.gz, what's "tricky" about taking those updates?

 

Here: http://www.atmel.com/tools/ATMEL...

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just found something interesting. If you follow the link back to "source" you get to all the stuff for 3.5.4 but if you go up one level from there you get to:

 

http://distribute.atmel.no/tools...

 

and that has a 3.6.0 here:

 

http://distribute.atmel.no/tools...

 

which might be preferable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry, not tricky to get the updates... tricky to remember to get the updates.

Respectfully,
Kurt E. Clothier

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK, this has been resting for a few days.. I'm thinking of two "experiments" to understand how things fit together - and to get something working, to gsin some self-confidence re the subject.

 

I need any help or tips I can get on on these:

 

1. Run GDB on top of ATBACKEND

As I understand it, these two are enough for getting a rudimentary debug stack up'n'running. I'm content with getting thi to work to the point where I can give any GDB command respond in a reasonable way - to see that this setup works.

 

Does anyone know how to start ATBACKEND. The help is terse, to say the least.

- Will it "discover" my Atmel-ICE by itself, or do I need to tell it something?

 

- Will it discover the target AVR by itself or do I need to tell it something?

 

- I believe it communicates upward (e.g with GDB on a TCP port. Is that correct? Do I need to tell ATBACKEND which port it shall use or is there a standard? Anything else?

 

When I start GDB;

 

- Do I need to tell it on which port it should communicate "downwards" with ATBACKEND?

 

- Do I need to tell it anything about the target AVR?

 

- What is a good first command to GDB to test if the whole chain is working?

 

2. Run GDB on top of AVaRICE

 

I'll start with this simple question:

 

- Where can I get a Windows build (a "binary") of AVaRICE? (I suppose I could extract one out of WinAVR but that would be 7.5 years old by now. Does anything newer exists.

 

If I get my hands on an AVaRICE binary for Windows, then the follow-up questions will more or less be the same as for ATBACKEND.

 

Driver needed?

 

Do I need a driver "beneath" ATBACKEND and/or AVaRICE? Which one?

 

Remember..

These tests are just a first step for understanding the general "infrastructure". The ultimate goal is to run GDB - AVaRICE - (driver?) - JTAGdongle - targetAVR on GNU/Linux.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The only avarice.exe I know of is that Winavr one. I doubt there's much demand for non-Studio debugging in Windows. Avarice comes into its own in Linux where it's basically the only option. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohanEkdahl wrote:
- Where can I get a Windows build (a "binary") of AVaRICE?
A Cygwin version is available on the official AVaRICE page http://avarice.sourceforge.net/

Go to the file download area and there at the top (above the table) is a download link for the latest Cygwin build.

Stefan Ernst

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you both!

 

@clawson: I'd like to not complicate things, so building a recent AVaRICE for windows is out of the question. I might resort to getting a Dragon out of th box with oldish stuff and use the WinAVR build of AVaRICE.

 

@sternst: I'm not a CygWin person. I've learned to avoid if at all possible. too meny times in the distant path I was hit by different incompatible versions of cygwin1.dll. These days I prefer MinGW/MSYS.

 

Repeat: Anyone with advice or hints on how to actually start up ATBACKEND/AVaRICE and GDB in an orderly manner? Any tips or web links to material to get started? I usually get along well searching The Web but here I've sort of come out stumped..

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Try running procexp from sysinternals when AS7 has spawned the backend. I'm pretty sure it will reveal the command line that invoked it.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Nice tip, Cliff! (-:

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Recently I switched most of my development work back from Linux to Windows. It is a very poor development environment for a professional programmer but one of the true highlights for me are the Mark Russinovich tools from SysInternals (later assimilated by M$). They are a shining beacon in helping you understand Windows and its operation.

Last Edited: Sat. Jul 8, 2017 - 07:10 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have got debugging working with NetBeans, OpenOCD and Atmel-ICE.  This is using the ATSAM3X8E (custom Arduino DUE) not an AVR though.  I am going to have a look at doing the same for the AVR's as next.  I'll let you know how I get on.  I'm also using Makefiles as well.  The Makefile is for Arduino based projects.

 

I was using AS7 and Visual Micro previously but it wasn't possible to have real debugging with this set up.  My preference is Linux and I prefer cross platform tools where possible.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@TT_ZX: Is it possible for you to give a short intro to how you get the NetBeans - GCC -OpenOCD - Atmel-ICE - SAM stack up and running? PLEASE!?! I plead, grovel and bow in humbleness! ;-)

 

(On the table ATM is an Atmel ICE and a SAM D20 Xplained board. I am looking for all learning experiences I can possibly find and be successful in!)

 

Re makefiles, I have no problems with that. Not an obstacle.

 

 

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am using Gentoo and have installed openocd-0.10.0.  Create a project folder for you source files and create a config file for OpenOCD:

 

#filename openocd.cfg

# Atmel-ICE JTAG/SWD in-circuit debugger.
interface cmsis-dap
cmsis_dap_vid_pid 0x03eb 0x2141

# Chip info
set CHIPNAME at91sam3x8e
source [find target/at91sam3ax_8x.cfg]

$_TARGETNAME configure -event gdb-attach {
  halt
}

$_TARGETNAME configure -event gdb-attach {
  reset init
}
 

Adjust to suit your chip (atmel_samd20_xplained_pro.cfg I think).  Not attach you Atmel ICE and run openocd in a terminal from inside your project folder.  You should get something like this:

 

Open On-Chip Debugger 0.10.0
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/b...
Info : auto-selecting first available session transport "swd". To override use 'transport select <transport>'.
adapter speed: 500 kHz
adapter_nsrst_delay: 100
cortex_m reset_config sysresetreq
Info : CMSIS-DAP: SWD  Supported
Info : CMSIS-DAP: JTAG Supported
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : CMSIS-DAP: FW Version = 01.26.0081
Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 1 TDO = 0 nTRST = 0 nRESET = 1
Info : CMSIS-DAP: Interface ready
Info : clock speed 500 kHz
Info : SWD DPIDR 0x2ba01477
Info : at91sam3x8e.cpu: hardware has 6 breakpoints, 4 watchpoints

 

That's the first step so get that working and I'll most the next steps soon.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

TT_ZX wrote:
That's the first step

THANK YOU! I am most grateful! This is the first hard advice/help I've seen on how to get going with non-Windows debugging.

I will test it soon(ish).

 

The OpenOCD/SAM case is just as interesting as the AVaRICE/AVR case:

1) I've recently started dabbling with the SAM D family, and

2) There's enough common structure here so that understanding one helps understanding the other.

 

TT_ZX wrote:
I'll [post] the next steps soon

No big hurry - take your time. I have some family business and stuff coming up the next few days and need to get that out of the way first.

 

As promised in my OP, if/when I get stuff like this working I will make the best write-up I can of it. So, no need for you to be nitpicking - as long as I understand and can use what you post, that 's enough!

 

Once again: THANK YOU!

 

Did I say?: THANK YOU!

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Last Edited: Tue. Jul 11, 2017 - 07:33 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This what I use for my toolchain:

https://launchpad.net/gcc-arm-embedded

 

Download the latest version and extract it somewhere convenient.  Now run this command:

path_to_tool_chain/gcc-arm-none-eabi-5_4-2016q3/bin/arm-none-eabi-gdb -iex "target extended-remote localhost:3333"

 

You should get something like this:

 

GNU gdb (GNU Tools for ARM Embedded Processors) 7.10.1.20160923-cvs
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-linux-gnu --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/....
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/....
For help, type "help".
Type "apropos word" to search for commands related to "word".
Remote debugging using localhost:3333
0x0008076c in ?? ()
(gdb)

 

If you got that then the OpenOCD is working.  Now time to make it work in NetBeans.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As I'm currently on Windows I am hoping to get something going on that platform as a first learning experience.

 

I've found these Windows builds of OpenOCD and hope they will work: http://www.freddiechopin.info/en...

 

The release notes talks about support for Cortex-M3, and although there is no talk about supporting the D20 Xplained Pro board there is support for other Xplained boards so I'm having my fingers crossed.

 

The OpenOCD documentation (Users Guide) seems to cover a lot (172 pages!) and is included in these downloads. I'd rather have to much to read than too little! (-:

 


 

Don't get this wrong. The plan is to get this working on GNU/Linux, but I don't have a GNU/Linux machine handy ATM (apart form Virtual Box machines, and I don't want to have any guest/host USB problems in play, at least starting out). The "intermediate plan" is to get a boot'able GNU/Linux onto a USB stick or some such and run from there - until I can allocate and set up a physical machine with GNU/Linux. But first a try to get this running on Windoze. If that fails, I'll go for the intermediate USB stick GNU/Linux.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, let's give some specifics then smiley...

PS > .\atbackend.exe /h
usage: atbackend OPTIONS
Atmel Backend.

/clean                     Start with clean code cache.
/bundles=paths             Specify a semicolon-separated list of bundles or
                           bundle repositories.
/help                      display help information on command line arguments
/config-file=file          load configuration data from a file
/connection-port=port      port used to listen for TCF connections
/websocket-port=port       port used for websocket connections
/start-discovery           start discovery protocol
/no-stdin                  obsolete
/wait                      Wait for a keypress before exiting
/avr8-gdb-ports=ports      Listen for incoming avr8-gdb connections on
                           specified port
/armM-gdb-ports=ports      Listen for incoming cortex M/R arm-gdb connections
                           on specified port
/armA-gdb-ports=ports      Listen for incoming cortex A arm-gdb connections on
                           specified port
/exit                      Exits immediately. Most often used with /clean.
/listen-on-any-ip-address  Listen on any IP address. Default is
                           localhost(127.0.0.1).
/version                   Exits immediately.

The ones you want to have a look at is the -gdb-ports set. Choose the one for the target you want (avr8 or armM). Run atbackend with this set to something (4712 in my case)

PS > .\atbackend.exe /avr8-gdb-ports=4712

Now, for the gdb client. Find the path to the correct one, avr-gdb-py in my case 'cause i'm cool (remember, new terminal, atbackend needs to run somewhere)

"C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-gdb-py.exe" -iex "target remote :4712"

Note the -iex part, this is just 'some command to run when gdb has started'. You can drop it and type it into gdb once it has started as well. The line tells gdb to connect to a target on the remote protocol on local port 4712. Some gobbeldygook later, the terminal says

Remote debugging using :4712
0x00000000 in ?? ()
(gdb)

You're now connected to atbackend acting as a gdb-server. Note that this is just a proof-of-concept implementation and it may go completely nuts at any time :) If your atbackend is set up to log (I run debug versions so it's a lot of logs), you'll see the raw GDB packets being sent in the atbackend terminal.

 

Wait, how do you give the tool, interface, device etc? This is done using monitor commands. In your trusty gdb terminal, type monitor help

(gdb) monitor help
Remote command help:
help       This help text
set        Set debug level
reset      Reset target
tool       Select debug connection
device     Select device to debug
pins       Set pins
props      Set target properties
reg        Set register
mode       Set session mode
(gdb)

Everything that is prefixed with 'monitor' in gdb is sent directly to the gdb-server (atbackend). So, this are the special gdb commands that atbackend implements. 

 

All commands self-document

(gdb) monitor tool
Usage: tool TOOLTYPE [SERIALNUMBER]
  or:  tool list
(gdb)

Let's set up on the simulator

(gdb) monitor tool list
com.atmel.avrdbg.tool.simulator
(gdb) monitor tool simulator

Set the device

(gdb) monitor device
Usage: device DEVICENAME [INTERFACE [INTERFACE_CLOCK_SPEED_IN_HZ]]
(gdb) monitor device ATmega2560

Almost ready for liftoff now, let's load in a elf file

(gdb) file "m2560.elf"
A program is being debugged already.
Are you sure you want to change the file? (y or n) y
Reading symbols from m2560.elf...done.
(gdb)

And, since this is embedded, the normal 'run' command doesn't really work. Let's set a breakpoint on main, reset the device, and run to the breakpoint.

(gdb) break main
Breakpoint 1 at 0xfa: file .././main.c, line 12.
(gdb) monitor reset
(gdb) continue
Continuing.

Breakpoint 1, main () at .././main.c:12
12      {
(gdb) list
7
8       #include <avr/io.h>
9
10
11      int main(void)
12      {
13          /* Replace with your application code */
14          while (1)
15          {
16          }
(gdb) backtrace
#0  main () at .././main.c:12
(gdb) 

(everything after (gdb) is something I write, if that wasn't obvious by now).

 

So, again, this was made inhouse as a complete proof of concept. If your debugger catches fire or the simulator initiates the new skynet, it will be your problem smiley

 

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Morten!

 

THANK YOU! You're a gentleman and our savior on many occasions! All the best!

 

As I said, I'm having some upcoming family business (the more pleasant kind!) mid-week, and I'm hunting for my next job (everyday business as a consultant/contractor..) so prolly won't find the opportunity to test this for the next few days. But towards the week-end I should find the time so nothing you said, or will say, is wasted.

 

THANK YOU!

 

meolsen wrote:
If your debugger catches fire

Oh, they're all original Atmel devices.. Sturdy as hell! E.g can't pry off the USB connectors with a nuclear device if you tried.. Mind you, dropping the AVR One! from 30K feet would probably damage similar to Fat Man, and that (or a paper press) is the only use of it nowadays I suppose.. cheeky

 

Current inventory (IIRC) is 2 Atmel-ICE, 1 JTAGICE-3, 4 AVR Dragon (2nd generation), 1 AVR One!. So, I have backups if smoke emerges.

 

Not that it will, but I get the message in your disclaimer wink

 

Did I say?: THANK YOU!

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@JohanEkdahl: I don't expect you to have any problems getting this working on Windoze.  I plan to do this as well so we'll see who gets to it first wink.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Once you have NetBeans installed you'll need to install plugins, C/C++ and Gdbserver, which may not be installed by default.  Now you need to set up your toolchain by going to Tools/Options.  On the C/C++ tab, add a new Tool Collection and fill in the paths to the toolchain you extracted earlier:

 

You will obviously need to adjust the paths to suit.  I'm not sure what is required for Make and Cmake on Windoze.  Maybe you will already have these installed.

 

Now click the Versions button to confirm all the required libraries are available.  This is what I get:

 

To be able to build and program via the Atmel ICE got to Run/Set Program Configuration/Customize.  Now go to Manage Configurations and add a new configuration.  Select the new configuration go to Build.  For Tool Collection, set this to the Tool Collection you just added.  Set Configuration Type to Make File.  Go to Run and enter 'openocd -f openocd.cfg -c  "program ${OUTPUT_PATH} verify reset exit"' without the single quotes.

 

Now you just have to hit the Run Project button and watch the magic happen (if you have the OpenOCD running in the backgroud, you will need to kill this first).  Your project will be compiled and them flashed onto the CPU with the Atmel ICE.  Or if not, you'll have to find what I've missed cheeky.

 

 

Last Edited: Tue. Jul 11, 2017 - 10:12 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

To start a debug session run OpenOCD in a terminal and leave it running.  Go to Debug/Attach Debugger.  In the Debugger drop down select gdbserver.  Set Target to "ext: 3333" without quotes.  The Target box appears greyed out to me but I could still type this in.

Now click OK.  You should now be attached to your debugger and should get these lines in the terminal you have OpenOCD running:

 

Info : accepting 'gdb' connection on tcp/3333
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x0008076c msp: 0x20088000

 

 

You can now Pause, Step read and manipulate variables and all the good stuff I've never had the opportunity to do until recently.

 

So the one gotcha I haven't worked out is how to start and attach to the GDB server by just hitting the Debug Project button.  I not sure this is possible because of how the gdbserver plugin is implemented.  It's not a big deal but it would be nice.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hmmm. Lost a long post here.. Short version:

 

You guys are stellar!

 

 

@TT_ZX: Tell me if you're  preparing a serious/ambitious/long writeup. I have an embryo for such, and enjoy writing. But if you're already ahead of me there then I'll rather do other stuff. Aga in, I enjoy writing stuff. Just don't wanna double work, so let me know. (-:

 

My embryo will have four parts:

 

Part 1 : Introduction, overview, document info

Part 2: Shortest possible cook-books/recipes. If they work the user/reader is lucky and can hop to Part 4. If not, Part 3 applies.

Part 3: Details about the components/modules/softwares involved, what they do, how they interact with other parts, and everything I have learned about fault-seeking them.

Part 4: When everything works, how do you use it? What can you do? Etc.

 

I'm off for the family gathering tomorrow. Might not be here again until the week-end. And am I looking forward to trying all this out!

 

Thanks, for now!

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@JohanEkdahl: I'm not planning on doing any write ups.  TBH I'm not very good at it even though English is my first language.  I just wanted to share the info I've found mostly trawling the net and by trial and error.  I look forward to seeing your write up though.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, well.. I actually started out testing this yesterday late evening. Didn't come far though. The gdbserver plug in crashed my NetBeans install. Tried to both disable the plugin and uninstall it, to no avail..

Mind you, my NB is a bleeding edge development version - IIRC I needed that for some Groovy/Grails stuff I was playing with a few months ago. Let's hope an un/re-install solves it. But now it'll have to wait until the weekend.

I'll be back!

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just to let you know I haven't abandoned this, and any of your efforts above was wasted..

 

Status report:

 

I'm on to this again.

 

Yesterday I fixed my broke NetBeans setup(s). Yes, I've set up two - one (the "bleeding edge", for Groovy/Grails development) and one stock 8.2 for C/C++ and eventually AVR development and debugging tests. Last time the gdbplugin to NetBeans broke my NBs. (This time I'll run my hard disk imaging before trying anything.. ;-) )

 

Today my primary goal is to set up and verify hardware for the experiments. It'll likely be an ATmega2560 (on an STK600) and a Dragon (2nd gen). Both needed firmware updates. [1] I'm also tempted to do some similar tests for the SAM D20 (with OpenOCD in place of AVaRICE.

 

Then (today? tomorrow?) it's on to actually testing some of the stuff from TT_ZK and Morten above. Wish me luck..

 


 

There's one thing I worry about:

 

I've managed to keep away from "semi-bricking" AVRs with debugWire (not exiting debug session in proper way etc...). So, how is this leaving the debug session done "at the low-level". Is this about some specific GDB command, or what?

 

As I said above, I'm starting out with an ATmega2560 ... for a good reason. It's JTAG (not debugWire) so the above problem is not an immediate one.

 

Still, if someone has any light to shed on the "exit a debugWire session properly" subject, I'm all ears..

 


 

[1] The one trouble so far is that the Device Programming dialog in Studio hangs occasionally when using the Dragon from there. In case Morten is still around and is interested, here's what I get:

 

 

If I choose Wait 1 more minute the dialog hangs, and eventually I get that message again. Never stops, it seems.. Gotta kill Studio with Task Manager. Then I of-course forgot that Studio can leave its droppings as running processes, i.e. ATBACKEND. Gotta kill that one too, or Studio just keeps on acting up when started again.. There is some serious mis-design - or lack thereof - here, Atmel.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Last Edited: Sun. Jul 16, 2017 - 10:58 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Morten, if you're here...

 

Heres my startup of the ATBACKEND:

 

C:\Users\JohnDoe>"c:\Program Files (x86)\Atmel\Studio\7.0\atbackend\atbackend.exe" /avr8-gdb-ports=4712

And, in a new terminal window, I start up GDB:

 

C:\Users\JohnDoe\My Documents\Atmel Studio\7.0\OCD\STK600Blinky\Debug>"C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-gdb.exe" -iex "target remote :4712"
GNU gdb (AVR_8_bit_GNU_Toolchain_3.6.0_1734) 7.8
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-w64-mingw32 --target=avr".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.atmel.com>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
Remote debugging using :4712
0x00000000 in ?? ()

(gdb) monitor tool
Usage: tool TOOLTYPE [SERIALNUMBER]
  or:  tool list

(gdb) monitor tool list
com.atmel.avrdbg.tool.simulator
com.atmel.avrdbg.tool.stk600    0048395C6FB2
com.atmel.avrdbg.tool.avrdragon 00A200014633

(gdb) monitor tool avrdragon

(gdb) monitor device ATmega2560

(gdb) file "STK600Blinky.elf"
A program is being debugged already.
Are you sure you want to change the file? (y or n) y
Reading symbols from STK600Blinky.elf...done.

(gdb) break main
Breakpoint 1 at 0xfa: file .././main.c, line 16.

(gdb) monitor reset

(gdb) continue
Continuing.

At this point it crashes:

 

 

The problem details are:

 

Problem signature:

  Problem Event Name: APPCRASH

  Application Name: atbackend.exe

  Application Version: 1.13.0.4749

  Application Timestamp: 58bd8897

  Fault Module Name: com_atmel_debugger_core.dll

  Fault Module Version: 1.13.0.4749

  Fault Module Timestamp: 58bd88ef

  Exception Code: c0000005

  Exception Offset: 00121844

  OS Version: 6.1.7601.2.1.0.256.48

  Locale ID: 1053

  Additional Information 1: 0a9e

  Additional Information 2: 0a9e372d3b4ad19135b953a78882e789

  Additional Information 3: 0a9e

  Additional Information 4: 0a9e372d3b4ad19135b953a78882e789

 

Read our privacy statement online:

  http://go.microsoft.com/fwlink/?...

 

If the online privacy statement is not available, please read our privacy statement offline:

  C:\Windows\system32\en-US\erofflps.txt

 

Any ideas?

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Last Edited: Sun. Jul 16, 2017 - 01:13 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Debug interface and speed at least... Think it's set in the device command.

Re debugWire, there's no magic done. If the device is in debugWire mode (from studio for instance), then it should just launch. Enabling/disabling debugWire would need atprogram to set up the device correctly.

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Morten! I am fully aware of your "position" and respect that not everything can be talked about. Proceed at will.. ;-)

 

meolsen wrote:
Debug interface and speed at least... Think it's set in the device command.

I think I can investigate how to handle "speed", but "Debug interface" in very generic. Too generic for my current knowledge level. Can you be more specific?

 

meolsen wrote:
Re debugWire, there's no magic done. If the device is in debugWire mode (from studio for instance), then it should just launch. Enabling/disabling debugWire would need atprogram to set up the device correctly.

Can you be more specific about what "correctly" might be?

 


 

Meanwhile, I tried running using the simulator rather than the Dragon and it works slightly better. I can actually single step, but while doing that I seem to just fall out of my main loop. Here's my code:

 

[The web-site code editor is acting up again. So, you'll get it as text. I at least managed to change to a non-proportional font..]

 

#include <avr/io.h>
#define F_CPU 8000000UL
#include <util/delay.h>

int main(void)
{
  DDRD = 0xFF;
  while (1) 
  {
    PORTD = 0x00;
    PORTD = 0xFF;      
  }
}

 

So, I start ATBACKEND and then (yes, in a new command window) I will start GDB. In a command file (settings.gdb) I have the first things to be done:

 

monitor tool simulator
monitor device ATmega2560
file "STK600Blinky.elf"
break main
monitor reset
continue

 

Starting up GDB:

 

C:\Users\johan\Documents\Atmel Studio\7.0\OCD\STK600Blinky\Debug>"C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-gdb.exe" -iex "target remote:4712"
GNU gdb (AVR_8_bit_GNU_Toolchain_3.6.0_1734) 7.8
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-w64-mingw32 --target=avr".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.atmel.com>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/....
For help, type "help".
Type "apropos word" to search for commands related to "word".
Remote debugging using :4712
0x00000000 in ?? ()
(gdb)

 

Running my startup commands from the file:

 

(gdb) source -v settings.gdb
setup.gdb: No such file or directory.
(gdb) source -v settings.gdb
+monitor tool simulator
+monitor device ATmega2560
+file "STK600Blinky.elf"
+break main
Breakpoint 1 at 0xfa: file .././main.c, line 7.
+monitor reset
+continue

Breakpoint 1, main () at .././main.c:7
7         DDRD = 0xFF;
(gdb)

 

Now watch me step a few times...

 

(gdb) step
10          PORTD = 0x00;
(gdb) step
11          PORTD = 0xFF;
(gdb) step
0x00000104 in exit ()
(gdb)

 

Now, that looks to me like I'm falling out of the loop. I tried stepping further but it is clear that I've fallen out of the loop.

 

I'm stumped.. And worried. It seems to me that all the components are talking to each other, but GDB and/or the simulator is simply not behaving.

 

EDIT: I've verified that when stepping the code in Studio I do not fall out of the loop.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Last Edited: Sun. Jul 16, 2017 - 05:35 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

monitor device ATmega2560 JTAG 250 ish... Use the help command...

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@TT_ZX if you're still around!

@Morten, with the usual "you have the right to remain silent" and if you still can bear with me..

 

BACKGROUND:

I tore down the ATmega setup and pulled out the SAM D20 Xplained board to see if my luck would turn. After meddling a while with how to point to the .cfg file I ended up with this, where I at least can get OpenOCD started and the openocd.cfg file is read:

 

<projet-root>
  |
  +--main.c (and other source files)
  |
  +--astudio
       |
       +--openocd.cfg
       |
       +--openocd-0.10.0
            |
            +--bin-x64
            |     |
            |     +-- openocd.exe
            |
            +--scripts
                 |
                 +--board
                      |
                      +-- atmel_samd20_xplained_pro.cfg

This project setup looks, and is, a bit weird IMO. But it works, e.g. building and running/debugging in Atmel Studio. It's a project setup that avoids all ASF goo, with minimal startup code and a simple HAL to handle I/O ports. I'll work on converting this to a more "standard" project later. I mention this because you will see some partial paths below and without this info you will probably be confused..

 

Point is, it works.  And I get a bit on the way with OpenOCD. Here goes..

 

My openocd.cfg looks like this:

#filename openocd.cfg
# Atmel-ICE JTAG/SWD in-circuit debugger. 
interface cmsis-dap
cmsis_dap_vid_pid 0x03eb 0x2141
# Chip info
set CHIPNAME atsamd20j18
source [find ./openocd-0.10.0/scripts/board/atmel_samd20_xplained_pro.cfg]
# C:/Users/johan/Documents/Atmel Studio/7.0/OCD/Taradov/astudio/openocd-0.10.0/scripts/board
$_TARGETNAME configure -event gdb-attach {
  halt
}
$_TARGETNAME configure -event gdb-attach {
  reset init
}

I now start OpenOCD:

C:\Users\johan\Documents\Atmel Studio\7.0\OCD\Taradov\astudio>openocd-0.10.0\bin\openocd.exe
Open On-Chip Debugger 0.10.0
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
Warn : Interface already configured, ignoring
Info : auto-selecting first available session transport "swd". To override use 'transport select <transport>'.
none separate
adapter speed: 400 kHz
cortex_m reset_config sysresetreq
Error: unable to find CMSIS-DAP device

I know that OpenOCD manages to read the .cfg file - before sorting out the source line in it I got an error because OpenOCD could not find the .cfg file.

 

BUT... Look at the last line: "Error: unable to find CMSIS-DAP device".

 

I am clueless about what to make of that.

- I have closed Atmel Studio.

- I have disconnected and reconnected the Xplained board. 

- There is no ATBACKEND running (my understanding is that it should NOT be running when using OpenOCD).

- Looking in Windows Device Manager there is a "EDBG Virtual COM Port (COM3)".

 

QUESTIONS:

Do you see anything obvious?

Do I need to tell OpenOCD where to find the EDBG device? Tips on how?

 

Yes, I am on my way into the OpenOCD documentation. Tomorrow. I'm old enough to know when to stop, e.g.

- When you're too tired

- When you've made no progress for a long time ("sleep on it..")

- When you're frustrated ("not a productive state of mind")

Right now I qualify on all three counts, so I'll call it a day.

 

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

meolsen wrote:
monitor device ATmega2560 JTAG 250 ish... Use the help command...

 

OK, I'm officially "daft".

 

"the help command" where? I wasn't expecting

(gdb) help monitor device

to work, but tried it anyway. Of-course it didn't say more than "Send a command to the remote monitor (remote targets only)." , i.e. as if I asked

(gdb) help monitor

Either my help command is ill formed, or I'm asking at the wrong place. I suspect the latter. The alternative would be ATBACKEND, but...

> "C:\Program Files (x86)\Atmel\Studio\7.0\atbackend\atbackend.exe" /help

usage: atbackend OPTIONS
Atmel Backend.

/clean                     Start with clean code cache.
/bundles=paths             Specify a semicolon-separated list of bundles or
                           bundle repositories.
/help                      display help information on command line arguments
/config-file=file          load configuration data from a file
/connection-port=port      port used to listen for TCF connections
/websocket-port=port       port used for websocket connections
/start-discovery           start discovery protocol
/no-stdin                  obsolete
/wait                      Wait for a keypress before exiting
/avr8-gdb-ports=ports      Listen for incoming avr8-gdb connections on
                           specified port
/armM-gdb-ports=ports      Listen for incoming cortex M/R arm-gdb connections
                           on specified port
/armA-gdb-ports=ports      Listen for incoming cortex A arm-gdb connections on
                           specified port
/exit                      Exits immediately. Most often used with /clean.
/listen-on-any-ip-address  Listen on any IP address. Default is
                           localhost(127.0.0.1).
/version                   Exits immediately.

> "C:\Program Files (x86)\Atmel\Studio\7.0\atbackend\atbackend.exe" /help device

..same output as above..

 

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

BUT... Look at the last line: "Error: unable to find CMSIS-DAP device".

The PID of an EDBG is (usually) 0x2111, not 0x2140

 

"the help command" where? I wasn't expecting

(gdb) monitor help

Remember, monitor means 'send everything to the remote target', in this case atbackend. 

 

I think 

(gdb) monitor device

Should return its syntax...

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks, Morten! 

 

Re the help, I obviously need to sleep on it.. ;-)

 

Re the PID .. likewise, but even if I would realize it was the PID that was wrong I'm not sure how I would have found the correct PID out without you telling me. You probably saved me many hours right there. (I won't test it tonight, though. I'm old enough to...)

 


 

Any thoughts on the "falling out of the loop"? Or are you suggesting that also to be a consequence of bad "Debug interface and speed" things?

 

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

To find the VID:PID, go to device manager/HID-compliant device. Then go to Details/Property/Hardware Ids.

You can see my Atmel-ICE is 03EB:2141.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Any thoughts on the "falling out of the loop"? Or are you suggesting that also to be a consequence of bad "Debug interface and speed" things?

No, if that was the case you wouldn't be able to debug at all. Did you try another step, did it loop back or did it continue into _exit?

 

You can see my Atmel-ICE is 03EB:2141.

Or, you can look in the \tools\{toolname}\{toolname}.xml file. EDBG for instance:

  <Connection type="USB" name="com.atmel.avrdbg.connection.cmsis-dap">
    <VendorId>0x03EB</VendorId>
    <ProductIds>
      <ProductId>0x2111</ProductId>
      <ProductId>0x213A</ProductId>
      <ProductId>0x2157</ProductId>
    </ProductIds>
  </Connection>

 

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohanEkdahl wrote:
Still, if someone has any light to shed on the "exit a debugWire session properly" subject, I'm all ears..
avrdude has a command line option for this now I believe.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I now have NetBeans debugging working with AVARICE and my newly acquired Dragon.  AVR support in OpenOCD with the Atmel-ICE is not complete yet according what I have read.  I haven't tried hard to get OpenOCD working with the AVR so it might be possible.  AVARICE seems to work fine so no need to look any further at this stage.  I was concerned that the NetBeans gdbserver plugin was not going to be compatible with AVARICE but so far it seems to work.

 

Now all I have to do is clean up my configurations and directory structure a bit and get myself more familiar with NetBeans.  I haven't used NetBeans before this exercise but I like what I've seen so far.

 

@JohanEkdahl: How are you getting on with your set up?  Maybe I will try and duplicate my set up on my Win 7 laptop once I am happy with it to check if there's any gotchas.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

TT_ZX wrote:
@JohanEkdahl: How are you getting on with your set up?  Maybe I will try and duplicate my set up on my Win 7 laptop once I am happy with it to check if there's any gotchas.
 

 

Since I have some completely different things to tend to besides this (e.g. a fair bit of house-renovation), and to avoid going insane ;-) , I'm trying to limit work on this to two times a week. In longer passes. (The sunday stint above was 8 hrs including breaks..). Where it's at right now, short stints are not the best. E.g. I need to repeat things from scratch "to make sure", take notes to know and remember what I have done etc.

 

Without looking at my notes I can't even tell where I'm at re the Dragon and an 8-bit AVR.

 

What I did after Sunday was to test the PID for the SAM D20 Xplained EDBG that Morten gave, and it seemed to work. For the moment, I stopped there. The SAM/OpenOCD track is very interesting eventually, but for now it only serv es as "additional learning experiences" re GDB. The first real goal is to get 8-bit AVR OCD going.

 

So, no, I have not given up. Next stint tomorrow, hopefully..

 

The plan ATM: Test out the SAM/OpenOCD stack  - just to not leave that at an open end - and then perhaps see if I can tack NetBeans onto that. But then definitively back to AVaRICE and the Dragon.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK, looking through the sunday posts in this thread it seems I've lost a post there..

 

Problem is to get an AVaRICE  build for Windows.

  • Of-course it's not in the Atmel AVR Toolchain for Windows - I never expected that.. ;-) 
  • There seems to be a build here: https://sourceforge.net/projects... , but that says "requires Cygwin" and that is something I avoid like the plague [1].

 

So a bit of a dead end here. I'd like not to go into a siding here, trying to build AVaRICE myself (using MinGW/MSYS, which IMO is the modern(ish) way to do things like this).

 

I do have a MinGW/MSYS setup with a C/C++ toolchain targeting Windows working, if this becomes necessary. But I'd rather try to have focus on one thing, rather than juggling a lot of different things at the same time. And there's always the possibility that my own build introduces a problem that isn't in official builds and that no-one can repeat, understand or help in the matter..

 

So, if anyone knows where to find a recent AVaRICE build for Windows, not requiring Cygwin, I'm all ears!

 


 

[1] For many years Microsoft was critiqued for creating the foundations for "DLL hell". The problem was well known, and you'd think people had learned.. Then when Cygwin surfaced and some thick-head(s) decided (?) to produce several versions of Cygwin1.dll over time, and make them incompatible with each other. Stupid or plain evil. I won't touch Cygwin1.dll with a ten-foot pole if I can avoid it. I certainly will not write any HOWTO or recommendation that says "Use Cygwin". Ever. Period.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I downloaded the source tree for AVaRICE, and found a note from Eric Weddington, dated 2003-09-26. A very old note for sure, but it says:

To build avarice for Windows requires the use of Cygwin
<http://www.cygwin.com/> Specifically, this was built using the Previous
package of Cygwin. In the Cygwin installer, select the Prev radio button up
top when installing the packages. This should install cygwin 1.3.22-1, from
the Base tree in the Cygwin setup.

If that still holds it illustrates perfectly the problem with Cygwin..

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohanEkdahl wrote:
Then when Cygwin surfaced and some thick-head(s) decided (?) to produce several versions of Cygwin1.dll over time, and make them incompatible with each other. Stupid or plain evil. I won't touch Cygwin1.dll with a ten-foot pole if I can avoid it.
But Microsoft have been doing that for years. How many different copies of gdi.dll or kernel.dll are there for example? The "DLL hell" thing is *supposed* to be solved by WinSxS (Windows Side by Side). Each similarly named DLL now contains a "manifest" (block of XML) embedded in the binary of the DLL and then Windows DLL loader now not only tried to LoadLibrary("gdi.dll") but a very specifically version numbered copy of the same.

 

Cygwin1.dll's should have manifests these days.

 

The only thing is you can't just copy such a DLL onto a PC an expect it to be found. It has to be properly installed into the WinSxS cache (sometimes known as "the aassembly") so that the DLL loader is aware of its manifest in the lookup database when it make a load attempt. For example these are all the copies of gdi.dll on my machine:

C:\Windows\winsxs>dir | grep windows-gdi_
21/11/2010  04:24    <DIR>          amd64_microsoft-windows-gdi_31bf3856ad364e35_6.1.7601.17514_none_07f91de77125e78d
24/04/2016  20:26    <DIR>          amd64_microsoft-windows-gdi_31bf3856ad364e35_6.1.7601.18946_none_07da9f87713c7c4b
25/04/2016  03:04    <DIR>          amd64_microsoft-windows-gdi_31bf3856ad364e35_6.1.7601.18985_none_07ae5f8d715dd2b8
25/04/2016  03:38    <DIR>          amd64_microsoft-windows-gdi_31bf3856ad364e35_6.1.7601.19146_none_07da798f713cacb4
24/04/2016  20:26    <DIR>          amd64_microsoft-windows-gdi_31bf3856ad364e35_6.1.7601.23149_none_086715528a579b5c
25/04/2016  03:04    <DIR>          amd64_microsoft-windows-gdi_31bf3856ad364e35_6.1.7601.23188_none_083ad5588a78f1c9
25/04/2016  03:38    <DIR>          amd64_microsoft-windows-gdi_31bf3856ad364e35_6.1.7601.23346_none_086418408a5a49a5
05/08/2016  17:47    <DIR>          amd64_microsoft-windows-gdi_31bf3856ad364e35_6.1.7601.23453_none_0856495c8a6516b8
17/11/2016  12:35    <DIR>          amd64_microsoft-windows-gdi_31bf3856ad364e35_6.1.7601.23587_none_0839dca68a79cd0e
19/04/2017  21:40    <DIR>          amd64_microsoft-windows-gdi_31bf3856ad364e35_6.1.7601.23717_none_08858fe68a4103c5
26/06/2017  18:05    <DIR>          amd64_microsoft-windows-gdi_31bf3856ad364e35_6.1.7601.23807_none_089061b88a38e4fb
21/11/2010  04:24    <DIR>          wow64_microsoft-windows-gdi_31bf3856ad364e35_6.1.7601.17514_none_124dc839a586a988
24/04/2016  20:26    <DIR>          wow64_microsoft-windows-gdi_31bf3856ad364e35_6.1.7601.18946_none_122f49d9a59d3e46
25/04/2016  03:04    <DIR>          wow64_microsoft-windows-gdi_31bf3856ad364e35_6.1.7601.18985_none_120309dfa5be94b3
25/04/2016  03:38    <DIR>          wow64_microsoft-windows-gdi_31bf3856ad364e35_6.1.7601.19146_none_122f23e1a59d6eaf
24/04/2016  20:26    <DIR>          wow64_microsoft-windows-gdi_31bf3856ad364e35_6.1.7601.23149_none_12bbbfa4beb85d57
25/04/2016  03:04    <DIR>          wow64_microsoft-windows-gdi_31bf3856ad364e35_6.1.7601.23188_none_128f7faabed9b3c4
25/04/2016  03:38    <DIR>          wow64_microsoft-windows-gdi_31bf3856ad364e35_6.1.7601.23346_none_12b8c292bebb0ba0
05/08/2016  17:47    <DIR>          wow64_microsoft-windows-gdi_31bf3856ad364e35_6.1.7601.23453_none_12aaf3aebec5d8b3
17/11/2016  12:35    <DIR>          wow64_microsoft-windows-gdi_31bf3856ad364e35_6.1.7601.23587_none_128e86f8beda8f09
19/04/2017  21:40    <DIR>          wow64_microsoft-windows-gdi_31bf3856ad364e35_6.1.7601.23717_none_12da3a38bea1c5c0
26/06/2017  18:05    <DIR>          wow64_microsoft-windows-gdi_31bf3856ad364e35_6.1.7601.23807_none_12e50c0abe99a6f6

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm aware of Microsofts sins, Cliff. That does not excuse Cygwin to commit the same sins.

 

All the way back when COM (Component Object Model) was introduced by Microsoft there was provisions for having such DLLs being backwards compatible. At the time, one of the arguments for COM was to get out of  DLL Hell. Somewhere, quite early,  down the line from COM the whole idea was sidestepped, backwards compatibility lost and DLL Hell re-introduced - now on the COM level.

 

I can't recall the exact wording, but even in the early days of COM one rule was (my formulation) : "Never break a published interface".

 

Since COM there has been a technique available to avoid DLL hell. Before that people whined, but when COM was actually introduced "nobody" cared.

 


 

Back to the actual subject matter: Digging more into AVaRICE stuff, the WinAVR-20100110 installer brings a Cygwin1.dll, so I suppose it's the one that is needed for the avarice.exe that comes with the same installer.

 

And looking at

> avarice /?

it seems to support the Dragon, which is what I have on the bench.

 

If this works, then it'll do for the time being. Somewhere down the line a recent AVaRICE will be needed, but that can wait ass long as I can experiment with the Dragon and a mega2560.

 

I'll give this a try. Tomorrow..

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Last Edited: Tue. Jul 18, 2017 - 12:32 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I was going to say that I can't help thinking there must be others using avarice and Atmel-ICE somewhere but when you add "Windows" to that perhaps you do find yourself in a subset of 1 ? :-O

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

I was going to say that I can't help thinking there must be others using avarice and Atmel-ICE somewhere but when you add "Windows" to that perhaps you do find yourself in a subset of 1 ? :-O

Yes. Most likely. Studio serves the AVR-development-on-Windows community very well. I have never argued with that. And as long as I'm on Windows that will be my AVR environment also.

 

The whole thing with getting AVaRICE running on Windows is about the "small steps" principle, and that I have no running GNU/Linux system ATM, and that on GNU/Linux I will have to build AVaRICE myself (if I understand things correctly). Anything but small steps will likely make me fail or just get overwhelmed and abandon the idea.

 

The ultimate goal is to have a coding/programming/debugging solution that runs on any platform, where any = {GNU/Linux, MacOS, Windows}. I still suspect that the number of people using such a setup on Windows will be a single-digit number. Someone might be very affectionate of a specific IDE, e.g. Eclipse. But it's kind of a honorary quest to make it truly cross-platform, just for the sake ofg it. Practically, the important thing for me is to have it running in GNU/Linux. And since MacOS is based on BSD then it should be possible to run the same setup there.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohanEkdahl wrote:
and that on GNU/Linux I will have to build AVaRICE myself (if I understand things correctly).
true that but the difference is that this is just "natural" on Linux so it's probably very little more than config/make , no messing about with "build systems" and stuff because Linux has all that natively.

 

In fact one approach for building the Windows exe is actually to build it (as a cross compile) on Linux ;-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
In fact one approach for building the Windows exe is actually to build it (as a cross compile) on Linux ;-)

Tell me more - I'm all ears! (Especially if MinGW/MSYS qualifies as "a cross-compiler on Linux, targeting Windows".)

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As you'll see it comes back to mingw again:

 

https://stackoverflow.com/questi...

 

but you may find things more "manageable" coming at it from a Linux direction.

 

PS some of the other links for "build windows exe  on Linux":

 

http://www.blogcompiler.com/2010...

https://arrayfire.com/cross-comp... (gotta love the GIF anim alone!)

Last Edited: Tue. Jul 18, 2017 - 02:07 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK, I can build a Windows executable using the MinGW stuff. (I've already done that more times than I can count. Simple/trivial code only. E.g. every tested C++ example I've posted the last few weeks has been done using that setup on my main Windoes system).

 

So, I guess I'm asking - is Cygwin contributing anything special that MinGW does not? (Yes, a very open question, and not specifically @clawson).

 

I'm on my way to Google "build avarice on gnu/linux" now.. (E.g. I'm somewhat oriented about 'configure', Autotools stuff etc - but have not (yet!) used it to the point that I'm confident with it.)

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So there is a gotcha.  OpenOCD doesn't do debug wire and AVaRICE is only distributed in source form and needs Cygwin to run on Windoze.  Have I got that right?

 

I built AVaRICE from SVN using a custom ebuild on Gentoo.  The ebuild took me a while to get working as I'm not that familiar with making my own.  Especially not with SVN sources.

 

According to this wiki https://wiki.gentoo.org/wiki/Mingw I can build a Windoze binary on Gentoo.  I've had a look through it but I'm sceptical that this is going to work for me.  I've failed to get crossdev working for ARM and AVR targets so far.  I've just been using binaries tools provided by Arduino for AVR and https://launchpad.net/gcc-arm-embedded for ARM.

 

If you don't get anywhere with this I might have a go at crossdev.  Like you, I too want a cross platform IDE with all the trimmings.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sad status report:

 

I was about to run another stint on this. My plan was to try the AVaRICE from WinAVR-20100110 out and see how far I could get. Not far at all, it turned out..

 

I connected my Dragon and made sure it was seen from Atmel Studio. Affirmative. So I close Studio to avoid fighting over the Dragon.

 

Now, I look in the AVaRICE documentation, and I see that I must specify where my Dragon is. In all documentation and tutorials I've seen it should be on a (virtual) com port, so I go into device manager and.. Nothing!

 

I'm pretty sure the Dragon was updated with firmware from Studio when I attached it a few days ago, and I'm on the latest version of Studio (i.e. 7.0.1417). [*]

 

So, just to double-check I attach my SAM D20 Xplained board, and DOES immediately shows up as a COM port in Windows Device Manager.Next check is to attach my Atmel-ICE. It does NOT show up as a COM port. 

 

Looking harder the Dragon does show up, but not as a COM port. Neither does the Atmel ICE. Only the Xplained EDBG does that. And no, the Dragon and the Atmel-ICE does not show up in the same way. Obviously, the different Atmel debuggers do not share at all how they connect to the host system - it's a mess, but I guess it saves jobs somewhere... :rolling eyes:

 

So.. This is what I think the situation is: Older firmware of the Dragon, and drivers on the host, made the Dragon appear as a COM port on the host. This went well together with old AVaRICEs. Current Dragon firmware and host drivers does things differently. There exists no download of AVaRICE for Windows that matches this.

 

I am not prepared to take on building AVaRICE for Windows myself. Not right now, at least.

 

It seems I have come to the end of the road once again, and am starting to mentally prepare to give up. I lack the abilities, knowledge and stamina to penetrate this (and I'm usually quite stubborn..) Dropping this for today, at least.

 

PS. I am kicking myself hard for not thinking before letting Studio upgrade the firmware on the Dragon. Sooo stupid!

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Last Edited: Wed. Jul 19, 2017 - 07:29 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No, dragon has NEVER been on COM port. The com port on the EDBG is just a CDC bridge to a usart on the target device. It's not used for debugging.

You need to check what usb driver avarice expects. I would assume libusb0. Studio in the latest version binds the dragon to WinUSB.

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Should also mention that such an old avarice won't support anything in the JTAGICE3, Atmel-ICE and equivalent debuggers...

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm aware that this post is not very structured and "stringent". Sorry for that, but its a good reflection of my state of mind right now. Ignore at will.

 


 

meolsen wrote:
Should also mention that such an old avarice won't support anything in the JTAGICE3, Atmel-ICE and equivalent debuggers...

Well, from what I read in (old!) documentation for AVaRICE it uses Cygwin and from the WinAVR-20100110 user manual:

If you use avarice, when you specify a serial port to use with the —jtag flag, you must specify it in the form of:

--jtag /dev/comX

where X is the COM port number you are using. This is due to the fact that avarice is linked to the Cygwin DLL, which requires a Unix-type format for the COM port number.

I'm not sure if that says I must specify a serial port, or if I can specify a serial port.

 

The AVaRICE home page says

 The AVR Dragon is a low-cost offering from Atmel, and is also supported.

but that might be written in context of running on a GNU/Linux system where I assume the Dragon somehow appears under /dev .

 

I still end up with not knowing how to point AVaRICE to the Dragon on a Windows system. It does not, from what I see, "announce itself" in any identifiable and usable  way, e.g. under Device Manager.

 

meolsen wrote:
Studio in the latest version binds the dragon to WinUSB.

I don't know what to make of that. i) I have close to zero knowledge about WinUSB. ii) I'm trying to keep Studio out of the picture. Are you saying that Dragon can only be used by something that "binds the Dragon to WinUSB" - and hence, if AVaRICE does not do that it wont work?

 


 

Looking forward at what possible ways there is forward:

 

  • Trying to use AVaRICE with the Atmel-ICE. Requires a current AVaRICE (see below), and IIRC support for Atmel-ICE is still "dubious".

 

  • Build a current AVaRICE. I am trying to avoid this since it will definitively add several full days of work, study and learning. For something that, it seems to me, have a low probability to actually work in the end I'm hesitant.

 

Or.. Just scrap the whole idea of trying to understand this with Windows as host, and go for the GNU/Linux setup. But this still involves

  • Building AVaRICE.
  • The possibility that I've upgraded my Dragon to be something that the current AVaRICE does not support.
  • All other setups: Toolchain, GDB, some IDE at least..

This might be the way, but then it'll have to wait. I have no machine to run GNU/Linux on ATM.

 

The goal was always to end up on GNU/Linux, but I hoped I could learn and verify all this stuff on Windows. Turns out I was probably wrong. I'll sleep on this and decide later if/how to proceed.

 

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Johan,

 

avrdude is "more up to date" than avarice when it comes to talking to devices like Dragon so you may want to look at how it "sees" the Dragon but I believe the way it handles USB for most devices is that it treats them like UART/COM ports but some special setting (it might be a weird baud value?) says "actually handle this as USB not serial". It then goes searching for know VID/PIDs to locate the device. As quite a lot of the stuff is common (or was) between avrdude and avarice you may find something similar going on there.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cliff, and others!

 

Last thing I did last night was to

  1. Decide to try to switch to GNU/Linux - but since I have no free machine for that ATM I set up a Ubuntu VM in VirtualBox, and
  2. Decide to start out just trying to get AVRDUDE running since my suspicion was exactly what you state above, and
  3. Realizing that then I could just as well go for using my Atmel-ICE (which comes up as a COM port on Windows so I'm hoping it'll make for less trouble connecting to it)

 

So..

 

  • I got Ubuntu up.
  • I installed AVRDUDE by apt-get install'ing [1]. Turns out I didn't get the latest (i.e. 7.3) but 7.2 - with no support for Atmel-ICE. Not a big surprise since we know "the repos" are often somewhat behind.
  • Downloaded the latest .tar.gz source bundle of AVRDUDE and followed the instructions for building:

 

gunzip -c avrdude-6.3.tar.gz | tar xf -
cd avrdude-6.3
./configure
make
su root -c 'make install'
From configure I got this summary
Configuration summary:
----------------------
DON'T HAVE libelf
DON'T HAVE libusb
DON'T HAVE libusb_1_0
DON'T HAVE libftdi1
DON'T HAVE libftdi
DON'T HAVE libhid
DO HAVE    pthread
DISABLED   doc
ENABLED    parport
DISABLED   linuxgpio

so I clearly have some preparatory installing to do.. Nevertheless I couldn't resist seeing what an actual build would end in, so...

johan@UbuntuAvrDebugging:~/Downloads/avrdude-6.3$ make
/bin/bash ./ylwrap config_gram.y y.tab.c config_gram.c y.tab.h `echo config_gram.c | sed -e s/cc$/hh/ -e s/cpp$/hpp/ -e s/cxx$/hxx/ -e s/c++$/h++/ -e s/c$/h/` y.output config_gram.output -- yacc -d 
./ylwrap: line 111: yacc: command not found
Makefile:1927: recipe for target 'config_gram.c' failed
make: *** [config_gram.c] Error 1

Apart from the stuff that configure told about, I obviously need yacc.

 


 

Re the VM it seems to be able to access USB ddevices attached to the host. I see the Atmel-ICE in the VirtualBox list of devices and can select it. When I do it disappears from Windows Device Manager, so VirtualBox seems to "steal" it correctly.

 

And when testing that I realized that Atmel-ICE does not appear as a COM port (it's the EDBG that does so). Just a proof of my confusion and how immensely complex this stuff is for me ATM. (I usually don't consider myself stupid, but this thing seems to be able to convince me of it..)

 


 

I stopped there since it was clear that I had several hours before getting close and it was getting "a wee bit nippy of late" [2].

 


Footnote:

 

[1] Like this:

sudo apt-get update
sudo apt-get install avrdude

but that gives me 7.2 with no Atmel-ICE support.

 


 

[2] One extra point for anyone who can point correctly to the live recording where this wording is part of the announcement for the last number of the evening. Group and record title, please.

 

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Last Edited: Thu. Jul 20, 2017 - 10:41 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just be warned (and Morten will confirm where the line is) but early Atmel programmers/debuggers were USB 1.1 and I think that was up to Dragon, beyond that the devices are USB 2.0, I think that is from JTAGICE3 onwards. I have had success in the past talking to USB 1.1 devices from a VirtualBox but even after installing the "USB 2.0 extension pack" I have had less success with USB 2.0 devices.

 

So you may be better off trying to get it to all talk to the Dragon not an Atmel-ICE first if that's coming out of a VirtualBox.

 

While I haven't switched back yet there is a suggestion that VMWare may be better at this these days than VirtualBox.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Perhaps..

 

My last thought on this was to, again, first try with the D20 Xplained board since the EDBG on that shows up as a COM port.

 

I am at a loss trying to sort out the USB stuff - I just don't have enough knowledge about that.

 

E.g. this thing with the Dragon "being bound to WinUSB when on Windows". What does that imply when trying it on GNU/Linux?

 

Similar re

clawson wrote:
I believe the way [AVRDUDE] handles USB for most devices is that it treats them like UART/COM ports but some special setting (it might be a weird baud value?) says "actually handle this as USB not serial"

I can't make heads or tails of that. I've been trying to find some info about this but I'm surely missing something. Possibly obvious.

 

The current online documentation for AVRDUDE does not even mention Atmel-ICE. It only mentions the  Dragon in the list of possible values to pass with the -c option (dragon_dw, dragon_isp, dragon_jtag...).

 

The only thing I've found re USB is

For the JTAG ICE mkII, if AVRDUDE has been built with libusb support, port may alternatively be specified as usb[:serialno]. In that case, the JTAG ICE mkII will be looked up on USB. If serialno is also specified, it will be matched against the serial number read from any JTAG ICE mkII found on USB.

But that is for JTAGICE mkII, something that I don't have in my collection of programmers and debuggers. And, it seems this implies a mkII uses yet another way of connecting so I don't dare try to "superimpose" the above quote onto any other programmer/debugger.

 

I might have a (clone) USBasp lying around somewhere that I might try also, but all this about programmers is just a step away from what is the real target here: On Chip Debugging.

 


 

The more I dig the more complexities, variants, bad or missing documentation and just plain strangenesses I encounter. Instead of the picture slowly clearing up it just gets more convoluted, confusing and impenetrable. It's "fractal"...

 

While it of-course is Atmel/Microchips right to take any descision, and while we should be very grateful that we can get the Studio for free on Windows, I loathe the non-cross-platform decision they made for AS5 more than ever. One thing is sure - if I have to ditch AVRs when eventually ditching Windows (when my W7 is at EOL) I'll do it. I've seen enough report about how W10 behaves on non-corporate installs to be absolutely sure about that.

 

I need a break.. See you later.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Last Edited: Thu. Jul 20, 2017 - 11:55 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohanEkdahl wrote:
What does that imply when trying it on GNU/Linux?
"libusb" presumably?
JohanEkdahl wrote:
I can't make heads or tails of that. I've been trying to find some info about this but I'm surely missing something. Possibly obvious.
When you read the code it looks like it was originally designed for only UART and it ultimately has a get_byte/put_byte thing going on then the USB stuff appears to be "hacked in" afterwards so it shares a lot of structure with serial and some of the USB support even appears in the serial files. But somthing in the "device" details says "this isn't really a UART, it's a USB", and at the last minute it heads off in a USB direction.It makes the code very difficult to follow!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Stop thinking about the com port Johan!! It's not for programming/debugging!

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I did not follow this thread closely and have not much experience in debugging under linux, but I just happened to type this search term:

+gdb +linux +frontend into duckduck:

 

https://duckduckgo.com/html?q=%2...

 

and the results look intriguing. Especially the link to using GDB with QtCreator, which is my favourite IDE for developing AVR stuff on my Linux Box.

https://chromium.googlesource.co...

Paul van der Hoeven.
Bunch of old projects with AVR's:
http://www.hoevendesign.com

Last Edited: Thu. Jul 20, 2017 - 04:25 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

meolsen wrote:
Stop thinking about the com port Johan!! It's not for programming/debugging!

Not aimed at you, Morten - and I certainly do not expect you to straighten out my misunderstanding of AVRDUDE/AVaRICE. (You're one of my heroes for all of the other stuff you've hinted at, though! (-: )

But I sort of see some light with that.. Thank you!

 

 

OTOH: I'm sure I've seen a AVRDUDE or AVaRICE command line somewhere with something looking suspiciously like a BPS value, "115200" IIRC. (I'll try to locate it again.) It might be a trick, like Cliff hintedd at above..

 

I'll spend some time trying to build AVRDUDE on Linux tonight...

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Last Edited: Thu. Jul 20, 2017 - 04:50 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This evenings progress:

 

think I've managed to build AVRDUDE on GNU/Linux. The optimistic description is:

 

$ gunzip -c avrdude-6.0.tar.gz | tar xf -
$ cd avrdude-6.0
$ ./configure
$ make
$ su root -c 'make install'

In practice, on a newly set up Ubuntu, there will be a bunch of problems. A lot of libraries not installed. I managed to resolve everything but 'libhid'. Also YACC/Lex or equivalents were needed (resolved with Bison+Flex). I have a 150 line text file with notes on how I did it.´If needed and I find the time I could clean it up and post it.

 

It builds without errors despite ./configure marking 'libhid' as a DON'T HAVE. I'm hoping for that to be benign..

 

Not that it has gotten me much closer, but it was really nice to ave success with something. (If nothing else, the notes holds 30 lines of explanation of what the configure script is and does and a very brief overview of "Autotools ".)

 

 

N.B.: I actually have not tested it yet..

 


 

With that success, I of-course had to have a go at building AVaRICE too. Looks like an older version of Autotools was used for that. The configure script does not leave the same nice summary at the end.

 

But ./configure ended with only one warning, so I actually tried to 'make'. There my luck ended, something wrong with a pragma..

 


 

That's enough for now.. (This took 4 hours.)

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Modern AVR debuggers use HID I believe (Morten?) so I have a feeling a missing libhid could be an issue.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks Cliff!

 

The problem here is to know the name of the package to 'apt-get install'.

 

The configure script just says

DON*T HAVE libhid

but this;

sudo apt-get install libhid

fails with "E: Unable to locate package libhid". For some other packages I managed to figure out that appending "-dev" to the package name solved it. Not so for libhid. I also find things like this: https://www.howtoinstall.co/en/u... , but that is not the package the configure script craves..

 

I'm not a master re apt-get. Is there any way to do wildcard searches or some such for what packages exists? Not that this is the correct syntax but Im thinking something like "apt-get search libhid*"..

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrdude uses libusb to talk hid

 

 "apt-get search libhid*"..

meolsen@:~$ apt-cache search libhid
libhidapi-dev - Multi-Platform library for communication with HID devices (development files)
libhidapi-hidraw0 - Multi-Platform library for communication with HID devices (hidraw backend)
libhidapi-hidraw0-dbg - Debugging symbols for libhidapi-hidraw0
libhidapi-libusb0 - Multi-Platform library for communication with HID devices (libusb backend)
libhidapi-libusb0-dbg - Debugging symbols for libhidapi-libusb0

 

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohanEkdahl wrote:
I'm not a master re apt-get. Is there any way to do wildcard searches or some such for what packages exists? Not that this is the correct syntax but Im thinking something like "apt-get search libhid*"..
Don't know about apt-get, but you can do it online: https://packages.ubuntu.com/search?keywords=libhid

Stefan Ernst

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@Morten:

 

THANK YOU! (-:

 

I get

johan@UbuntuAvrDebugging:~/Downloads/avrdude-6.3$ apt-cache search libhid
libhidapi-dev - Multi-Platform library for communication with HID devices (development files)
libhidapi-hidraw0 - Multi-Platform library for communication with HID devices (hidraw backend)
libhidapi-hidraw0-dbg - Debugging symbols for libhidapi-hidraw0
libhidapi-libusb0 - Multi-Platform library for communication with HID devices (libusb backend)
libhidapi-libusb0-dbg - Debugging symbols for libhidapi-libusb0
libhidrd0 - runtime library for parsing and generating USB HID reports
libhidrd0-dbg - detached debugging symbols for libhidrd0
libhidrd0-dev - development files for parsing and generating USB HID reports
python-hidapi - Python bindings for the HID API
python3-hidapi - Python bindings for the HID API

I know the first hit doe NOT solve the "DON'T HAVE libhid" from ./configure. I'm not keen to just try the others one after the other in sequence...

 

How do people know which one of those "maps" to the short name "libhid"? I'm sure they're not just guessing!

 


 

EITHER the configure script actually looks for a more specific name than the "linhid" it outputs in the message,

OR the packages names are not the same as the final library they install.

 

Is there any way to "easily" drill into the configure script or the package to see what it actually looks for / installs?

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohanEkdahl wrote:
I'm not keen to just try the others one after the other in sequence...

But that is what I did, more or less.

 

I didn't install the *-dbg packages. And not the python packages. I'm not as cool as Morten. I could argue that I'm instead hot because of Groovy, but that's another story..

 

Anyway, I installed all non debug-symbol packages apart from the Python ones, but it does not solve the problem.

 

I found this, though: http://libhid.alioth.debian.org/ . Seems to me that it's been 10 years since libhid was "replaced" by "hidapi"... A bit down on that page there is a link to d/l the libhid source tarball, but you must register and get an email and... Sigh!

 

So now it's really enough for tonight - four hours just became close to six..

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Last Edited: Thu. Jul 20, 2017 - 09:10 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

but, you wont need libhid as long as you have libusb

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

but, you wont need libhid as long as you have libusb

Thank you, Morten! That is reassuring. Since that is the only DON'T HAVE that I have ;-) , there seems to be a possibility that what I've built will work once I test it..

 

Just out of curiosity, and to learn something from a real guru (grovel, grovel...): How do you know this (don't need libhid if have libusb)? How would I know?

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Btw do yourself a favour and "apt-get install synaptic" then searching for packages you want is 1,000 times easier.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ah yes.. I knew I had a GUI packet installer in a (by now scrapped) machine way back some time. That's the one. Thanks Cliff!

 

(Still, if I will incorporate such stuff in a possible write-up I might there go for the very basic thing that every Debian-derivate has. And that the apt command line..)

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
$ apt-cache-search libusb
libftdi1 - Library to control and program the FTDI USB controller
libusb-1.0-0 - userspace USB programming library
libusb-1.0-0-dev - userspace USB programming library development files
libusbmuxd-dev - USB multiplexor daemon for iPhone and iPod Touch devices - devel
libusbmuxd1 - USB multiplexor daemon for iPhone and iPod Touch devices - library
libusbmuxd1-dbg - USB multiplexor daemon for iPhone and iPod Touch devices - debug
ekeyd-uds - Simtec Electronics UDEKEY01 Entropy Key Daemon (UDS variant)
libdjconsole-data - Hercules DJ Console access library - data files
libdjconsole-dev - Hercules DJ Console access library - development headers
libdjconsole0 - Hercules DJ Console access library
libftdipp1 - Library to control and program the FTDI USB controller
libhid-dev - userspace USB HID development files
libhid0 - userspace USB HID access library
libusb-ruby - libusb binding for the Ruby language
libusb-ruby1.8 - libusb binding for Ruby
libusb-ruby1.9.1 - libusb binding for Ruby
libusbip-dev - USB device sharing system over IP network (development files)
libusbip0 - USB device sharing system over IP network (shared library)
libusbprog-dev - Development files for libusbprog
libusbprog0 - Library for programming the USBprog hardware
python-ftdi - Python module to control and program the FTDI USB controller
python-hid - Python wrapper for USB HID access library
spectools - Utilities for using the Wi-Spy USB spectrum analyzer hardware
libhpmud-dev - HP Multi-Point Transport Driver (hpmud) development libraries
libhpmud0 - HP Multi-Point Transport Driver (hpmud) run-time libraries
libusb++-0.1-4c2 - userspace C++ USB programming library
libusb++-dev - userspace C++ USB programming library development files
libusb-0.1-4 - userspace USB programming library
libusb-dev - userspace USB programming library development files

 

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohanEkdahl wrote:

With that success, I of-course had to have a go at building AVaRICE too. Looks like an older version of Autotools was used for that. The configure script does not leave the same nice summary at the end.

 

But ./configure ended with only one warning, so I actually tried to 'make'. There my luck ended, something wrong with a pragma..

 

 

You might need a couple of patches.

Description: Fix FTBFS for GCC 5
Author: Tobias Frost <tobi@debian.org>
Bug: <URL to the upstream bug report if any, implies patch has been forwarded, optional>
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777789
Forwarded: <URL|no|not-needed, useless if you have a Bug field, optional>
Last-Update: 2015-05-18
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- a/src/pragma.h
+++ b/src/pragma.h
@@ -28,9 +28,10 @@
  */
 #if defined(__GNUC__)
 #  if __GNUC__ > 4
-#      define PRAGMA_DIAG_PUSH       _Pragma(GCC diagnostic push)
-#      define PRAGMA_DIAG_POP        _Pragma(GCC diagnostic pop)
-#      define PRAGMA_DIAG_IGNORED(x) _Pragma(GCC diagnostic ignored x)
+#      define PRAGMA_DIAG_PUSH       _Pragma("GCC diagnostic push")
+#      define PRAGMA_DIAG_POP        _Pragma("GCC diagnostic pop")
+#      define PRAGMA_(x)             _Pragma(#x)
+#      define PRAGMA_DIAG_IGNORED(x) PRAGMA_(GCC diagnostic ignored x)
 #  elif __GNUC__ == 4
 #    if __GNUC_MINOR__ >= 6
 #      define PRAGMA_DIAG_PUSH       _Pragma("GCC diagnostic push")
From a6f4e5e771a9fa766e2b15b99a945203d0ec05e6 Mon Sep 17 00:00:00 2001
From: Martin Hofmann <martin.hofmann@studium.uni-erlangen.de>
Date: Fri, 14 Mar 2014 15:41:26 +0100
Subject: [PATCH] Fix build error if ENABLE_TARGET_PROGRAMMING is on                                                                                                                                               

New versions of bfd.h break build on Linux and Mac OS systems. Including
bfd.h requires constants to be defined, that are provided by autoconf.
Including autoconf.h into the files fixes the error.
---
 jtag2prog.cc | 1 +
 jtagprog.cc  | 1 +
 2 files changed, 2 insertions(+)                                                                                                                                                                                 

diff --git a/src/jtag2prog.cc b/src/jtag2prog.cc
index 1c75a80..a374818 100644
--- a/src/jtag2prog.cc
+++ b/src/jtag2prog.cc
@@ -38,6 +38,7 @@
 #include <math.h>                                                                                                                                                                                                

 #if ENABLE_TARGET_PROGRAMMING
+#  include "autoconf.h"
 #  include <bfd.h>
 #endif

diff --git a/src/jtagprog.cc b/src/jtagprog.cc
index bc573ef..7f701fb 100644
--- a/src/jtagprog.cc
+++ b/src/jtagprog.cc
@@ -37,6 +37,7 @@
 #include <math.h>

 #if ENABLE_TARGET_PROGRAMMING
+#  include "autoconf.h"
 #  include <bfd.h>
 #endif

--
1.9.0

Why not use the Dragon instead of the Atmel-ICE?  This is how I am flashing the AVR.

../arduino-1.8.3/hardware/tools/avr/bin/avrdude -C../arduino-1.8.3/hardware/tools/avr/etc/avrdude.conf -v -patmega328p -cdragon_isp -Pusb -Uflash:w:$(TMPDIR)/$(PROJNAME).hex:i

And this is how I start a GDB server using the Dragon.

avarice -2 -g -w -j usb -P atmega328p :3333

I'm using avrdude version 6.3 from Arduino-1.8.3.

Last Edited: Fri. Jul 21, 2017 - 06:31 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here is a binary package of my AVaRICE version 2.13svn20160229, Jul 12 2017 21:22:29

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The Atmel-ICE seems to work fine for programming.

avrdude -v -C$(AVRDCONF) -patmega328p -catmelice_isp -Pusb -Uflash:w:$(TMPDIR)/$(PROJNAME).hex:i

And debugging.

avarice -2 -g -w -4 -P atmega328p :3333

So, I didn't need to get the Dragon after all.  It's nice to have in my collection so I'm not complaining.

Last Edited: Fri. Jul 21, 2017 - 06:33 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohanEkdahl wrote:

OTOH: I'm sure I've seen a AVRDUDE or AVaRICE command line somewhere with something looking suspiciously like a BPS value, "115200" IIRC.

 

You need to specify the baud rate when upload via the Arduino boot loader.  Maybe this was what you are remembering.

avrdude -v -C$(AVRDCONF) -patmega328p -carduino -P/dev/$(PORT) -b57600 -D -Uflash:w:$(TMPDIR)/$(PROJNAME).hex:i

 

Last Edited: Fri. Jul 21, 2017 - 06:34 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, whaddyaknow.. With my own build of AVRDUDE:

johan@UbuntuAvrDebugging:~/Downloads/avrdude-6.3$ avrdude -patmega2560 -catmelice
avrdude: usbdev_open(): WARNING: failed to set configuration 1: could not set config 1: Device or resource busy

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.08s

avrdude: Device signature = 0x1e9801 (probably m2560)

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

avrdude done.  Thank you.

Yeah, I'm not pointing to any configuration file, I know...

 

BUT: It reads the device signature, i.e. the whole chain/stack works! The point? This: I now have proof that I can access a USB device (well, at least my AtmelICE) from a Ubuntu VM running under VirtualBox hosted on Windows. This removes one big uncertainty from my endeavours.

 

It's onto AVaRICE then! I'll sort my build problems out eventually (e.g. need to read up on how to apply patches on GNU/Linux if TT_ZX is right about patching needed). For now I'll try with the binary that TT_ZX supplied above.

 

Yes, I'm trying to follow my own advice: Small steps, small steps. Divide and conquer.

 

If that isn't clear: I am very grateful for all help and advice I've gotten! I'll probably need more eventually..

 

[BTW my Ubuntu is sluggish as hell. I'll probably need to set up a better VM (more RAM? bigger disk?). It'll probably be "Mint".]

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think I might have misled you with the patches above.  I remember having problems when trying to build AVaRICE and applying the GCC 5 to fix the same error you had.  It would then build but I was left with what appeared to be an old version that didn't support the Atmel-ICE.  It turned out to be an issue with Autotools which might be Gentoo specific.  Just make sure run ./Bootstrap before ./configure.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohanEkdahl wrote:

[BTW my Ubuntu is sluggish as hell. I'll probably need to set up a better VM (more RAM? bigger disk?). It'll probably be "Mint".]

 

Better yet, install Mint on the bare metal and demote Windoze to KVM. wink

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks, but have no "bare metal" ATM. I am not intending to scrap my W7 system, and have no other machine available.

 

Worse, temporarily, is that my Ubuntu VM broke down in pieces! Lost it's disk. On the surface it looks more like a VirtualBox malfunction than a Ubuntu crash. I was going to re-do the AVRDUDE build anyway since practice makes perfect, and I need to check that my notes are complete.

 

Still, here we where just a forthnight ago talking about backups, and I have neither snapshot'ted nor backed up my successes above. Shame on me.

 

Re ./bootstrap :  Noted!

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For those that don't already know (I didn't), you can't use hardware breakpoints with debugWIRE.

http://www.atmel.com/webdoc/GUID-DDB0017E-84E3-4E77-AAE9-7AC4290E5E8B/index.html?GUID-3D3FB217-0BFE-4E45-B77F-1FFE7D58C79E

 

Also AVaRICE cannot upload the elf file over debugWIRE either.  This means you need to set a software breakpoint, exit you debug session, upload the new elf over ISP and then start a new debug session.  I have to detach and the reattach my AtmelICE when using ISP after a debug session otherwise I get:

avrdude: jtag3_edbg_prepare(): failed to read from serial port (-1)
avrdude: failed to sync with the JTAGICE3 in ISP mode

So far debugging with the AVR is quite limited.  It's better than nothing I suppose, which is what I have had up to this point.  I think I will go with ARM on any future projects unless they are very simple.

 

Compiling AVaRICE for Windoze on my Gentoo system was a fail as well.  The cross development setup went well but AVaRICE needs header files from Cygwin to compile.  I tried to install these into my cross development setup but couldn't get it right.  Considering the limitations of debugging over debugWIRE I'm not going to spend any more time on this.  At least I can still develop, build and load my AVR code from Windoze, which is all I ever had anyway.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

TT_ZX wrote:
For those that don't already know (I didn't), you can't use hardware breakpoints with debugWIRE. http://www.atmel.com/webdoc/GUID...

Well, I for one didn't know.. Thanks for the heads-up!

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The data sheet for every AVR with  debugWire has that standard warning about wearing out the flash when you use dW and how you shouldn't use a development chip in production. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Status report: Been busy socializing, so this effort has been more or less paused.

 

Some small peripheral progress: I had a Minux Mint VM running under VirtualBox, but it was sloooow (could only run with emulated graphics for some reason, so very sluggish and couldn't use full physical screen).

 

Then I stumbled upon an unused 32 GB USB3 memory stick and decided to put a bootable Mint on it. (Am posting this using Chromium on that Mint stick.)

 

Laptop has USB3 and the Mint on the stick fast and works like a charm. Connected the Atmel-ICE and it shows up as /dev/usb/hiddev0 . Promising!

 

More socializing to come, so this will have to wait for a week or so. I have not given up.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Everyone got on "a day out" except me so managed to find a few hours for this today.

 

Have successfully built AVRDUDE again. About to test it with the Atmel-ICE soon.

 

But first, I thought I'd have a go at building AVaRICE. I get the following:

 

mint@mint ~/AVR/avarice-2.13 $ make
Making all in scripts
make[1]: Entering directory '/home/mint/AVR/avarice-2.13/scripts'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory '/home/mint/AVR/avarice-2.13/scripts'
Making all in src
make[1]: Entering directory '/home/mint/AVR/avarice-2.13/src'
make  all-am
make[2]: Entering directory '/home/mint/AVR/avarice-2.13/src'
gcc -DHAVE_CONFIG_H -I.  -DENABLE_TARGET_PROGRAMMING=0   -g -O2 -MT crc16.o -MD -MP -MF .deps/crc16.Tpo -c -o crc16.o crc16.c
mv -f .deps/crc16.Tpo .deps/crc16.Po
g++ -DHAVE_CONFIG_H -I.  -DENABLE_TARGET_PROGRAMMING=0   -g -O2 -MT devdescr.o -MD -MP -MF .deps/devdescr.Tpo -c -o devdescr.o devdescr.cc
devdescr.cc:36:51: error: _Pragma takes a parenthesized string literal
 PRAGMA_DIAG_IGNORED("-Wmissing-field-initializers")
                                                   ^
In file included from jtag.h:33:0,
                 from devdescr.cc:29:
pragma.h:33:38: error: ‘_Pragma’ does not name a type
 #      define PRAGMA_DIAG_IGNORED(x) _Pragma(GCC diagnostic ignored x)
                                      ^
devdescr.cc:36:1: note: in expansion of macro ‘PRAGMA_DIAG_IGNORED’
 PRAGMA_DIAG_IGNORED("-Wmissing-field-initializers")
 ^
Makefile:385: recipe for target 'devdescr.o' failed
make[2]: *** [devdescr.o] Error 1
make[2]: Leaving directory '/home/mint/AVR/avarice-2.13/src'
Makefile:248: recipe for target 'all' failed
make[1]: *** [all] Error 2
make[1]: Leaving directory '/home/mint/AVR/avarice-2.13/src'
Makefile:297: recipe for target 'all-recursive' failed
make: *** [all-recursive] Error 1

I've been searching and digging, and found e.g. https://stackoverflow.com/questi... but am not really sure of what happens there. Will think/search more though.

 

Meanwhile, it seems the possible that there is a need for patches , as noted in #90 by TT_ZX. I'm not entirely sure what TT_ZX is saying though. His post seems to have two (unnamed) patch files and then some diffs. Are the latter some kind of confirmation or do I apply what he shows in the diffs also?

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Don't you just copy those entire texts each to a separate file called avrarice1.diff and avarice2.diff then use the Linux "patch" command to have it apply the patches?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't know. There's both a "bona-fide" patch file and two diffs. This makes me uncertain abut what TT_ZX means should be done.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.. ;-) )

 

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A bit more progress!

 

AVRDUDE verified a bit further. Have Atmel-ICE, STK600 with ATmega2560:

 

mint@mint ~/AVR/avarice-2.13 $ sudo avrdude -c atmelice -p ATmega2560
avrdude: usbdev_open(): WARNING: failed to set configuration 1: could not set config 1: Device or resource busy

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:E0)

avrdude done.  Thank you.

Yeah, still no config file pointed out, I know. But It's talking all the way down to the AVR chip.

 

And...

 

AVARICE tested with the same setup, but it fails.

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

Defaulting JTAG bitrate to 250 kHz.

Failed to open /dev/usb/hiddev0

mint@mint ~/AVR/avarice-2.13 $

I am, sure the device name is correct. It comes/goes under /dev when I connect/disconnect the Atlmel-ICE.

 

This could be something I'm not doing right, i.e. not telling AVARICE what debugger I have. Or even that AVARICE does not support the Atmel-ICE. Can't remember the details on support ATM. I will fall back and tet the Dragon, which AVARICE is explicit with supporting.

 

Anyway I need to RTFM for AVARICE agan now, I know.

 

Enough experimenting for tonight! Need to make sure my PM/notes are in good order - I constantly remind myself I've promised a write-up eventually.

 


 

I'm talking muxh to meyself here lately. Are you guys getting tired of me? Please say and I'll try to be more quiet. Try.. ;-)

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Last Edited: Fri. Jul 28, 2017 - 07:31 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Failed to open could be permissions, try sudo-ing it.
.
(and if that works use udev to set up more permissive permissions)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

PS don't forget strace. It can be very useful to find out what's going on.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@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..

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
$ killall avaraice

 

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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!

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Status:

 

What did I do today?

 

Well, I got tired of running Mint in VMs. They had a tendency to crash.

Then I got tired of running Mint from a bootable USB memory stick. It was slooow (because of lack of hardware acceleration?) 

 

So I decided to take the jump and try setting up a dual boot on my, up until now, Windows 7 dedicsted SSD.

  • I spent a good 2 hours cleaning it out to, and swap things out to external hard disks. It was time for that anyhow.
  • I then went to the grocers while the machine spent 2 hours taking a safety disk image to external disk before I started meddling with partitions and stuff. It was due anyway.
  • I then waited 1 hour while I de-fragmented the disk to try to move files to the beginning of the partition.
  • I then spent a good 3 hours fighting Windows, since it has a tendency to place "unmovable files" at the middle or end of its partition and thus the partition can not be shrinked enough to make room for a new set of partitions for Linux. A lot of disabling services and stuff (e.g. turned off virtual memory! - since Windows swap file was at the end of the partition), deleting files, shrinking attempts (repeat, rinse...) and finally I had 48 GB free. Reset everything disabled in Windows again. Rebbot, and Windows seemed to start up normally.
  • I then spent a whopping 15 minutes creating the needed partitions and installing Mint in the freed up space.

 

Windows still boots (-:

 

Mint boots like lightning! (15 seconds?) Mint "sees" the Windows partition!

 

During the night I will secure this with a new disk image..

 

I did not do anything specific to AVR development on Linux, but I learned a lot today.

 

Tomorrow I'll build and test AVRDUDE and AVARICE for the third time. Practice makes perfect (-:

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Last Edited: Sun. Jul 30, 2017 - 08:19 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Next time try resizing the NTFS partition from Linux.  No unmovable files when the FS is not mounted.  Boot Mint from CD/DVD/USB and run GParted.  There is also a tiny bootable ISO called GParted Live.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I read a lot on the net before fishing for disk space. There was talk about a recent bug in GParted handling NTFS partitions.

 

FUD or fact, I didn't dare use GParted, as I am not prepared to lose Windows just yet. (OTOH, I've been on Mint the whole day today.. Heck, I even did a screen shot and edited with GIMP! )

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But you'd already made a disk image backup.  The worst that would happen would be you'd need to restore the backup and try again with a different tool.

 

I've never had any trouble resizing with gparted only any partition/fs type.  Mind you, I'm not an early adopter, so the gparted I use is an older version, perhaps immune to this alleged recent bug.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Last Edited: Sun. Jul 30, 2017 - 05:03 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I use gparted professionally a lot in the past. A wonderful tool. Never gave me a moment's worry.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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!

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What is the output of:

avarice --help

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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?

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Last Edited: Mon. Jul 31, 2017 - 08:06 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What is the output of:

avarice --help

Nothing. AVARICE starts, that's it. But for

avarice -?

I get

 

AVaRICE version 2.13, Jul 28 2017 19:47:49

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
  -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 :424

Again - what are you interested in? (Is this a misunderstanding/misread ? My "reset awkwardnesses" above is re AVRDUDE, not AVARICE.)

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for your kind words.  I was working away from home doing big hours last week, so I didn't really have time to post.  This site is one of my regulars now but I don't have a lot of experience in MCU or C/C++ yet so I'm mostly reading and learning.

 

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 and had to use those patches to get it to build at all.  I think it has something to do with needing to run these commands to build correctly:

  ./Bootstrap (once only after checkout)
  ./configure
  make

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I see you don't have support for the new programmers in your build.  Did you run those build commands above?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
 ./configure

But presumably that goes hunting around your Linux to see if you have things like libusb-dev installed or not? I guess it needs to see that to "turn on" support for the devices that require certain libraries? So it's not so much just running ./Bootstrap and ./configure that matters but what is found in the process. The ./configure should be writing a log to say what it found and what (optional bits) are missing.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here is my complete output:

AVaRICE version 2.13svn20160229, Jul 21 2017 19:23:15

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 

See the svn<date> after the version number?  I think what Johan is building is just the release version 2.13 not with all the changes since then.  I don't know anything about SVN and I don't build the package using the commands above.  I use Gentoo's package manager to build the package for me.  Originally I was having the same issue (release version being built).  Once I figured out how to get the Gentoo package manager to run the equivalent of the ./Bootstrap command (have look at the contents of this file) I got the latest build with the output above.  I didn't change any of the libraries in my system between builds.  I think the ./Bootstrap generates a new ./configure file.

 

Sorry to be vague but I don't know exactly what goes on during the build process I just know what I did to get it to build correctly on my system.

Last Edited: Mon. Jul 31, 2017 - 08:37 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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!

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohanEkdahl wrote:
Yes, my build is using the sources of the latest release, not the HEAD of the SVN.
I'd pull HEAD. Most of these tools don't seem to go in for regular "releases" so HEAD can be a LONG way ahead of any "last release"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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!

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
I'd pull HEAD. Most of these tools don't seem to go in for regular "releases" so HEAD can be a LONG way ahead of any "last release"

 

OK, and yes.

 

I just wanted something known to be stable for my first attempts. Not sure what philosophy Jörg et al has re the trunk - i.e. if the principle is that it is always in a "releaseable state".

 

@TT_ZX:

TT_ZX wrote:
 I use Gentoo's package manager to build the package for me.
 

Does thtis mean tht you don't pull sources from the AVARICE SVN repo at all, but from Gentoo's repo? Linux distros have been known not to be really up-to-date re "exotic" stuff like the AVR tools. The easy, no SVN-knowlege, way to get the head of the SVN repo is to go here: https://sourceforge.net/p/avaric... and click Download snapshot at upper'ish right.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Last Edited: Mon. Jul 31, 2017 - 09:46 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohanEkdahl wrote:

 

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

 

 

I meant my first attempts at building the package gave me the same output as what you have now.  Now that I have the equivalent of ./Bootstrap working,  I get the output shown above.  I don't believe I changed where the repo was pulled from (if my memory serves me).

 

The Gentoo package manager retrieves the repo from svn://svn.code.sf.net/p/avarice/code/trunk/avarice

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK, I gave HEAD a try. Didn't end well. What follows reflects my weak and fragmented knowledge about "Autotools":

 

I pulled the head (downloaded the snapshot) and unpacked it in a separate directory.

 

There's no makefile, so lets try to create that first:

johan@Mint-Latitude-E6330 ~/AVR/avarice/avarice-code-372-trunk $ ./configure
bash: ./configure: No such file or directory

So, clearly, we need to do some preparatory work to create the configure script. The instructions in the file INSTALL are clear that we need to run ./Bootstrap once. But trying

johan@Mint-Latitude-E6330 ~/AVR/avarice/avarice-code-372-trunk $ ./Bootstrap
+ aclocal
./Bootstrap: 23: ./Bootstrap: aclocal: not found

I will need to read up again on Autotools to see what might be needed before Bootstrap. The directory holds some files that are involved in/with Autotools:

johan@Mint-Latitude-E6330 ~/AVR/avarice/avarice-code-372-trunk $ ls -l
total 160
-rw-r--r-- 1 johan johan   551 Jul 10  2003 AUTHORS
-rw-r--r-- 1 johan johan  1449 Dec  7  2003 avarice.spec.in
-rwxr-xr-x 1 johan johan   746 May 27  2005 Bootstrap
-rw-r--r-- 1 johan johan 69222 Apr 18  2016 ChangeLog
-rw-r--r-- 1 johan johan  6525 Feb 29  2016 configure.ac
-rw-r--r-- 1 johan johan 18007 Feb 25  2003 COPYING
drwxr-xr-x 2 johan johan  4096 Jul 31 09:30 doc
-rw-r--r-- 1 johan johan    79 Feb 25  2003 INSTALL
-rw-r--r-- 1 johan johan   762 Jul 23  2007 INSTALL-FROM-CVS
-rw-r--r-- 1 johan johan 12534 Dec 19  2012 m4_ax_pthread.m4
-rw-r--r-- 1 johan johan   915 Oct  8  2006 Makefile.am
-rw-r--r-- 1 johan johan  7719 Mar  2  2016 NEWS
drwxr-xr-x 2 johan johan  4096 Jul 31 09:30 scripts
drwxr-xr-x 2 johan johan  4096 Jul 31 09:30 src
drwxr-xr-x 2 johan johan  4096 Jul 31 09:30 tools

but no aclocal. IIRC this is a file that is created by Autotools, and the "local" in the filename suggests it is to be created on the target machine (rather than on the "maintainer" machine).

 

I did read up quite a bit on Autotools a year ago or so, but memory fades fast, and even more so if not practiced. I have vague memories of 'autoconf'/'autoreconf', but as I recall that is something done by the maintainer, not "me". I do not have 'autoconf' installed, and am reluctant to do so on such a vague "whim"..

 

I will not have the time to read up on Autotools again ATM, so if no-one has a good advice on how to proceed to get the aclocal file then building from HEAD stops here. (And my Dragon stays on the bench, although it would be really nice to see the Atmel-ICE (or JTAGICE3) working!)

 

Again, big thanks to everyone that have contributed so far!

And.. I have not forgotten the promised write-up, but am not in a position yet to begin serious writing.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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"!

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here is a build log from my system.  It may shed some light on what is needed.  I know nothing about Autotools unfortunately.

 

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Congrats, looks like you got it nailed!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You probably posted while I composed my last long'ish post with a successful build of HEAD. 

 

I had a look in your log, and I see gets the code from the canonical SVN repo at SourceForge, trunk and revision 372. This is the current HEAD of the trunk and the same that I used in the latest build above.

 

Do I understand it correctly that you do not see the -3 and -4 options/switches in the help?

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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... ;-)

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Last Edited: Mon. Jul 31, 2017 - 11:55 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohanEkdahl wrote:

Do I understand it correctly that you do not see the -3 and -4 options/switches in the help?

 

Yes I do.  I pretty much went through the same process as you.  First attempts at building I didn't get those options but once I figured out Autotools (the Gentoo way) the next build was good.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.)

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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").

No, I can't confirm that... It's not intentional at least (we try to keep the firmware API stable, keeps all of us saner). If you want me to look into it I need the verbose output from avrdude (the one that shows the byte stream) smiley

 

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:

Really? I've never seen that... Just skimmed the avrdude source and it look like it takes an optional vid:pid parameter for usb. No mention of serial though...

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

meolsen wrote:
Really? I've never seen that... Just skimmed the avrdude source and it look like it takes an optional vid:pid parameter for usb. No mention of serial though...
I thought the ICE ID thing was when you had more than one ICE connected at the same time (so it knows which one to "talk to").

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

meolsen wrote:
If you want me to look into it I need the verbose output from avrdude (the one that shows the byte stream) 

Well, since I've updated the firmware I would have to downgraded again to see if this "phenomenon" is repeatable. I'll pass, and take your word Morten :-)

 

clawson wrote:
I thought the ICE ID thing was when you had more than one ICE connected at the same time (so it knows which one to "talk to").

Yes, that might be it!

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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... ;-)

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohanEkdahl wrote:
(But by golly, is this tedious... ;-)

 

As tedious as this may seem, imagine the tedium of having to field questions from hundreds (well, maybe part of a dozen) less adept individuals, each trying to do what you are doing. 99% would get part way and report "this is taking too much time and effort" and silently give up. I could easily be one of those!

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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!

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sometimes it's fun to document what you're doing with a photograph. So...

 

Left my Dell Latitude E6330 running Linux Mint. (On-screen, top right is a terminal window where I've just tried to run AVaRICE. Behind that is a Libre Office document with my table of tests.)

 

Center the STK600. I've fastened the Atmel-ICE on top of the ATmega2560 top board with a rubber band..

 

Top right the Dagon and the Arduino Uno fastened to a small piece of wood. (The rainbow flat-cable is left from an old display experiment IIRC.)

 

Bottom right the STK500 with and ATmega88.

 

When the picture was taken I was testing AVaRICE trough the Dragon to the ATmega328P on the (old) Arduino Uno.

 

It's a lot of cables and headers to keep track of. More than once I've cursed that something stopped working only to realize that I've just wired the Dragon/ICE to the wrong board, turned a connector the wrong way or have the wrong USB cable attached to the laptop..

 

 

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Last Edited: Sat. Sep 9, 2017 - 07:54 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

some of you are still following this

Don't doubt it!

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

AVR GDB was removed from PlatformIO 3 replaced by a unified debugger for ARM Cortex-M and TI MSP430.

Both AVR GDB and AVaRICE have been restored to an in-work version of PlatformIO 3.

The operator's interface is a terminal (i.e. not a part of PIO Unified Debugger)

 

Add GDB to build environment

valeros committed on Jun 20, 2017

https://github.com/platformio/platform-atmelavr/commit/b593f9e33cbab9337d9e1c6d31594422e70b03fd

Debug probe support for atmel-ice / dragon and atmega328p processor #53

warrenwoolseyiii opened this Issue on Jun 19, 2017

https://github.com/platformio/platform-atmelavr/issues/53

...

debug_server =
  /path/to/avarice
  --edbg
  --debugwire 
  --ignore-intr 
  :4242

Now you can start debugging session from terminal using pio debug --interface gdb -x .pioinit
Some of above commands might not work, especially load (in this case you will need to upload debug version of firmware manually using avrdude)

 

...

PIO Unified Debugger

http://docs.platformio.org/en/latest/plus/debugging.html

It Simply Works. Easier than ever before!

New in version 3.4: (PlatformIO Plus)

...

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@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.

 

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.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Last Edited: Sat. Sep 9, 2017 - 08:49 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohanEkdahl wrote:
But at a first glance I see no coverage of debugging for AVRs in "Unified Debugger".
There's contact :

https://www.avrfreaks.net/forum/platformio-do-or-do-not-thats-question#comment-2267111

JohanEkdahl wrote:
I'll be happy to start an SAM ARM on-chip debugging thread, if you want to contribute more on that matter!
I'll decline as no need for SAM (yet)

SEGGER has a GDB server for PIC32 and some of the ARM Cortex low price debuggers (OpenOCD) work for PIC32; I'm mulling PIC32MZ DA as MicroPython is in work for PIC32.

Choices wink

Been quite sometime since I've read the SAM side of the Community so when you post there I'll likely miss it.

 


GDB interface utility for MIPS processors, including PIC32

https://github.com/sergev/ejtagproxy

...

EJTAGproxy is a utility for debugging PIC32 microcontrollers with GDB
via JTAG or ICSP adapter.  Supported adapters:

 * Microchip PICkit2
 * Microchip PICkit3 with scripting firmware
 * Olimex ARM-USB-Tiny
 * Olimex ARM-USB-Tiny-H
 * Olimex ARM-USB-OCD-H JTAG adapter
 * Olimex MIPS-USB-OCD-H JTAG adapter
 * Bus Blaster v2/v3 JTAG adapter from Dangerous Prototypes
 * Flyswatter JTAG adapter from TinCanTools

...

List of supported processors:

...

via

Dangerous Prototypes

DangerousPrototypes

Use your PICkit2 or PICkit3 as a debugger for PIC32

http://www.microchip.com/design-centers/32-bit/architecture/pic32mz-da-family

MicroPython Forum

MicroPython & PIC32 chips

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:
SEGGER has a GDB server for PIC32

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?

 

gchapman wrote:
There's contact : https://www.avrfreaks.net/forum/p...

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?

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Will do

JohanEkdahl wrote:
And since PlatformIO is open source (yes?)
Yes (Apache 2.0) for the core, IDE integration, and CI; not FOSS for the value-added portions (PlatformIO Plus) (remote targets, PIO Unified Debugger, unit testing, static analysis)

JohanEkdahl wrote:
... then why do they need contact with Atmel?
PIO Unified Debugger is akin to the proprietary debuggers by Imagecraft, Rowley, and IAR.

An assumption is the response from one at Microchip is it's GDB MI and TCF.

What's likely to be proprietary is Microchip's plan for AVR cross-platform and a certain agreement between ones at Microchip and Microchip partners.

An assumption is Microchip has third party partners as Atmel did.

JohanEkdahl wrote:
They could just adopt AVaRICE?
Am glad AVaRICE is now a part of PlatformIO Core; more operators leads to the addition of more targets and defect correction.

Atmel did not compete against FOSS; Microchip does compete against Texas Instruments (AVR versus MSP430™) (Microchip AVR atbackend.exe versus TI MSP Debug Stack)

 


https://github.com/platformio/platformio-core/blob/develop/LICENSE

http://platformio.org/pricing

https://www.avrfreaks.net/forum/linux-friendly-pcb-design-software#comment-2179406

https://github.com/xoriath/vscode-atmel-debug by meolsen (Morten)

TCF

http://www.atmel.com/about/contact/sales/default.aspx?contactType=Third%20Party%20Support%20-%20AVR#

Texas Instruments

MSP Debug Stack

http://www.ti.com/tool/mspds

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Glad to see you are making progress here, Johan!

I gave up earlier and ordered an Olimex MK2, for a hopefully easier debugging setup in linux.

But will continue trying some more with my ICE while I wait for it to arrive.

 

One question though, did you remove the reset circuit on the arduino before trying debugwire?

I also think you need to manually program the DWEN fuse like you said.

 

Well, got to check if I got some more arduino's with ISP lying around, just bricked one (I think) because of the reset capacitor that I forgot to remove before programming DWEN..

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

canbeany1 wrote:
One question though, did you remove the reset circuit on the arduino before trying debugwire?

canbeany1 wrote:
just bricked one [Arduino] (I think) because of the reset capacitor that I forgot to remove before programming DWEN..

Tell me more. Up til now I've not ever programmed the DWEN fuse on any Arduino, so I'm ignorant..

 

I have an ATmeega88 sitting on the STK500 so I will proceed with testing the DWEN hypothesis on that.

 

canbeany1 wrote:
I gave up earlier and ordered an Olimex MK2, for a hopefully easier debugging setup in linux.

Isn't that just a programmer? I.e. not a debugger. My main "fight" is with AVaRICE for debugging.

 

If it's only programming you're after then note that I've come as far as having AVRDUDE working with both Dragon and Atmel-ICE. I would suspect it should work just fine with other programmers too. Somewhere I have a stash of USBasp's lying around, and I will test those eventually.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You are completely right.. It was after a long day I ordered it, I probably did mistake it for a JTAG ICE MKII clone :(

 

I made a bash script for changing fuses, but have not tested it successfully yet.

It set the DWEN fuse like it should, but I was unable to disable debugwire again.

It was probably because of the reset capacitor though, as I have debugged a UNO in AS7, and that time I removed the capacitor before starting.

 

#!/bin/bash
if [ "$1" = -e ]; # enable dw fuse
then
    avrdude -q -q -pm328p -catmelice_isp -U hfuse:r:hfuse.bfdw:h
    hfuse=$(cat hfuse.bfdw)
    echo Fuse was: "$hfuse"
    let "hfuse -=64"
    dwfuse=$(printf '%x\n' "$hfuse")
    newhex=0x"$dwfuse"
    echo Fuse now: "$newhex"
    avrdude -p m328p -catmelice_isp -U hfuse:w:"$newhex":m

elif [ "$1" = -d ]; # disable dw fuse
then
    avrdude -q -q -pm328p -catmelice_isp -U hfuse:r:hfuse.afdw:h
    hfuse=$(cat hfuse.afdw)
    echo Fuse was: "$hfuse"
    let "hfuse +=64"
    disdwfuse=$(printf '%x\n' "$hfuse")
    newhex=0x"$disdwfuse"
    echo Fuse now: "$newhex"
    avrdude -p m328p -catmelice_isp -U hfuse:w:"$newhex":m

elif [ "$1" = -r ]; # read fuses
then
    echo "Reading fuses"
    avrdude -p m328p -catmelice_isp -U hfuse:r:-:h

fi

If you *comment the avrdude write commands, you can compare fuse results with a fuse calculator.

Gonna look for a working m328p in the next hour. Was going to test a 1284P with JTAG, but I haven't ordered an adapter board for the ICE so I am not able to test JTAG just yet.

 

USBasp works great for programming, that's what I have been using since windows forcefully updated my win7 install with 6 hours of unsaved work open.. No more microsoft in this house! (I know me not saving is stupid.. but..argh!)

 

*edit* rewrote the bash script a little, I can now enable/disable debugwire with no hitch.

 

BUT.. 

a@debian:~$ avarice --edbg --debugwire --ignore-intr :4242
AVaRICE version 2.13svn20160229, Sep 10 2017 10:43:55

a@debian:~$ 

and thats all she said.. Will try again after a reboot of the system, been on for a while now.

Last Edited: Sun. Sep 10, 2017 - 02:19 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Tell me more. Up til now I've not ever programmed the DWEN fuse on any Arduino, so I'm ignorant..

There is a capacitor on the reset line of the AVR on your UNO.  It interferes with the DW communications.