Atmel Studio stopped seeing AVR Dragon; possibly Win 10 update related

Go To Last Post
180 posts / 0 new

Pages

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

I have the same problem. Zadig workaround seems to work for me but of course not a good solution because I also get teardown error. Also I have a laptop with windows 10 that still recognizes MKII without the workaround. I tried to copy windrvr6 as suggested above from working laptop to a computer which shows symptoms but it didn't work.

Also... I have tried to program an old system using the workaround. When I tried to set break point and single step it took unusually long time for a single step. The system had a ground loop surge current recently that could damage the chip but voltages seems ok. so I'm still not sure it is also a side effect of workaround or it is due to the surge damage. I will investigate it further.

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

I'm convinced that problem is with windrvr6.sys . version 11.1 works but version 11.5 and afterward does not work. "anykey" supplied file works but it will give digital signature error so another workaround is disable digital signature enforcement on windows 10 and it works.
 

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

Ok I solved the problem , hopefully it works for you too. I found a working windrvr6.sys (no digital signature error) on my laptop but not where you expect I mean not in Windows\System32\Driver\   but I searched the whole windows directory and I found older version of windrvr6.sys on a directory that had some GUIDs(lots of meaningless digits and letters) in its path. I copied the older windrvr6.sys to computer that shows the symptoms and problem gone. I emphasize a few  points:

1- I uninstalled completely libusb driver so I'm not using the zadig workaround.

2- Driver inside windows\system32\driver\ of the laptop that was ok was newer version(11.5) of windrvr6.sys which won't work on computers that show symptoms. I found older version in other directory

3-the new file does not show digital signature error to me and it works

4- this is from a windows 64 bit and may not work for win 32

5- this file is newer version than anykey file. theworking driver is version 11.1

 

I think following solution should work

1-Copy(overwrite or rename old file) the new file in Program Files(x86)\Atmel\Atmel USB Drivers\Jungo\usb64\

2- Uninstall any libusb if you already installed one and delete files

3- After restart select not working driver in device manager ans select update driver, select let me pick the driver and browse to

programfiles(x86)\atmel\atmel usb drivers\inf\JtagICEmkII\

hopefully the new driver that you had copied will be picked up and it works after restart

 

I hope it helps.

Ebi

 

 

 

Attachment(s): 

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

Irtech, this didn't work for me. I did this:

- renamed the original windrvr.sys (11.5) in Program Files(x86)\Atmel\Atmel USB Drivers\Jungo\usb64\ and replaced it with the one in the zip (10.21)

- in device manager I removed the Dragon and WinDriver devices with the uninstall driver software option, because windows didn't do a downgrade

- I pressed scan for new hw, the dragon was recognized, and I pointed to Program Files (x86)\Atmel\Atmel USB Drivers\inf\AVRDragon

- the windriver wasn't reinstalled that easy, the add legacy hw wizard had no drive under the Jungo vendor (because I intentionally removed it)

- I went to Program Files(x86)\Atmel\Atmel USB Drivers\Jungo\usb64\ and did rightclick install on the inf file

- after this I could install it with the add legacy hw wizard

- the windrvr.sys in the windows/DriverStore is the version from the zip (filesize, version match). Though rightclick properties still shows 11.5 in the device manager, but I assume it's just because I didn't hack the inf file too in Jungo/usb64, only the sys

 

Anyway, I rebooted, and Atmel studio still lacks the dragon.

 

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

"I fired up an old Windows Vista x64 machine, installed AS 6.2, and the Dragon works fine with the same target."

 

 

If you value your time at least $20 an hour, then after four or five hours of futzing around with junk software ( and ANY new version of Windows is junk until proven otherwise), then you have spent enough to have bought a used old Windows Vista x64 that could be dedicated to only running AS 6.2 with a Dragon interface. 

 

There are several 20th century ideas that should be occasionally reevaluated.   One is that a PC runs all PC software.  So we go buy the latest and greatest computer (or installing a new version of the Operating System, which is the same thing), and spend many hours trying to get the software that we already have working on the 'old'  computer working.

 

Another is that it is a waste to 'tether' a single application to a single PC machine.  But if it works OK, and the cost of installing and making functional an application on a new OS is greater than the cost of a used machine that has proven to run the application well, then by all means, reserve a PC to a single application.   Every tech office and lab in the world has at least one 'really old' PC that is running only a critical application.   Remember, Microsoft could care less if your software runs on 'their' OS: they only care if 'their' software runs on their OS [after you have paid them a ton of money].

 

Call me superstitious, but I believe that software has entropy.  On the same box, the same code will run correctly for only so long.  So enough chaos develops into the system to prevent the software application's running correctly.  That's why I never update anything (except my own skill set).  Most chaos enters into computer systems through OS and application updates.  Since these are mostly proprietary of the company that supplied them, and that company never has complete details and documentation of the Redmond Rednecks' latest update, the third law of Energy applies to computer systems as it does to any other closed system. 

 

Which is why your Dragon doesn't work anymore.

 

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

twinsen,

Do you also delete driver software when you uninstall ? if you delete the driver software then still the newer driver is picked up from another place. what I wrote above are steps that actually tested by me and worked for me. I have not tested the following and I don't even recommend it but as a suggestion maybe if nothing else works searching all windows, program files, program files(x86) and User directories for windrvr6.sys and replace it(rename current version) with older driver works. but I suggest you keep track of all places that you change the driver so you can revert if something went wrong. Also note that size of older version is different than newer version. Anyway as I said above currently driver shows version 11.1 to me not 10.2 or 11.5 ( I think 10.2 was any key driver version, but I could be wrong). 11.5 definitely won't work.

 

Simonetta,

Personally I don't like the idea of filling my office with museum hardware. fortunately in this case I could solve at least my own problem but if I couldn't I would buy a newer ICE. but I understand that this situation may happen in a really bad time for some people when they have very tight schedule and even 24h may damage their career. so what I do after more than 20 years of experience is to have a few virtual machines on my main computer for when murphy's law shows up in the wrong time and the wrong place. the good thing is I also can copy the virtual machines to my modern laptop and when I go to customer place I don't need to carry a few laptops. But I learned that even this may not be enough so as a last resort I have an extra HDD with an older version of windows that everything works on it. well I rarely work with virtual machines and the alternative OS so they are not updated but my main computer and laptop  are always up to date and I think it is a very bad idea that you connect to internet or even a LAN with an out of date OS for a long time.

 

Cheers

Ebi

Last Edited: Tue. Sep 22, 2015 - 06:34 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi guys,

 

Irtech's advice kinda worked for me!

But I did it a bit different:

1. I removed the Dragon driver and the WinDriver using the device manager. Also make sure you have no libusb drivers left on your system. (And yes, I went through the registry for hours deleting all traces of libusb ...)

2. I replaced the windrvr6.sys in Program Files(x86)\Atmel\Atmel USB Drivers\Jungo\usb64\ with Irtechs windrvr6.sys

3. I installed the WinDriver again using the driver in Program Files(x86)\Atmel\Atmel USB Drivers\Jungo\usb64\

4. I installed the Dragon again using Program Files (x86)\Atmel\Atmel USB Drivers\inf\AVRDragon

5. Reboot

 

But with this steps the Dragon still didn't show up in the Atmel Studio

 

So I made one more step which I think brought the Dragon back to life:

1. I just replaced/renamed the windrvr6.sys in C:\Windows\System32\drivers using Irtechs version. You may need to go into windows safe mode. I also had no signature error.

2. Reboot

 

After that I could use the Dragon normally again. Thanks Ebi!

 

Sorry for the vage description but I hope it helps.

 

-lexman

 

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

I'm gonna wait. Someone surely must come up with a fix soon?

In the meantime i've

1) reverted to win. 7

2) I'm using, for one dev env (I have one at work, identical prototype at home) an Atmel ICE basic - which at the moment is priced (Farnell Finland) cheaper than the dragon. If only it were'nt for that crappy fragile cable....I noticed digging on Google that someone's made an adapter card that glues to the top of the ICE, giving back sensible sockets. He hasn't released the Eagle files, but the schematic and layout are presented as .png's. Should be a couple of hours' work. Then, regrettably, it'll be goodbye dragon (mothballed, anyway).

As Simonetta above says, if you value your time...well, I'm unemployed ("at work" above is "work experience" to get me off benefits. Work Experience?!?!  I'm 59, FFS!) but even I can stretch to an ICE Basic.

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

Any update on this? Seems like a rather severe error should get attention at Atmel.

Dana  K6JQ

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

danak6jq wrote:

Any update on this? Seems like a rather severe error should get attention at Atmel.

I already wrote the Atmel representative that was participating in this thread a PM a few days ago. No response so far. I would really like to see some progress. I used the LibUSB workaround from this thread to make the devices visible in AS6, but I can't use any command line scripts or our command line based production utilities which really hurts productivity.

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

I wrote them too and told them about my STK600 issues and the liubusb workaround .

They replied after a few days and said they will forward that to someone else up the food chain and let me know if there is an update.

 

The libusb workaround is an OK emergency solution , but it hangs at times and says the tool is busy and one needs to restart Atmel Studio to fix that.

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

Mr. foodchain is back! Sorry for being inactive, been some very busy weeks lately...

 

So, I guess you're interested in the current state of the matter... smiley

 

The first week or two after the inital reports, we were working on getting a reproduceable setup of the issue. However none of the machines in our lab setups seemed to get this issue, updated versions or clean install versions.

 

While we were working on reproducing the issue, I have been looking at the timeout issue that also was reported on libusb0, just to have a backup plan. The blocking issue has been resolved in the latest build internally, and atfw has also been updated to function properly withlibusb0. Both these changes will be available in 7.0 release. There are however some issue with replacing Jungo with libusb. Firstly, atprogram does not work correct currently. Secondly earlier versions of Atmel Studio will stop recognizing the tool, and we have also not been able to validate this USB stack as well as we want. 

 

This week we finally got a machine with the symptoms, and we started looking into upgrading Jungo from the version shipped in 7.0 beta to the newest v12 which is the first driver version to claim Windows 10 support. Normally in this case, we just upgrade the kernel driver, since that have until now been API compatible with earlier versions. In version 12 however, Jungo really broke that compatibility. To manage this, we would have to relink our usb stack to the new API (quite easy). However we will also have to rewrite all the inf files for the tools that use Jungo, and by that breaking compatibility with previous Studio versions again.

 

So, we are currently working through all the different scenarios, looking for the best way out. That means however that for now, Studio 7.0 might have this issue on Windows 10. Current workaround for that is the libusb0 driver change shown earlier in this thread, with the note that atprogram will not work in this setup just now. 

 

More news to come once we are able to find the correct way out of this mess (although, I'll be away the next couple of weeks, so maybe not from me directly).

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

For same problem.

Windows 7 64bit

Atmel Studio 6.2

Atmel Studio 7.0

 

See text file in attachment

 

Attachment(s): 

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

Anybody brave enough to try this with 32-bit, as josbluet has kindly provided the 32-bit directory?

Oh, and where do you get Studio 7 from? Blowed if I can find it!

-Cheers

-Andy

 

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

Thanks! Dunno how I missed it.

-Andy

 

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

I'm just another user who can no longer access AVR Dragon.

I'm using Atmel Studio 6.2 and 7 and it was working before I updated to Windows 10. Now it doesn't

 

Is there any official word from Atmel on a solution? I don't really want to mess around with moving USB drivers manually.

SpiderKenny
@spiderelectron
www.spider-e.com

 

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

AARRGGGHHH!!!! I installed 7 and now the "fix" that had been working for 6.2 no longer works!

 

Atmel: I have coding and product deadlines! You're killing us here. I now have to drop back and waste more time trying to figure out how to fix (and I use this verb loosely) this - AGAIN!

 

When can we expect an answer? This was reported more than 2 months ago. Maybe you should have concentrated more on fixing the bug at hand instead of introducing a new version of AS. It's wonderful to work on improving and extending products, but not at the expense of something as critical as being able to download code from your studio thru your programmer to my board. I don't have the option (or the desire, really) to change companies, but you're certainly losing ground here.

 

Again: AARRGGGHHH!!!!

The SiliconHacker  Plano, TX  www.siliconhacker.com

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

I raised a tech support ticket with Atmel for this and got a reply that just pointed me to this forum.

The libusb filter technique does work with Studio 7 too. You probably just need to re-apply it. Although, I find that programming often fails, and I've had to drop the programming clock rate to just 64 KHz for it to be reliable.

Every now and then the programming dialog just locks up and I have to terminate AS7 from the task manager.

 

I also worry about how the libusb trick might interfere with a proper fix from Atmel.

 

I would truly love to see a proper corporate response to this issue posted in this forum. The lack of which is doing harm to Atmel. As professionals, do they really expect us to use 3rd party fixes and workarounds?

 

I simply cannot trust the workaround - it doesn't give me that warm fuzzy feeling that all is OK.

I truly wish Atmel would give us a detailed response here.

SpiderKenny
@spiderelectron
www.spider-e.com

 

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

I'm using JTAGICE mkii and suddenly it stopped being detected (I already was on Windows 10). I'm replying because someone suggested use: libusb-win32-devel-filter-1.2.6.0 and it worked for me! Now Atmel Studio 6.2 detects the JTAGICE again! Now going to test if it also works fixes Atmel Studio 7 (I guess it will.)

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

 

I'm OK at the moment, but this is a real challenge to AVR development. The libusb-win32-devel filter is a far less than satisfying work-around. I hope this is escalated at Atmel.

 

 

Dana  K6JQ

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

 

If anyone wants to try another workaround, the details are here: #2

 

 

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

Atmel seems to plan to fix the problem we all have in the next version of Atmel studio 7 , after build 582.

 

Lets hope it'll work.

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

I have been trying to apply this fix but am not sure I have got the correct files and method, could someone point out (link) the best instructions and the files for a 32 bit system. I know its in the forums somewhere but I'm missing it. Time to give up and ask for help.

I also just tried the second method posted by danv above with no success.

 

Thanks in advance

 

Mark

 

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

The workaround described by Danv ( https://www.avrfreaks.net/comment... ) seems to have solved the problem on my PC.

Both Dragon and AVRISP mkII are now shown in Studio 7.0 and can be used

Anykey

Last Edited: Wed. Oct 7, 2015 - 12:58 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Danv's post has fixed this for me too (now I have the filenames correct blush)

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

Danv's post has fixed this for me too (now I have the filenames correct blush)

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

I tried the Zadig fix on two Win10 systems. While the Dragon now appears in the picklist, programming appears to quietly fail on AS 6.2 and hard fails with a NULL reference exception on AS 7. What a mess!! I'm completely at a halt for testing code.

 

Atmel: My (new) company is in real jeopardy because of this. Assuming you get this fixed in the foreseeable future (hopefully before I go bankrupt), PLEASE, DON'T LET THIS HAPPEN AGAIN! Supporting existing products and CUSTOMERS who believe in and use your products are WAY more important than developing the next/best AS.

The SiliconHacker  Plano, TX  www.siliconhacker.com

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

 

Hi Phoenix

Did you give "my" fix a try ? It should work for 6.2 as well if you follow the instructions.

 

We share your frustration with the USB driver. This is something we source from a third party  and the driver we´re installing in Studio 7 does not seem to be compatible with some Windows 10 and 7 systems. We cannot figure out why and the 3rd party is not very helpful either. The "fix" is installing new drivers and switching Studio to work with them.

 

Regards, Dan

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

Dan:

 

Thanks much for your recommendation; I tried your fix on laptop#2 (Win10, AS 6.2, Dragon) and it worked.

 

I'm neck deep in code at the moment (trying to make up for lost time), but I'll try the same fix and laptop #1 (Win10, AS 6.2 & AS 7.0, Dragon) hopefully tomorrow or Friday (on both AS 6.2 and 7.0), then report back.

 

Again, thanks for taking the time to point me to that solution. I really appreciate it.

Dave

The SiliconHacker  Plano, TX  www.siliconhacker.com

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

Dan:

 

I tried the fix on laptop #1, for both AS 6.2 and AS 7.0, Win10, Dragon; both AS versions are working now. Again, thanks so much for posting the fix. Hopefully, we'll see this rolled into the production version of AS 7 soon. At least I'm back online and able to test new code (which is really critical at this time).

 

Dave

The SiliconHacker  Plano, TX  www.siliconhacker.com

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

Hi,

 

The fix by danv also worked for me. Previously I had problem with detecting AVR Dragon using Win10 upgraded from Win7 with AS 6.2.1563 SP2.

 

Thanks

 

/LL

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

 

I've installed AS7 + 'fixed' USB package, and once I (tried to) undo the damage I'd done tinkering with this, AS7 + AVR Dragon appear to be working for me again, on the same Win 10 system I initially reported this from :-)

 

Thanks -

Dana  K6JQ

 

Dana  K6JQ

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

Dan:

 

Well, it seems the honeymoon has ended. After installing your fix last Thursday, it worked for four whole days. This morning, I can't get the Dragon or the mkII to show in the tools list. Any suggestions?

 

To say that this is frustrating is an understatement of epic proportions. We need a permanent, reliable fix.

 

Dave

The SiliconHacker  Plano, TX  www.siliconhacker.com

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

 

 

Hi Dave,

 

Sorry to hear this. Can you check that the devices do show up in the Device Manager, and that their driver is windrvr12.sys ?

Also, check again that the DLL in the codecache directory is the "patched" one.

 

For Studio 6.2 please enable "Diagnostic logging" in Tools Options Debugger. Open the Output window, look for the Backend agent tab. Do you see some WD_Init error messages ?

 

 

Tnx, Dan

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

Duplicate

Last Edited: Mon. Oct 12, 2015 - 06:39 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Duplicate

Last Edited: Mon. Oct 12, 2015 - 06:39 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

I'm sad to report the same thing - while the 'fix' made it possible for AS7 to 'see' my Dragon, it never leaves the 'Disconnected' state and after a reboot is no longer visible. Since I tinkered with libusb-win32 and devel-filters and such, I may have some junk laying around that breaks things, though I really did try to excise it all.

 

 

Dana  K6JQ

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

A bit of background:

When a tool is Disconnected, it has been "seen" by Studio, but it doesn´t enumerate any longer (left the bus, or connected to another driver)

The "fix" sets windrvr12.sys as the kernel driver to be used by JTagIceMk2 , Dragon, Ispmk2, stk600 etc (the old driver was windrvr6.sys)

The new DLL is necessary to make Studio load the new kernel driver.

windrvr6 .sys does not support windows10 according to Jungo, who provides windrvr12.sys as the new Win10 compatible driver.

So we had big hopes that make use of windrvr12 the problem on Windows 10 would be gone, and it was until Dave and Dana reported back today.

One possibly missing piece of the puzzle is that Studio (as is) still uses an old windrvr license string, which may need updating. 

If Dave and Dana could report back the Jungo error messages (should show up in the backend log) we may be able to pinpoint the problem.

 

Here´s how to get the backend log:

http://atmel.force.com/support/a...

http://atmel.force.com/support/a...

 

 

 

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

Dan:

 

Ok, here's what I've found:

 

The (renamed) WDAPI1010.dll in the 7.0 C:\Program Files (x86)\Atmel\Studio\7.0\atbackend\codeCache directory shows property details: File Version 12.0.0.0, Date 10-7-2015. This should be the one that you distributed.

 

In the Device Manager, with the Dragon plugged in, I see THREE drivers listed under Jungo:

AVR Dragon

WinDriver (11.5.0.0)

WinDriver1200 (12.0.0.0)

 

From the log file:

 

13:27:41.385: 01 27 41 385: msg recv(c8):C 2 Tool pollForTools true
13:27:41.386: 01 27 41 386: msg send(c8):R 2
13:27:41.386: Tool:pollForTools 1.9973 msecs
13:27:41.398: 01 27 41 398: usb WDU_INIT failed: No valid license (0x20000009).
13:27:41.399: 01 27 41 399: msg send(c8):E Tool attachedToolsChanged [{"ToolType":"com.atmel.avrdbg.tool.simulator","ConnectionType":"","ConnectionProperties":{}}]
13:27:41.399: Got Tool::attachedToolsChanged([{"ToolType":"com.atmel.avrdbg.tool.simulator","ConnectionType":"","ConnectionProperties":{}}] ) event, notifying listeners
13:27:42.412: 01 27 42 412: usb WDU_INIT failed: No valid license (0x20000009).
    ... [removed 116 copies of the same message]
13:29:40.641: 01 29 40 641: usb WDU_INIT failed: No valid license (0x20000009).
13:29:41.391: 01 29 41 390: msg recv(c8):C 3 Tool pollForTools false
13:29:41.643: 01 29 41 643: msg send(c8):R 3
13:29:41.643: Tool:pollForTools 257.1838 msecs

 

I enabled the diag setting per the links. The output window shows this when the Dragon was unplugged:

 

02 37 46 441: msg recv(e8):C 5 Tool pollForTools true
02 37 46 442: msg send(e8):R 5
02 37 46 472: usb WDU_INIT failed: No valid license (0x20000009).
02 37 46 474: msg send(e8):E Tool attachedToolsChanged [{"ToolType":"com.atmel.avrdbg.tool.simulator","ConnectionType":"","ConnectionProperties":{}}]
02 37 47 502: usb WDU_INIT failed: No valid license (0x20000009).

    ... [deleted multiple copies of the same message]

 

It keeps repeating the following before and after the Dragon is plugged back in:

 

02 38 33 779: usb WDU_INIT failed: No valid license (0x20000009).

 

So, is the issue that Jungo still lists the "old" 11.5 driver? If so, how do I get rid of it? Does this confirm the theory of the old license string?

 

I'm more than happy to perform whatever diagnostics/etc. that I can. I really need this to be resolved.

Dave

The SiliconHacker  Plano, TX  www.siliconhacker.com

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

I am not sure that having 11.5 around is a problem, since the tools themselves are bound to windrvr12. 

 

The license error string could indicate that the old license we used is no longer valid. Perhaps the driver has a grace period of a few days, after which it stops accepting old licenses.

I will build a new Atmel Studio 7.0 com.atmel.hil.usb   with an updated license string and make it available here, but it might have to wait til tomorrow . 

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

Dan:

 

Be happy to try it when it's available. Thanks for your help.

 

Dave

The SiliconHacker  Plano, TX  www.siliconhacker.com

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

 

Can you try  this one  https://www.dropbox.com/s/w0gkok...? Freshly rebuilt for Atmel Studio 7.0 only.

Drop it in the code cache folder, should replace the existing one (which you of course rename to .backup).

 

Crossing toes and fingers... If it doesn´t work, what is the Jungo error message ?

 

Thanks, Dan

 

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

Dan:

 

With AS 7 not running and Dragon not plugged in, I dropped the replacement com_atmel_hil_usb.dll into codeCache as requested.

 

Plugged in Dragon, nothing put to Output window. Log file shows

 

15:58:46.599: 03 58 46 599: msg recv(e8):C 2 Tool pollForTools true
15:58:46.599: Tool:pollForTools 2.0013 msecs
15:58:46.624: 03 58 46 599: msg send(e8):R 2
15:58:46.948: 03 58 46 948: msg send(e8):E Tool attachedToolsChanged [{"ToolType":"com.atmel.avrdbg.tool.simulator","ConnectionType":"","ConnectionProperties":{}},{"ToolType":"com.atmel.avrdbg.tool.avrdragon","ConnectionType":"com.atmel.avrdbg.connection.jungousb","ConnectionProperties":{"Type":"com.atmel.avrdbg.connection.jungousb","SerialNumber":"00A200047242","UsbVendorId":1003,"UsbProductId":8455}}]
15:58:46.949: Got Tool::attachedToolsChanged([{"ToolType":"com.atmel.avrdbg.tool.simulator","ConnectionType":"","ConnectionProperties":{}},{"ToolType":"com.atmel.avrdbg.tool.avrdragon","ConnectionType":"com.atmel.avrdbg.connection.jungousb","ConnectionProperties":{"Type":"com.atmel.avrdbg.connection.jungousb","SerialNumber":"00A200047242","UsbVendorId":1003,"UsbProductId":8455}}] ) event, notifying listeners

 

 

And, most importantly, the Dragon is now seen in the Tools dropdown. Just did a small download, but it appears to work as needed. Again, be happy to continue to perform any other test you might need.

 

This is good - is this the beginning of the permanent fix perhaps? Was it an old string?

 

Dave

The SiliconHacker  Plano, TX  www.siliconhacker.com

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

Dave :

 

Glad to hear that helped. Before this DLL, we used the same license string we´ve used for the last 4-5 years and 3 major releases of Studio. Strange that it worked for a while and then stopped working...

Please do post here if you hit any more problems.

 

Looking forward, we´ll release a Studio with windrvr12 and updated license string. It may take a couple of weeks or so, and will not be included in the upcoming update.

 

Meanwhile, I will update the patching recipe to also include this DLL drop.

Sorry for all the trouble !

 

Thanks, Dan

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

duplicate...

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

Dan:

 

I confess that I was quite concerned for a while (my new company is releasing several new products based on Atmel micros - this is why this issue was so critical to me), but it appears that Atmel now has its hands around this. I'm hoping for the best.

 

It's been solid for the last hour or so... smiley I will, of course, post if something goes south.

 

Again, thanks for your help and attention. I look forward to the production release containing the fix. 

Dave

The SiliconHacker  Plano, TX  www.siliconhacker.com

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

 

Oh! This seems to work, at least it enumerates the Dragon and I can perform operations on an ATmega16 that is handy.

 

Bravo!

 

Dana

 

 

Dana  K6JQ

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

Dan - is this good for 32 and 64-bit? I have both, unfortunately both my Dragon and Atmel-ICE are in a remote office where the 64-bit machine is.
With this new DLL, Atmel Studio 7 seems to start up okay.

-Thanks

-Andy

 

 

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

Yes, the new dll is good for both 32/64 Windows.

 

Pages