Getting started with Atmel Studio

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

Hi all -

 

I've just begun working with all things Atmel, so hopefully I don't screw up the terminology.

 

My new job entails using the ATMega 1284P. The previous developer was running Atmel Studio 4 on Windows 7. I've been given a Windows 10 box, and would like to use Atmel Studio 7, as I'm generally a fan of keeping up to date on development tools. I found the Atmel page on converting from earlier versions (http://www.atmel.com/webdoc/atmelstudio/ch12s02s02.html) but I get an error when I try to convert:

 

Conversion Failed:Project Import Failed : The specified object file is not found in the specified location of the source project C:\CyberData\APG1284PDupontBase\APGDupont\Debug\Exe\APGDupont.dbg [Activity : Saving Atmel Studio 7.0 Solution]  

 

Can someone please tell me what I'm doing wrong?

 

As a sidebar, I read the thread about version 7 that began in March. Of particular interest was the discussion on the drivers. Do I correctly understand that I should no longer expect to see the drivers listed under "Jungo?"

 

Thanks for any help.

This topic has a solution.

M. Zimmers
Cyberdata

Last Edited: Tue. Sep 12, 2017 - 07:08 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Might just be simplest to recreate from scratch and you probably learn more doing it that way anyway.

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

mzimmers wrote:
I'm generally a fan of keeping up to date on development tools

But you say you've just started a new job.

 

Therefore you should discuss with your manager what the policy/plan is on this.

 

Changing tools mid-project is not something to be undertaken lightly - especially when going from such an old version!

But, then again, it sounds like they've replaced the developer (was he the only developer?), and replaced the development machine - so they must have budgeted something for you to get it all set up and up to speed.

 

Or perhaps they weren't even aware that they old guy was so far behind - in which case it would be even more important to discuss the way forward!

 

Do you have access to the previous developer's machine - for reference?

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

Hi awneil -

 

I'm taking over for someone who is still here, so I can still learn from him.

 

The current challenge is that Windows 10 system doesn't seem to have the drivers set up properly for AVR Studio 4. If I understand it correctly, version 4 expects to see the drivers under "Jungo" and I now have them under "Atmel" (in the Device Manager).

 

Maybe what I should have asked is, are there major implications with upgrading from 4 to 7? If so, I can look into getting a Windows 7 system to run Studio 4. I was just hoping that I'd be able to move to the newer tools.

 

And all this is predicated on the assumption that there's some benefit to moving from 4 to 7 - if you feel this is false, please feel free to say so.

 

Thanks...

M. Zimmers
Cyberdata

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

4 to 7 is a bit like switching from a manual to an electric screw driver. Some folks still think the manual does at least as good a job and there's less to go wrong ;-)
.
EDIT I love predictive text!

Last Edited: Mon. Sep 11, 2017 - 05:46 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mzimmers wrote:
are there major implications with upgrading from 4 to 7?

Any update to tools mid-project requires some re-validation that the new tools don't "break" anything.

 

Have you asked why they haven't updated already?

 

The trouble with sticking with obsolete tools, as you're finding, is getting the obsolete systems to run them on!

 

Because 4 is so far behind 7, it rather unlikely that any "automated update" is going to work - which probably explains the error you're getting.

 

So I'd probably go with clawson's suggestion and re-create the project form scratch.

 

 

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

Well, as they say in the South, "I got no dog in this hunt."

 

Over the years, I've found it to be a good idea to try to keep current with OSs, applications and toolsets, but I'm not wedded to the concept. I'm more than open to what people here think I should do. The goal is to get something on my system that I can use to maintain these applications.

 

We also use IAR here, so the Atmel version I use must be able to accept something called a "UBROF 8" file and a "HEX" file. (Version 4 did this.)

M. Zimmers
Cyberdata

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

mzimmers wrote:
Over the years, I've found it to be a good idea to try to keep current with OSs

I would certainly agree.

 

But you say you've just started a new job - so your new employer may have a different view/policy; and, as already noted, changing tools is a non-trivial exercise - and can have impacts beyond the SW development itself.

 

A tool change like this could be a mini-project in itself - hence the importance to discuss with "management"...

 

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

UBROF is a file unique to IAR.

 

HEX is the end file generated by the compiler. It is used by the programming tool to load the firmware into the target. IAR generally (always?) uses a different hardware tool to do that programming than Atmel Studio. Any programmer should be able to take a hex file and stuff it into the target, no matter whether that HEX file was created by IAR or gcc (Atmel Studio).

 

There is varying support for bootloaders and programmers between the two development environments. 

 

My personal opinion (having worked with both) is to stick with one environment or the other for a given project. Don't try to mix them - its a recipe for disaster. Its hard enough to work with different IDEs for different projects.

 

Jim

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

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

ka7ehk wrote:
HEX is the end file generated by the compiler. 

Not exactly:

 

It is extracted/converted from the output of the Linker.

 

 

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

Should have written "tool chain" instead of "compiler". Close but no roses.

 

Jim

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

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

Generally it's a good principal to update to the latest version of software, but there are exceptions.  Atmel Studio is one of them.  With microprocessor development software, it's best to use [[1] the version that everyone else on your development team is using, [2] what your customers are using if they have open-source access to the source code and contribute to its improvement, [3]  what runs and loads the fastest, and [4] last but not least, what works.   If you are the only developer for this application, then 1 and 2 don't apply, so 3 and 4 would suggest sticking with Studio 4. 

 

  On my recent laptop,  Studio 7 takes about 100 seconds to simply load from clicking on the icon to being able to type chars on the edit screen.   That's about 80 seconds too long for any program.  Bloated code is an indicator that the team that wrote it doesn't quite know what they're doing.  I'm not saying that the Atmel team is incompetent: I'm only saying that my gut instinct tells me that any program that takes more than a minute to load is not to be trusted because the developers pasted together miles and miles and miles of source code together into a big fudge mix.   Which means that there are many opportunities for unnoticed "got'ya!" side effects just waiting to be discovered by the beta testing squad i.e. the users.   Just how different can the fundamentals for AVR development be when you are turning C source code into .hex files?   And since they both do fundamentally the same thing, then why does Studio 7 take 100 seconds to load and Studio 4 take about 15 seconds to load?  Over-engineering a product is not the same as improving a product.   If you can get Studio 4 to work with a Mega1284P, then I suggest sticking with Studio 4 until you absolutely have to "upgrade".

Last Edited: Mon. Sep 11, 2017 - 07:02 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Does sound like the Studio 4 project is referencing C:\CyberData\APG1284PDupontBase\APGDupont\Debug\Exe\APGDupont.dbg which does not exists on disk?

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

Hey everyone -

 

Thanks so much for all the input -- lots to think about. As I said, if I can get Studio 4 working on my system (Windows 10) I'm willing to stay with it. Originally I thought it would be easier to change IDEs, but now I'm thinking I may need to find a Windows 7 box (or run a VM) for this.

 

EDIT: Simonetta: the question isn't whether Studio 4 will work with the 1284P (it does); it's whether Studio 4 can be made to work on Windows 10. Currently it's not looking good, which is why I'm probably going to have to use a VM. I know it seems like the tail wagging the dog, but I don't know what else to do.

M. Zimmers
Cyberdata

Last Edited: Mon. Sep 11, 2017 - 11:48 PM
This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mzimmers wrote:
Currently it's not looking good, ...
Others are either successful or have attempted AVR Studio 4 on Windows 10 :

http://www.avrfreaks.net/forum/studio-419-build-730-windows-10

http://www.avrfreaks.net/forum/atmel-studio-419-windows-10

http://www.avrfreaks.net/forum/avr-studio-4-doesnt-see-anymore-my-jtagice-mkii-windows-10

http://www.avrfreaks.net/forum/studio-7-and-at90s4433

Windows 10 is a work-in-progress.

When you have a functional IDE lock it and Windows 10 down (restore points, backup each Windows 10 build, consider moving to Semi-Annual Channel)

Windows 8.1 :

http://www.avrfreaks.net/forum/tutsoftavrdragon-avrstudio418sp3-win81

Windows 7 :

http://www.avrfreaks.net/forum/installing-avr-studio-419-windows-7-fixed

mzimmers wrote:
... which is why I'm probably going to have to use a VM.
For trialing without installing Windows, some Vagrant boxes have Windows 7 :

https://app.vagrantup.com/boxes/search?order=desc&page=1&provider=&q=Windows+7&sort=updated&utf8=%E2%9C%93

via https://www.vagrantup.com/

 


Microsoft

Microsoft

Windows 10 release information

https://technet.microsoft.com/en-us/windows/release-info

 

Edit : URL

 

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

Last Edited: Tue. Sep 12, 2017 - 02:06 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi GChapman -

 

Thanks for those links. I followed the instructions on installing Studio 4 offline. I think I have two remaining issues:

 

My USB drivers show up under Jungo. I get the impression this is insufficient/incorrect. It seems I have two choices:

Do you have a recommendation on which to use?

 

Also, I seem to be missing a toolchain - on startup:

 

gcc plug-in: No AVR Toolchain installation found. The AVR GCC plug-in can still be used if you set up your own build tools.

I saw a reference to a gcc toolchain in one of the links you provided, in which it was posited that the gcc toolchain may be preferable to AVR's. Can you tell me where to get a version of this gcc toolchain that will work with Studio 4?

 

Thanks for all the help...I feel encouraged about getting this working.

 

M. Zimmers
Cyberdata

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

Just google "atmel toolchain for Windows" and get that - AS4 4.19 should "see" it once installed. That will give you a 5.3 version of avr-gcc

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

I had found this:

 

Atmel AVR 8-bit Toolchain 3.5.4 - Windows

 

It doesn't mention gcc or any GNU stuff...is it the right toolchain?

EDIT: I stand corrected. Once you begin downloading, it has "gnu-toolchain" in the filename. I'll begin installing and report back.

 

And...any opinion on the USB drivers?

 

Thanks...

M. Zimmers
Cyberdata

Last Edited: Tue. Sep 12, 2017 - 05:47 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mzimmers wrote:
use those found in this installer: driver-atmel-bundle-7.0.888.exe
anyone's fyi :

Atmel Corporation

Atmel Gallery

Products

Atmel USB Installer

https://gallery.atmel.com/Products/Details/6272a8fd-68fe-43d8-a990-741878cfe7b6

Version 7.0.888

...

via browse, categories, all, utilities, USB Driver :

https://gallery.atmel.com/Products/List?q=&orderBy=&SelectedCategoryId=6767359f-d509-42ff-82b0-680ece9bd39d

mzimmers wrote:
Do you have a recommendation on which to use?
No as I'm not an AVR Studio operator though Jungo is the long-time USB layer between the Atmel Studios and Windows; it's now WinUSB instead of Jungo in Atmel Studio 7.0.1416 and subsequent.

The miklor UV_Drivers is per scottm who is an STK500 operator; the STK500's primary RS232 serial port is used to communicate with the STK500's mega8535.

For an STK500 via a bog standard USB CDC ACM dongle, Windows 10's USB driver should work (i.o.w. no need for another driver)

STK600 goes via USB.

What's the debugger and/or programmer for the mega1284P?

mzimmers wrote:
I saw a reference to a gcc toolchain in one of the links you provided, in which it was posited that the gcc toolchain may be preferable to AVR's. Can you tell me where to get a version of this gcc toolchain that will work with Studio 4?
To expand on Cliff's answer :

Microchip AVR GCC : http://www.microchip.com/development-tools/atmel-studio-7/avr-and-arm-toolchains-(c-compilers) (Note : 3.6.0 is elsewhere)

FSF AVR GCC : http://gnutoolchains.com/avr/

 


http://www.atmel.com/Images/releasenotes_avrstudio418.txt

...

Bug Fixes

*Minor fix for un-installing USB driver. Will not completely un-install so that other programs using the Jungo driver will still work.

...

via http://www.atmel.com/tools/STUDIOARCHIVE.aspx

Microsoft logo

Microsoft Windows USB Core Team Blog

What is new with Serial in Windows 10

by George Roussos [Microsoft]

https://blogs.msdn.microsoft.com/usbcoreblog/2015/07/29/what-is-new-with-serial-in-windows-10/

...

 

1.   Improved Serial over USB driver support in Windows 10

...

In Windows 10, we added inbox support for USB CDC Abstract Control Model (ACM) compliant hardware. Usbser.sys is now installed as a compatible ID match for USB CDC compliant hardware, without requiring a 3rd party driver or inclusion via modem INFs.

...

one of the 'elsewhere' :

Atmel

Tools Distribution

http://distribute.atmel.no/tools/opensource/Atmel-AVR-GNU-Toolchain/3.6.0/

 

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

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

mzimmers wrote:
any opinion on the USB drivers?
My WAG is Jungo.

 

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

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

Well, I notice now that the entries under "Jungo" in the device manager no longer have the alert icon overlaid on them, so I guess that's progress. I guess I can focus on the toolchain now. I was reading the README, and the installation instructions are rather sparse:

 

If you want to try the Atmel AVR8 GNU toolchain alone, you can download it from here1
● If you want to try the Atmel AVR8 GNU Toolchain along with Atmel Studio, you can download and install
Atmel Studio 7 or (newer) which will also install the Atmel AVR8 GNU toolchain. See Atmel Studio release
notes for more details.

So, I guess the two questions are: where should I put the directory tree, and how do I make Studio 4 aware of it? I've poked through the command settings and haven't found anything that looks right.

 

Thanks...

 

M. Zimmers
Cyberdata

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

mzimmers wrote:
where should I put the directory tree, and how do I make Studio 4 aware of it?
No answer though, IIRC, there's been a few threads here about that.

 

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

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

OK, no problem. Maybe I won't need it, since it appears that a debugger is already installed with 4, and that's all I need.

 

To summarize: I decided to forego Studio 7 and am successfully running 4 on Windows 10 thanks to this link:

 

http://www.avrfreaks.net/forum/studio-419-build-730-windows-10

 

It may be noteworthy that I didn't need to install any other drivers, though. Once I performed the installation, device manager showed the correct devices (the ISP and the JTAG) as loaded (no yellow warning sign), and it seems to run OK. I'm still not sure about my toolchain, but for my purposes what I have is sufficient.

 

Thanks again to EVERYONE who participated...this is a great forum.

M. Zimmers
Cyberdata

Last Edited: Tue. Sep 12, 2017 - 07:12 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Simonetta wrote:
On my recent laptop,  Studio 7 takes about 100 seconds to simply load from clicking on the icon to being able to type chars on the edit screen.   That's about 80 seconds too long for any program.  Bloated code is an indicator that the team that wrote it doesn't quite know what they're doing.  I'm not saying that the Atmel team is incompetent: I'm only saying that my gut instinct tells me that any program that takes more than a minute to load is not to be trusted because the developers pasted together miles and miles and miles of source code together into a big fudge mix. 

 

Well there's also another side, since for me its 7.5 seconds average on 10 attemps when launching (small)project from the directory.(about 5s to load AS7 and then half of that to actually load the source files in editor and show it).

And i allready consider my PC stoneage since it's 5 years old, expect the SSD drive's.

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

mzimmers wrote:
... and am successfully running 4 on Windows 10 thanks to this link:
Well done!

mzimmers wrote:
... since it appears that a debugger is already installed with 4, and that's all I need.

...

... (the ISP and the JTAG) ...

What's the make and model of the AVRISP and AVR JTAG debugger?

AVR Studio 4.19?  Yes blush

What's the Windows 10 version (via winver, ideally a build number)?

Reason : identification of a successful configuration

mzimmers wrote:
I'm still not sure about my toolchain, but for my purposes what I have is sufficient.
... because y'all have a copy of IAR EWAVR.

 


https://technet.microsoft.com/en-us/windows/release-info.aspx

https://www.iar.com/iar-embedded-workbench/?focus=wbselector#!?architecture=AVR

 

Edit : Yes

 

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

Last Edited: Tue. Sep 12, 2017 - 10:49 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Windows Version 1703 (OS Build 15063.540).

 

Both devices are Atmel: AVRISP mkII and JTAGICE mkII. There's lots of tiny numbers on the back, but I don't know if that's information you want. According to Device Manager -> Properties, the Driver version of both is 11.1.0.0.

 

I'd love to get the toolchain integrated, but there doesn't seem to be much Atmel instruction on it, so I'll live with what I have.

M. Zimmers
Cyberdata

Last Edited: Tue. Sep 12, 2017 - 08:04 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks!

mzimmers wrote:
There's lots of tiny numbers on the back, but I don't know if that's information you want.
I don't but an AVRJTAGICE mkII fyi is a serial number that starts with B is XMEGA capable.

mzimmers wrote:
I'd love to get the toolchain integrated, but there doesn't seem to be much Atmel instruction on it, so I'll live with what I have.
Should be no loss as IAR EWAVR is a "better" IDE than Atmel AVR Studio 4.

If it's EWAVR-LE then it doesn't have a debugger (i.e. operate AVR Studio); otherwise, EWAVR and EWAVR-BL have the IAR C-SPY debugger.

https://www.iar.com/iar-embedded-workbench/?focus=wbselector#!?architecture=AVR&currentTab=editions-and-licensing&readMoreBlock=Product%2520editions

 

Edit : strikethru

 

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

Last Edited: Tue. Sep 12, 2017 - 08:23 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'd like to return to this topic, if only for closure's sake.

 

So, I've been looking at some other, older threads about the problem that manifests with the warning:

 

gcc plug-in: No AVR Toolchain installation found. The AVR GCC plug-in can still be used if you set up your own build tools.

 

1. is the problem described here http://www.avrfreaks.net/comment/762690#comment-762690

still the case?

 

2. I have the gnu 3.5.4 toolchain. The installation instructions (in the PDF file) don't really tell you how/where to install. Can I solve the problem mentioned in #1 by appropriate location of this toolchain, or (as has been suggested in the past) do I need to manually invoke the compiler from AVR Studio 4?

 

3. do I correctly infer that I needn't bother with WinAVR for the purpose of getting a toolchain because 4.19 won't take advantage of it anyway?

 

Thanks.

M. Zimmers
Cyberdata

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

Up to 4.18 Studio 4 could automatically "see" WinAVR or Atmel Toolchain for Windows (it found them using a registry key) so just installing AS4 when WinAVR (or toolchain) was already installed lead to it being "seen" automatically. In the final issue of AS4 - that is 4.19 Atmel either deliberately (my belief) or accidentally changed things so it would NOT be able to see WinAVR. It only auto-detects Atmel Toolchain for Windows. I believe this was an attempt to try and get folks to migrate from WinAVR to their toolchain (which at the time was piss poor). So if you use 4.19 and WinAVR you have to manually edit the location of avr-gcc.exe and make.exe into the details of each project (what would have occurred automatically). If you use Atmel toolchain it *should* be able to see it. But this was getting on for a decade ago so it could be that modern toolchains from Atmel have stopped doing whatever it was that made them visible to AS4.

 

In any case if the toolchain cannot be found automatically just manually edit in the locations of avr-gcc.exe and make.exe

 

I wrote a sticky thread at the top of Studio forum a long time ago (before this new version of Freaks) that explained how to do this. I expect it is still there.

 

PS yes sticky thread is still there: http://www.avrfreaks.net/forum/f...

Last Edited: Tue. Nov 7, 2017 - 04:46 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks, clawson...nice sticky. So...it appears that I could use either the gnu 3.5.4 toolchain I have a copy of, or I could download WinAVR and use what comes from that. Should I favor one over the other?

 

M. Zimmers
Cyberdata

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

Depends whether you favour a compiler from 2009 or one from 2017 with tons more features and bug fixes. I know which one I would choose.

 

The one thing WinAVR has that these later toolchains don't have is a lot more "support utilities" - things like avrdude and Mfile. Atmel don't put those things in their releases so if you want them there is some argument to say install WinAVR first to add those tools and then replace the C compiler and linker in it with Toolchain for Windows.

 

Having said that some of those things (like the 8 year old copy of avrdude) are now starting to look a bit "long in the tooth" themselves so perhaps there's little/no merit in bothering to install WinAVR at all?

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

Ahh...I wasn't aware that 3.5.4 was that much newer. I've inherited all of these tools and am still making sense of them.

 

Any opinion on the Atmel debugger vs. avr-gdb? Hopefully one of them supports a windowed interface; I haven't done line debugging since Reagan was president.

M. Zimmers
Cyberdata

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

Just get AS7 and an Atmel-ICE and stop fannying about with the trip down memory lane!

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

I'd love to. In fact, I'd love to chuck the lot, and go with a new version of IAR. (I've heard very unflattering things about AS7.) Unfortunately I'm stuck with AS4 for at least a few months, if only for its debugger.

M. Zimmers
Cyberdata

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

mzimmers wrote:
Any opinion on the Atmel debugger vs. avr-gdb?
AVR Studio

mzimmers wrote:
I haven't done line debugging since Reagan was president.
AVR GDB is fine.

GDB's command line is portable and handy for getting data out of the target and for patches.

If want an alternative to Atmel Studio, VisualGDB runs with Microsoft Visual Studio and has an AVR tutorial.

If want multi-platform (Linux, ARM Linux, macOS, Windows), AVR GDB is being restored to PlatformIO and such is apparently in Visual Studio Code.

Some IDE have GDB (command line) in a window yet the operator can set breakpoints from the source code window.

 


AVR Studio User Guide

https://vision.fe.uni-lj.si/classes/GSPV/AtmelAvr-2004-2005/AtmelPrirocniki/AvrStudioUserGuide.pdf

(1019B-12/98)

AVR Studio User Guide

https://people.ece.cornell.edu/land/courses/ece4760/AtmelStuff/doc1019.pdf

Rev. 1019A-A–01/98

VisualGDB

Tutorials > Embedded > Getting Started with Boards

Developing firmware for AVR devices with Visual Studio

April 1, 2016

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

...

5. Once the toolchain is installed, select the device you are targeting from the list. We will demonstrate debugging based on the MEGA-1284P Xplained board, so we select ATMEGA1284p in this step:

...

7. When you open the Debug Method page, connect your debug adapter to the USB port and click “Detect” to auto-detect it. VisualGDB supports AVR debugging using the AVaRICE tool that works with the JTAG ICE Mk I, JTAG ICE Mk II and AVR Dragon devices. VisualGDB can automatically detect the JTAG ICE Mk II and AVR Dragon and setup the drivers for them:

GitHub

/platform-atmelavr

Debug probe support for atmel-ice / dragon and atmega328p processor #53

https://github.com/platformio/platform-atmelavr/issues/53

Visual Studio

Marketplace

Visual Studio Code > Debuggers > Native Debug

GDB, LLDB & Mago-MI Debugger support for VSCode

https://marketplace.visualstudio.com/items?itemName=webfreak.debug#review-details

...

 

Federico Zuccardi Merli

9/4/2016

I'm using this for embedded debugging, through OpenOCD and other gdb servers. No major issues, but ...

 

...

 

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

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

mzimmers wrote:
(I've heard very unflattering things about AS7.)
Several to most of that is simply due to lack of configuration control the most prevalent being a Windows 10 update made Atmel Studio 7 non-functional (driver, .NET)

Ideally the ones at Cyberdata have one there who does IT and can keep you in Windows 10 and Atmel Studio else one can hire a MSP.

 

Microsoft logo

Microsoft

TechNet

Microsoft US Partner Community blog

Category: Managed Services Provider

https://blogs.technet.microsoft.com/msuspartner/category/managed-services/

 

Edit: strikethru

 

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

Last Edited: Tue. Nov 7, 2017 - 07:16 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK, I'm going to give Atmel Studio 7 a go. My first attempt at importing a AS4 project failed - actually what I attempted to import was an .aps file. Here's the error:

 

Conversion Failed:Project Import Failed : The specified object file is not found in the specified location of the source project C:\Users\MZimmers\CD firmware apps\WiFiButtonBase - Atmel Studio 7\WiFiButton\Debug\Exe\WiFiButton.dbg [Activity : Saving Atmel Studio 7.0 Solution]

 

I didn't create the AS4 project; it was given to me. What should I be looking for?

 

Thanks for the help.

M. Zimmers
Cyberdata

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

mzimmers wrote:
give Atmel Studio 7 a go. My first attempt at importing a AS4 project failed

Again, given that AS4 is sooooooo old, that's probably not a big surprise:

 

 

In #6, I wrote:
Because 4 is so far behind 7, it rather unlikely that any "automated update" is going to work - which probably explains the error you're getting.

 

So I'd probably go with clawson's suggestion and re-create the project form scratch.

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

I am gobsmacked. If you are a paid employee, your company should provide the necessary software and tools.
.
If you are experienced with IAR, your employer would buy the IAR licence and get 100% productivity from you from day one.
A Pizza company would supply their drivers with a scooter and petrol so that you can make your deliveries.
.
If your company wants you to use AS4 or AS7, they should have considered the "learning time" when they are paying your salary without getting anything for it. (except for avoiding the IAR licence fee)
.i
It is completely different for a hobbyist. I can spend as much time as I want. Any licence cost comes out of my pocket. I make my own "value for money" decisions.
.
If you start with no experience of IAR or AS7 your employer has a harder choice.
.
David.

Last Edited: Thu. Nov 9, 2017 - 10:00 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That was my point in my early replies here - up to ~ #8

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

Hi awneil -

 

I'm not turning a deaf ear to the idea of starting from scratch; I just wanted to preserve as much of the existing environment as possible. Anyway, I figured out why the import wasn't working -- the import facility was expecting a .dbg file in a particular location, and not finding it. I built that .dbg file (with IAR) and the import now works. I found another link that talked about cleaning out the old Jungo USB drivers, and now I see the ISP and JTAGICE devices under "Atmel" in Device Manager. So...progress is definitely being made.

 

But...when I try to enter debug mode, I get an error about "JTAGID not valid." And indeed, it doesn't look right:

 

Any idea what I need to do to get this corrected?

 

Thank you.

~~~~~~~~~~~~

UPDATE:

 

I re-did my import after removing some extraneous files. I think it's working now - I can start the debugger and step through the program. When I try to use the GNU debugger I get an error about not having an ELF file, but the built-in debugger seems fine for my purposes, so I'm not going to beat this to death.

 

Thank you to EVERYONE who helped me with this.

 

M. Zimmers
Cyberdata

Last Edited: Thu. Nov 9, 2017 - 06:18 PM