So, after some long waiting, the 634 update has arrived. Available from web or through the update notification that most of you should be getting/have gotten inside Atmel Studio (a notification flag on the top right, besides the quick-launch box).

The major points that are fixed is

AVRSV-6873 - Jungo driver issues

AVRSV-6676 - Launching debug fails due to Intel graphics driver

For the Intel graphics driver issue, it was discovered that it was an unfortunate dll load order that ultimately caused the Intel VGA driver to bark at us. Why the issue manifested there, we don't know, but Microsoft has provided us with a fix that we apply internally in the what is called the debug engine. Here we change dll preferences before the launch happens, and the issue should be fixed without any modification to the PATH environment variable that we have provided as a workaround. Note that we still show a warning in the installer if you have a driver version that falls into the versions that we have gotten reports on. This is mainly precautionary now that we have a fix, and can most likely be ignored (to the extent that Data Visualizer might also show some issues with this driver).

As for the Jungo driver, the fix is not that nice. We have had, after discussions with Jungo, to update the Jungo driver from version 11.5 to version 12. Unfortunately this version of Jungo breaks backwards compatibility with Jungo 11.5 or older. This means that, if you want to use Atmel Studio 6, AVR Studio 4 or 5, IAR, ImageCraft or mostly any other programming software that uses the Jungo API (wdapi) directly, this will no longer work. The workaround, as described here, is to install whatever you want to use before Atmel Studio 7.0. This will cause the older Jungo driver to be installed and bound to the USB device first. Then, install Atmel Studio 7.0.634 which will update the Jungo driver and rebind the USB devices, but it will leave the old Jungo driver behind. This makes it possible to switch between versions of the driver through the Windows device manager.

The Jungo issues does of course only affect our 'older' programmers and debuggers that use Jungo. From JTAGICE3 (firmware version 3) we use HID as the main USB stack, which is not affected (exception is the bootloader on the JTAGICE3, which is also Jungo). And before you start complaining, yes we do know that the solution is not optimal (aka shitty). But, it's the best one we have been able to find. Hopefully, in time, our third parties will also update to Jungo 12 and the issue should become less prominent.

Note that we are also requiring SHA2 based signing on the drivers now. If your machine does not support SHA2, then you will get a warning during installation and the Jungo driver will not load. To fix this apply KB3033929 from here.

In addition to that, we are also pushing out a new license to Xeam in this build. Xeam is a component in the installer, and the previous perpetual license (that expired) we used have been changed to a more perpetual license. Most of you who upgrades will unfortunately see the Xeam License expired issue, as the old license is validated before we are able to update it. Just click continue, and enjoy the ride.

:: Morten

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

No, the driver bundle is a separate product from Atmel Studio (although, parts of it is included in Atmel Studio as well of course). I have not yet had time to roll a new driver bundle with the Jungo 12 changes, so the 888 version of the driver bundle still installs Jungo 11.

:: Morten

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

"In Atmel Studio 7.0, the Jungo driver was changed to support Microsoft Windows 10" - does that mean that the old driver bundle (driver-atmel-bundle-7.0.888.exe, or whichever is the latest) does not support Windows 10?

The current driver bundle (888 is it?) installs Jungo 11. In other words it exhibits the same issues. Rolling a new (dual?) bundle is on the plan, but since its only studio 7 that can use the new driver it's not that critical to roll it out (more critical to fix the issue).

:: Morten

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

Should be fine. Just note that during the 7 install the drivers will/should rebind to the new drivers ( depends a bit on the windows version if this only applies to new/unknown tool or all). So just follow the FAQ linked to change the driver back if they disappear from Studio 4.

:: Morten

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

However when I tried to install it with regular user credentials under Windows 10 it failed.

I have installed Studio 7.0 as administrator, and I had to log-in as administrator again in order to install the help content. Only applying the administrator password when asked while installing the help content was not sufficient.

Thank you Morten.

Great dedication to provide support during the weekends, much appreciated!

Great dedication to provide support during the weekends, much appreciated!

I don't provide support... I'm here only as myself. I was a freak before I started working at Atmel :)

We do not yet support online help. (I. E you'll have to download what you want yourself through the manage help entry, also in the help menu).

I think I have to modify myself here a bit. We do actually support single lookups (i.e F1 in different windows when Online is used, will actually show a online page similar to the one that is downloaded). However, links on this page does not work at the moment, so we don't claim it to be in a production state yet :)

I have installed Studio 7.0 as administrator, and I had to log-in as administrator again in order to install the help content. Only applying the administrator password when asked while installing the help content was not sufficient.

Hmh, it should have been... Might be somethings I haven't thought of though. Currently, the local help store is at the same location as Visual Studio has its, in 'Program Data'. There's usually need for admin to write into this catalog... We were thinking about having it in a user local place (i.e AppData), but that would mean that each user in a multi user system would have to install their own 'cache' of content, which is a bit wastefull. So for now, we keep it in a system-folder...

:: Morten

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

Is Atmel aware about problems with Atmel Studio 7 and AVRISP mkII? The original programmer and its clones were working well with AS6 but there are issues with AS7 on some machines. The programmers are properly detected by both Windows and AS7 but they don't work. AS7 reports ModuleName: TCF (TCF command: Tool:connect failed.) write error. I suppose the problem must be somewhere between AS7 and Jungo drivers. I hoped build 634 would resolve this but it didn't.

I have a problem with atprogram.exe from Studio 7... specifically for UC3L, specifically when the Secure bit is set... specifically during Erase (you can't go any farther when the bit's set anyway). This is bad, since we use this program for production (how else are you supposed to program Atmel chips for production?)... now, since Win10 updated, I can't program UC3L's a second time. I can try releasing this to the company doing our boards, but I'd rather it didn't *flake*. Curse Win10, curse Studio 7. Filing a ticket on this now.

First I want to be clear that I'm new to studio 7 but not to software development.

A little history, My system is an HP g70-250us laptop with windows 7 pro and 4 gigs of memory. I first installed Atmel studio 7 about a month ago version 7.05xx, don't remember the exact version and it is no longer on my machine. I was having problems trying to get the simulator to work so I installed the newer version 7.0634?. The first problem came during installation, the installation took abut 2 hours!The first 75% or so installed in 5-6 Minutes, the last 25% took the best part of the two hours.

After installation my system turned into the worlds slowest machine, my old CPM machine would have put it to shame, no contest. The simulator still would not run more than once. After that it kept complaining about setting a tool and just repeatedly timed out looking for it. All during use of both versions it took several minutes to load a simple project and things were always sluggish at best.

I then uninstalled Studio, a project that took another 3 hours. Afterwards my machine was trashed. It took two full days of restoring and rebuilding to get back to something like it was before installing Studio. I tried to "upgrade" my video driver but windows thinks it has the best version already. I went to the HP site looking for the most current video driver and their driver update tool actually installed an older version of the driver. Backing that out and re-installing the previous driver made no change in operation.

I have another machine in my shop which is a dell 2.0 Ghz duo-core with 8 gigs of memory. That one still has the previous version. The Simulator on that version does the same thing, runs once and then hangs trying to find the simulator. If you recompile to fix a code error it simply times out looking for the simulator tool. The dragon tool seems to work fairly well it is just hard to debug interrupt driven RS232 stuff with an emulator so I thought I would try the simulator just to see if things look close.

My real questions are: Has anyone else exhibited this kind of lockup/system slowdown problem? What is the trick to making the simulator restart? As an aside, does studio 7 like windows 10 better?

My current opinion of Atmel Studio 7 is it is worse than a virus but I'm open to a fix to solve this.

The simulator issue is related to some of our oldest models that uses an exstra .dll that is not properly unloaded when ending the first simulator session. You don't mention which device you were using, but if it has a PB-variant you could try that instead. Those are newer and does not use the problematic extra .dll.

The fix for this problem unfortunately involves some changes to the backend of Atmel Studio, so it won't be fixed until the next update of Atmel Studio.

Do you have any idea what may have caused the massive slowdown? It not only slowed Atmel studio but the computer in general. To fix it I had to go back to a restore point just prior to trying to upgrade the Studio version.

Is this going to affect other, non-Atmel, software which uses the Jungo drivers?

#1 This forum helps those that help themselves

#2 All grounds are not created equal

#3 How have you proved that your chip is running at xxMHz?

#4 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand." - Heater's ex-boss

This is very frustrating. I received my new laptop and loaded up most of the programs I normally used and then tried again to load in studio 7.063. During the load I got to the point where it shows requirements and does the driver check and every thing was green so I proceeded, during the install I got a error that said check a log file for why it failed, The log said it couldn't find apex.dll. I then restored my computer to the point just before installing studio and tried to install 7.0582. That complained about a problem with visual studio, Something about the visual studio license being expired. I went on the web and tried to install visual studio and then tried to re-install studio 7, still no luck something about the asfpackage not loading.

Does any one at Atmel actually try to load a release on a virgin computer? I don't mean one where you unload a previous version and reload the software, that leaves files behind and is not a true test of an install package. At a company I used to work for we used to keep a hard drive image around that had a basic system on it and used it to create a new system each time we tested a release.

The point is: am I the only one that has had a hard time getting a working copy of studio 7 installed? I didn't have this problem a month or two ago when I loaded it on my workshop machine, nor for that matter on my older laptop before I tried to use the simulator and then tried to upgrade . This appears to be a fairly recent problem. Also, as a side note, the older laptop had studio 6 installed prior to installing studio 7. Thinking about it, even before trying to use the simulator, Studio 7 was always sluggish, things like using ASF and adding selections to it took several minutes each time a change was made.

What am I doing wrong? This is all under windows 7 professional on all machines. The new laptop is a HP icore7, 1Tb hard drive and 16Gb of memory running win 7 pro out of the box. I really want to avoid Win 8 or 10.

I have been using Atmel Studio 6 with my ASVRISP for a couple of years without any issues. Since upgrading to Windows 10 Atmel Studio does recognise AVRISP mk11. I have purged my system (I think) and reinstalled Atmel Studio version 7. When I look in the device manager with it connected I get a code 39. Looking at the diver details for WinDriver the details are Jungo connetivity Driver date 26/01/2014 Driver version 11.5.0. Looking at the AVRISP mk11 driver details it shows Jungo Ltd Driver date 12/08/2015 Driver version 12.0.0.0. looking at the evnts window I get the comment "Device USB\VID_03EB&PID_2104\000200120890 requires further installation". Any clues as to how to resolve this problem.