I think I have a handle on this now and thought I would share should anyone ever experience this little bit of frustration I have just worked through. I created a second post (because I think I exceeded the message limits here) to include the JTAG header pinout table for the AVR ONE! along with a table describing what pins on the Arduino/ATmega2560 get connected to what pins on the JTAG header.
AVR ONE! – JTAG
AVR ONE! JTAG Debug Fuse Settings
- If using AVR Studio the OCDEN fuse will be enabled automatically each time a debug session is started and will be disabled when the debug session is ended. That being said I did go into AVR programming with the AVRISP mkII and set the OCDEN to be enabled to be sure the settings where default initialized before starting. Since then I haven’t touched OCDEN.
- The JTAGEN fuse must be enabled.
- The BOOTRST fuse must be enabled.
AVR Studio 5.1 Project Settings
-
Follow the documented tutorial for including Arduino source code to the AVR Studio environment. Something to note, however, is that Atmel has appeared to have fixed the need to re-locate the “-Wl,-lcore -Wl,-lm” within the makefile so there is no longer a need to use an external makefile.
-
Although I believe it is possible to compile and run both C and C++ projects I was only able to set break points and watch variables (i.e. debug) AVR/GNU C projects.
-
I don’t know if this is a defect or not, however, when I compiled and tried to debug the blink example I was unable to set breakpoints or even use the “Start Debugging and Break (Alt+F5)” option within the studio. Once I commented out the Arduino delay(nMillis) function I was able to set breakpoints and stepping functions again.
-
There is a warning directive defined in Atmel’s delay.h file indicating that if the compiler optimizations are turned off then the use of their delay_ms(nMillis) function will not work as designed which makes perfect sense.
-
When I use Atmel’s _delay_us(nMillis) inline function defined in their delay.h file I am able to set breakpoints and debug as usual.
-
Finally be sure to turn OFF all Compiler Optimizations. This was both a good thing and a bad thing because as stated:
-
Bad Thing = if Optimizations = Off then some functions (in my case delay(nMillis) will cause the debugger to never stop, and never hit breakpoints.
-
Good Thing = Opened my eyes to what Atmel has included and they seem to have addressed (at least) this specific issue in their delay.h file via inlining.
[/list]
***Please let me know if you spot anything that appears to be incorrect so I can keep this updated with accurate info. I would like to “keep it real” for anyone looking to this forum for answers.