Atmel Studio has bad package handling.
If, after updating your Device Packs, you start getting problems using the Device Programming window:
23:38:28: [ERROR] Unhandled exception while parsing part description file C:/Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATmega_DFP\1.0.90\atdf\ATmega328P.atdf
23:38:36: [ERROR] Unhandled exception while parsing part description file C:/Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATmega_DFP\1.0.90\atdf\ATmega325.atdf
23:38:38: [ERROR] Unhandled exception while parsing part description file C:/Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATmega_DFP\1.0.90\atdf\ATmega645A.atdf
23:38:40: [ERROR] Unhandled exception while parsing part description file C:/Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATmega_DFP\1.0.90\atdf\ATmega1284.atdf
The problem is that for some reason, the %LOCALAPPDATA%\Local\Atmel\AtmelStudio\7.0\atPacks.db file doesn’t get updated to reflect the paths to the new packages.
I suspect that this might be because for some reason running the Device Pack Manager requires Administrator privileges, but the atPacks.db file is generated on a per-user basis. So probably the code is getting confused as to which %LOCALAPPDATA% folder it needs to write to.
In any case, the atPacks.db file isn’t updated, which you can see if you open up the file (which is a standard SQLite database) in an SQLite browser:
Here’s the fix:
- Open Windows Explorer
- Enter
%LOCALAPPDATA%\Atmel\AtmelStudio\7.0in the location bar - Delete atPacks.db.
Atmel Studio will regenerate the atPacks.db file when it starts again. (Which makes you wonder why they don’t just do the detection at start all of the time, which takes negligible time if you have an SSD. You do have an SSD, don’t you?)