AVR Source-level Debugging in Eclipse (WinXP) with Dragon – Success!

Log in or register to post comments
Go To Last Post
11 posts / 0 new
Author
Message
allano
allano's picture
Level: Hangaround
Joined: Wed. Aug 2, 2017
Posts: 106 View posts
Location: northwest suburb of Boston, MA USA
#1
Posted by allano: Sun. Oct 1, 2017 - 01:38 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Over the last two years, I have half-heartily tried to get source level debugging to work in Eclipse, first with Similavr and this year with a Dragon and real hardware.  In between tries, I read articles and AVRFreak threads about other users’ experiences as well as learned how to use avr-gdb and avarice in commend windows.  Finally, I got the right combination of tools, setup parameters and procedures to debug two eight bit microcontrollers in the Eclipse IDE environment. From threads on AVRFreaks, it seems that this event is a rare experience so I decided to start this thread to show what worked for me.

For my tool set, the primary difference from other articles was to choose stabs+ (stabs + gdb extensions) for the Debug Info Format and different options for the Eclipse Debug Configurations based on the information learned over the years.  More details later.

 

My primary interest is in debugging the ATtiny and Atmega 8 bit series so I chose to use debugwire with the Dragon.  I have successfully tried source-level debugging on an ATtiny84 and ATmega328 but do not know whether the procedure will work on other uCs.

 

For the purpose of this thread, I made the assumption that the reader has the Eclipse IDE, CDT plug-in, and avr-Eclipse plug-in installed.  If not, you might be interested in the article at https://protostack.com.au/2010/12/avr-eclipse-environment-on-windows/

To get a general feel for debugging in Eclipse, check out

http://avr-eclipse.sourceforge.net/wiki/index.php/Debugging for the Eclipse IDE and

https://awtfy.com/2012/03/29/hardware-debugging-the-arduino-using-eclipse-and-the-avr-dragon/

that has added information about debugging in Arduino.

I also assume the WinAVR-20100110 set tool is used.

 

In the next couple of posts, I would like to present the development environment, hardware and procedure that made it work with the hope that others can try it out on different microcontrollers (uCs) and post their experiences.

Tags:

Tools, In-System Debuggers and Programmers
Last Edited: Mon. Oct 2, 2017 - 01:30 AM
Top
allano
allano's picture
Level: Hangaround
Joined: Wed. Aug 2, 2017
Posts: 106 View posts
Location: northwest suburb of Boston, MA USA
Posted by allano: Sun. Oct 1, 2017 - 01:38 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I suspect my success might be a unique combination of tools and development environment. However, I'm not implying that it is the only setup that may work.  In fact, I'm hoping that other combinations of tools will also be successful.

One combination that did work is:

o The Window XP operating system

o Eclipse 3.7 (Indigo), CDT v8.0.2 Plug-in and Cygwin -  required by the CDT

o avr-Eclipse v2.4.2 (beta) - because I’m using Avrdude 6.1

o Eclipse GDB Hardware Debugging v7.0.0 plug-in

o WinAVR-21100110 tool chain

  - avr-gcc v4.3.3

  - avr-gdb v6.8

  - avarice v2.9     (although  version 2.12 worked as well)

o avrdude v6.1    (don’t remember why I replaced v 5.1 that came with WinAVR)

o libusb_win32   (the Dragon did not connect to libusb installed for the USBasp programmer.  Both Dragon and USBasp play well with libusb_win32).

 

When I chose that tool set in 2014, I did not want to "build" any software from source and hoped that tools released around 2010 and 2012 would play well together.

Top
allano
allano's picture
Level: Hangaround
Joined: Wed. Aug 2, 2017
Posts: 106 View posts
Location: northwest suburb of Boston, MA USA
Posted by allano: Sun. Oct 1, 2017 - 01:41 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

The hardware in the following picture

consists of the Dragon on the right, Dragon Lair (interface to the target uC) (http://www.aplomb.nl/TechStuff/Dragon/Dragon.html ) in the center and

ATtiny84 development board in the same style offered by Protostack at https://protostack.com.au/product-category/boards/microcontroller-boards/  on the left. The development board has a power input socket, 10pin ISP connector, reset button, 5v regulator and sockets for each pin on the uC as well as for a crystal if pluged in.

The bank of 8 LED’s on the left was built some 40 years ago to see the output of MSI logic and to monitor activity on the data bus of a Z80 based S100 computer – fun times remembered.

Top
allano
allano's picture
Level: Hangaround
Joined: Wed. Aug 2, 2017
Posts: 106 View posts
Location: northwest suburb of Boston, MA USA
Posted by allano: Sun. Oct 1, 2017 - 01:47 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK, now the fun stuff. 

Start a new project in Eclipse, create both Release and Debug configurations, and then select the Debug configuration.  Set the CPU type and clock speed to match the uC you will use. Select the project with the right mouse and select its Properties (last item in the list). The Project Properties window will open. Select C/C++ Build -> Settings.  In the Tool Settings tab, configured the AVR Compiler -> Debugging -> Settings as follows:

Set up the AVR Assembler -> Debugging entries with the same choices as above.  And while we are in Setting Menu for a new project, I usually have to check the Generate Hex file check box in the Additional Tools in Tool Chain.

All other tabs in the C/C++ Build window were left in their default settings. Apply the settings and OK the window.

 

So with the compiler set up for Debugging lets move on to the Debug environment.  The Debug Configuration is mean to setup up avr-gdb GDB for use in Eclipse. Since you already install the GDB Hardware Debugging capability, you can open the Debug Configuration Window by selecting the project (i.e. like TestDragon) in the Project Explorer pane with the right mouse and selecting Debug as -> Debug Configurations . . . 

To add a new HW configuration, select GDB Hardware Debugging with the right mouse and select New. 

A window like the one above will open with the project name and “Debug” appended to it.  In the C/C++ Application text box, Browse to the project’s Debug *.elf file and select it. I’m not sure how Eclipse uses the reference to this file because entering the elf file here does not automatically load it into avr-gdb.  Other options on the page are left as defaulted.  Notice that I want to use the DSF Hardware Debugging Launcher at the bottom of the page.  If that is not selected, press the Select Other high-light and make this change.

 

Now select the Debugger tab in the Debug Configuration window. 

The default GDB Command will have to be changed from ‘gdb’ to avr-gdb and to the path where your avr-gdb file is located.  Choose the Use remote target check box and enter what is shown in the picture (or whatever port number you wish).

 

Next select the Startup tab

Entries on this page will need a few words of explanation.  I left the Reset and Halt check boxes in their default state because I read that these two options are not active for a Generic JTAG Device (the Dragon qualifies).

 

The contents of the text box under those check boxes is used for parameters when avr-gdb.exe is invoked.  avr-gdb needs to load the project's *.elf file.  The avr-gdb’s “file” entry in the text box is used for this purpose.    Notice that Eclipse requires double back-slashes between paths and the elf file.  Also note that both avr-gdb’s break and continue instructions, previously included in other articles, are absent  because they caused unpredictable results: sometimes an asm ‘break’ occurred in the Disassembly window without creating a breakpoint in the GUI while at other times, the debug session would just hang as if an invisible ‘break’ were present.  Instead, the Runtime Options of Set Breakpoint at “main” and Resume (GDB’s equivalent of continue) are used to start program execution and stop at main.  The latter options worked well and produced consistent results.

 

Neither Load image nor Load symbols check boxes are checked.  The primary reason is that Avarice no longer has the ability to upload an *.elf (nor symbols) file to the uC.  Instead, AVRdude is used to upload the *.elf file to the target uC before the debug session is started.  Another underlining reason for not using either load is that after a load, Eclipse tacks on a –exe-run- instruction which tries to run the avr program as if it were a PC program. This action results in a “Don’t know how to run” error message. 

 

Entries in the other two tabs of the Debug Configuration dialog were left at their default values.

 

Top
allano
allano's picture
Level: Hangaround
Joined: Wed. Aug 2, 2017
Posts: 106 View posts
Location: northwest suburb of Boston, MA USA
Posted by allano: Sun. Oct 1, 2017 - 01:51 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Now that both compiler and debugger is setup, the next step is to upload the project’s elf file to the target uC using AVRdude and Enable the debugWire session.  For a simple program in

Eclipse uses AVRdude and the Dragon to upload the program to the target uC.

 

Launching C:\WinAVR-20100110\bin\avrdude -pt84 -cdragon_isp
-Uflash:w:TestDragon.hex:a

Output:

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.15s

avrdude: Device signature = 0x1e930c

avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed

         To disable this feature, specify the -D option.

avrdude: erasing chip

avrdude: reading input file "TestDragon.hex"

avrdude: input file TestDragon.hex auto detected as Intel Hex

avrdude: writing flash (3210 bytes):

Writing | ################################################## | 100% 5.48s

avrdude: 3210 bytes of flash written

avrdude: verifying flash memory against TestDragon.hex:

avrdude: load data flash data from input file TestDragon.hex:

avrdude: input file TestDragon.hex auto detected as Intel Hex

avrdude: input file TestDragon.hex contains 3210 bytes

avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 5.34s

avrdude: verifying ...

avrdude: 3210 bytes of flash verified

avrdude done.  Thank you.

 

Next step is to enable debugWire in the target uC (a ATtiny84).  I wrote a windows batch file to remind me to cycle power off and then on after setting the DWEN fuse so the target uC will enter the debugWire state.

 

The batch file:

avrdude -pt84 -cdragon_isp -b57600 -u -Uhfuse:w:0x9f:m

@ ECHO ** IMPORTANT ** Cycle Power off, then on to enter debugWire state.

@ ECHO You will want to start Avarice next.

@ PAUSE

 

What you see in the command windows is:

D:\>avrdude -pt84 -cdragon_isp -b57600 -u -Uhfuse:w:0x9f:m

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.15s

avrdude: Device signature = 0x1e930c

avrdude: reading input file "0x9f"

avrdude: writing hfuse (1 bytes):

Writing | ################################################## | 100% 0.15s

avrdude: 1 bytes of hfuse written

avrdude: verifying hfuse memory against 0x9f:

avrdude: load data hfuse data from input file 0x9f:

avrdude: input file 0x9f contains 1 bytes

avrdude: reading on-chip hfuse data:

Reading | ################################################## | 100% 0.05s

avrdude: verifying ...

avrdude: 1 bytes of hfuse verified

avrdude done.  Thank you.

** IMPORTANT ** Cycle Power off, then on to enter debugWire state.

You will want to start Avarice next.

Press any key to continue ...

 

I used a Windows command window to start avarice because Eclipse only shows errors in the Console view.  A separate command window gives much more information about Avarice’s progress.  Avarice starts with the following parameters for all uCs

 

D:\>avarice --debugwire --dragon --ignore-intr :4242

AVaRICE version 2.9, Jan  7 2010 22:42:57

JTAG config starting.

Found a device: AVRDRAGON

Serial number:  00:a2:00:06:41:35

Reported debugWire device ID: 0x930C

Configured for device ID: 0x930C attiny84

JTAG config complete.

Preparing the target device for On Chip Debugging.

Waiting for connection on port 4242.

Connection opened by host 127.0.0.1, port 1071.

 

The last line appears after you start your Eclipse debug session.  The result in Eclipse is:

In Eclipse’s Debug Perspective (shown above), the Eclipse Views of Breakpoints, Variables and Registers appear in the upper right pane, the project’s Source Code appears in the center-left pane and Assembly language code in the center-right pane.  The green highlights show the location of the program counter in both source and assembly code views. 

 

The debug controls are show in the bar next to the Debug tab View (near the top-left).  If you hover the mouse over each control button, you can see its purpose:

The Resume button  continues execution of the program until the next breakpoint. This button is like the Continue GDB command.

The Suspend button  will suspend execution of a program that is running and has no breakpoints.

The Terminate button  stops the debug process and also disconnects avr-gdb from Avarice. Use this button to reliably terminate avr-gdb and avarice.  It releases the Dragon for future use by other programs.

The Disconnect button  disconnects Avarice from GDB and (sometimes) kills the Avarice process.  It does not always release the Dragon for some odd reason.

The Step Into button  steps into a function to see its contents.  This button is like the GDB Step Into command.

The Step over button  executes a whole function without stepping through it.  This button is like the Next command in GDB but I have found that it does not seem to work – it steps into functions.

The Step Return button  , active when you are in a function, allows you to continue through a function to its end and return to the calling routine.  Be careful that you have a breakpoint set somewhere in the flow after the function or the routine will continue until you press the Suspend button.

 

Ok, back to the last picture.  Notice that no breakpoints have been set so far.  The next step in the process would be to set a breakpoint and look at variable values.  In the next figure, I set a breakpoint at line 18, by double clicking that line in the left boarder (shaded area), and then pressed the Resume button. After that, single stepped twice, looking at the values of variable “i”.  The last time through the if block shows i = 2 as you would expect.

If you were to Resume the program before setting a breakpoint, it would run at close to normal speed and show results if you have some indication (i.e. LED) in the prototyping board. Pressing the Suspend button will stop the execution. 

 

When you have completed your debug session, you will want to exit the Eclipse Debug session gracefully.  I found that selecting the debug session (“TestDragon Debug GDB Hardware Debugging” in the last picture) in the upper-left pane and then selecting the Terminate button is the most reliable way to exit from both Avarice and the Eclipse’s debugging session.  If successful, the larger LED on the Dragon will turn Red (no software connected) to tell you that Dragon is available for other software (such as Avrdude).  Pressing the Disconnect button did not always release the Dragon.  I have to unplug the Dragon’s USB connection from the computer and re-insert it before Dragon can be used by Avrdude.

 

Next step is to disable the debugWire state in the target microcontroller.  I was assured in post #27 of the https://www.avrfreaks.net/forum/anyone-actually-using-avarice?skey=eclipse%20debug%20dragon thread that asking Avrdude to issue an ISP command to the uC would temporarily disconnect the reset pin from the OCD module and, provided power was maintained on the uC, would allow Avrdude to change the DWEN fuse on the next ISP try, .  Much to my surprise, when the initial ISP command is to disable the DWEN fuse, Avrdude automatically retries that command and changes the fuse setting.  The following lines show the disable DWEN command for the ATtiny84 as well as the Avrdude’s response.

 

D:\>avrdude -pt84 -cdragon_isp -b57600 -u -Uhfuse:w:0xDf:m

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

avrdude: jtagmkII_getsync(): ISP activation failed, trying debugWire

avrdude: Target prepared for ISP, signed off.

avrdude: Now retrying without power-cycling the target.

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.15s

avrdude: Device signature = 0x1e930c

avrdude: reading input file "0xDf"

avrdude: writing hfuse (1 bytes):

Writing | ################################################## | 100% 0.15s

avrdude: 1 bytes of hfuse written

avrdude: verifying hfuse memory against 0xDf:

avrdude: load data hfuse data from input file 0xDf:

avrdude: input file 0xDf contains 1 bytes

avrdude: reading on-chip hfuse data:

Reading | ################################################## | 100% 0.05s

avrdude: verifying ...

avrdude: 1 bytes of hfuse verified

avrdude done.  Thank you.

 

So my DWEN fuse was changed to disable the debugWire mode. After Avrdude is finished, I usually cycle power off and then on but have been told that a power cycle is not necessary.  To get a better understanding of the process, check out the flow chart at http://www.atmel.com/webdoc/GUID-EAD481FD-28E6-4CD5-87FB-5165E7687C12/index.html?GUID-48C68221-FA0C-4CAB-9C7F-605F8B5D0000

This flow was originally presented in post #4 in the thread “How is debugWire (DWEN fuse) unprogrammed”  https://www.avrfreaks.net/forum/how-debugwire-dwen-fuse-unprogrammed

 

Top
allano
allano's picture
Level: Hangaround
Joined: Wed. Aug 2, 2017
Posts: 106 View posts
Location: northwest suburb of Boston, MA USA
Posted by allano: Sun. Oct 1, 2017 - 01:52 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I was able to get source level debugging to work for the ATtiny84 but wanted to check if it would work on another uC.  I had an ATmega328 and development board in house so I decided to try debugging on that controller. 

 

Before making any changes to other software and hardware, I decided to update Avarice from version 2.9 in WinAVR-20100110 to version 2.12 which is available as a Windows executable in https://sourceforge.net/projects/avarice/files/avarice/ .  I started another thread with that experience and will provide the Cygwin DLLs required in that thread https://www.avrfreaks.net/forum/files-update-avarice-212-windowsxp .  The primary attraction for this update was one line in the Release Notes that said this version cached the program counter to speed up communications – which is noticeably does.

Last Edited: Sun. Oct 1, 2017 - 09:21 PM
Top
allano
allano's picture
Level: Hangaround
Joined: Wed. Aug 2, 2017
Posts: 106 View posts
Location: northwest suburb of Boston, MA USA
Posted by allano: Sun. Oct 1, 2017 - 01:55 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Testing the described Eclipse debug setup on the mega328 was successful.  Except for changes to the fuse settings in both EnableDW and DisableDW batch files, everything worked as set up for the tiny84. 

 

The program used as a debug target on the mega328 was a test of the Davide Gironi’s I2C serial library using a four line LCD - lots of functions.

To make the test program more interesting, I included the UART in the mega328 (using Peter Fluery’s library) to communicate with my PC development computer using the serial connection through a RS232 module.  I wanted to display characters on the LCD that are typed in the PC and then echo them back to the PC. It was a learning experience to deal with the FIFO, set breakpoints at good locations (to avoid single stepping) and follow the control code path.

Debugging with the described setup in Eclipse was successful and worked as expected except for the Step-Over functionality.  It always stepped into  functions.  This is not too much of a problem since Step-Return exited the function.  My only suggestion is to place a breakpoint at the next instruction after the function so execution stops there.

 

I hope that this information helps those who were having problems with debugging in Eclipse.  I’d like to hear from others who have tried this procedure on other microcontrollers and succeeded.

Top
allano
allano's picture
Level: Hangaround
Joined: Wed. Aug 2, 2017
Posts: 106 View posts
Location: northwest suburb of Boston, MA USA
Posted by allano: Sun. Oct 1, 2017 - 01:58 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Possible error messages and their solutions

 

Sometime you mess up and exit the debug session without either terminating or disconnecting the debugger.  In that case you may have an embedded assembly ‘break’ instruction that the GUI does not know about and cannot delete

The only way I know of getting around that problem is to exit the debug session, disable the debugWire session (i.e. DWEN fuse) and  reload the *.elf file to the uC using AVRdude.

 

 

If you get a “cannot find USB device” error message, your Dragon is tied up with other software (no Red and Green LED indications). You will need to unplug and reinsert Dragon’s USB connection to you computer.

As an example

D:\>avrdude -pm328 -cusbasp

avrdude: error: could not find USB device with vid=0x16c0 pid=0x5dc vendor='www.fischl.de' product='USBasp'

avrdude done.  Thank you.

 

The “set parameter command failed” message you get when you try to start an Avarice session and are not in the debugWire mode.

D:\>avarice --debugwire --dragon --ignore-intr :4242

AVaRICE version 2.12, Dec 12 2011 15:48:09

JTAG config starting.

Found a device: AVRDRAGON

Serial number:  00:a2:00:06:41:35

set parameter command failed

 

 

Top
gchapman
gchapman's picture
Level: 10k+ Postman
Joined: Tue. Jan 9, 2007
Posts: 10966 View posts
Location: Arlington, Texas, u.S.A.
Posted by gchapman: Sun. Oct 1, 2017 - 06:55 PM (Reply to #5)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the good read.

allano wrote:
I have to unplug the Dragon’s USB connection from the computer and re-insert it before Dragon can be used by Avrdude.
Might try a USB cycle and/or USB power via an IOCTL.

Microsoft

Microsoft

Hardware Dev Center

USB IOCTLs

https://msdn.microsoft.com/en-us/library/windows/hardware/ff537421(v=vs.85).aspx

...

IOCTL_INTERNAL_USB_CYCLE_PORT

Simulates a device unplug and replug on the port associated with the PDO.

...

IOCTL_USB_HUB_CYCLE_PORT

Power cycles the port that is associated with the PDO that receives the request.

...

 

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

Top
gchapman
gchapman's picture
Level: 10k+ Postman
Joined: Tue. Jan 9, 2007
Posts: 10966 View posts
Location: Arlington, Texas, u.S.A.
Posted by gchapman: Sun. Oct 1, 2017 - 07:00 PM (Reply to #6)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

allano wrote:
I started another thread with that experience and will provide the Cygwin DLLs required in that thread (insert URL here).
https://www.avrfreaks.net/forum/files-update-avarice-212-windowsxp

 

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

Top
JohanEkdahl
JohanEkdahl's picture
Level: 10k+ Postman
Joined: Wed. Mar 27, 2002
Posts: 26988 View posts
Location: Lund, Sweden
Posted by JohanEkdahl: Fri. Oct 6, 2017 - 09:57 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello allano!

 

I somehow missed this thread when you started it, but luckily stumbled upon it later.

 

This only to say Thank You for posting this. I am reading with great interest!

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]

Top