Whole Tomato Software Forums
Whole Tomato Software Forums
Main Site | Profile | Register | Active Topics | Members | Search | FAQ
 All Forums
 Visual Assist
 Technical Support
 VAssistX completely broken in Microchip Studio 7

You must be registered to post a reply.
Click here to register.

Format: BoldItalicizeUnderlineStrikethrough Align leftCenterAlign right Insert horizontal ruleUpload and insert imageInsert hyperlinkInsert email addressInsert codeInsert quoted textInsert listInsert Emoji

Forum code is on.
Html is off.

Check to subscribe to this topic.

T O P I C    R E V I E W
ArKay99 Posted - Jul 18 2021 : 11:10:25 AM
Hi, I've been using Visual Assist since it first came out. Starting with Visual C++... It's the best tool for me for what I do. I've been doing some design work with Atmel MCU's for quite a while and had VA in Atmel's Studio up until 6.2. It always worked well there. I took some time off and an old colleague asked me to help with a project. I installed Microchip Studio 7 on my Windows 10 machine and was pleased to see it included VAssistX. I imported the old project and have been wrestling with VA since. There are other problems relating to ASF that seem to be linked with VA, but I'm not sure since it's so broken. I've tried including the directories of interest and failing that have included ALL the directories. I've rebuilt the VA db, cleared the cache...nothing. The main problem is that VA isn't parsing the include files. I get error underlines in all the third party library references (I've included the directories)...I also get error underlines from references to the standard libraries, ex: stdint.h. Sometimes if I open the project directly from the project or the solution Microchip Studio will start and it looks like VA has parsed the files correctly, they have the proper reference colors. But then if I click in the window the error underlines appear and hovering or right clicking shows Unrecognized symbol...but only for certain items. If I scroll down the page, items that were previously not underlined will become underlined, almost as if there is some local scope being corrupted (the red error indicators in the scrollbars travel with the scroll). I've repaired Microchip Studio, I've removed then reinstalled VAssistX. The solution compiles, builds, and debugs, ok, it's just that there seems to be some linkage that is not happening with VA and MS... If I can't get this to work, I'll be forced to go back to my 'old' Win 7 machine with Atmel Studio 6.2. Any help would be greatly appreciated.
9   L A T E S T    R E P L I E S    (Newest First)
feline Posted - Jul 21 2021 : 08:56:22 AM
Thank you for the detailed update, and I am very pleased to know that everything is working correctly now.

I understand your concern, I tend to make a complete backup of solutions, either as a zip, or just a full folder copy, before opening them in a new IDE. Source control also works well But yes, you never really know quite what will happen, or if it will stop you going back if required.
ArKay99 Posted - Jul 20 2021 : 11:20:29 AM
Hi feline. It's all sorted now. In my quest to get things working I put an absolute path to the avr\include directory in my toolchain compiler directories. That must have been masking the default avr\include path. After I removed that I had to Clear the VA History, cache and temporary files, Rebuild the symbol databases and restart the IDE.

I think the whole 'self-inflicted' chaos was the result of the way the project was built. The machine I'm running on is a dual boot Win 7/Win 10 machine. I started the project with an Atmel 6.2 install on the Win 7 C: system drive and had the solution on the Win 7 D: (as a data) drive. Then I converted the machine to a dual boot with a Win 10 C: drive and a separate Win 10 data drive (which is actually the F: drive. Then when I resurrected the project I copied the folder structure from the E: drive (in Win 10... in Win 7 it was the D: drive) to the F: drive (Win 10 data drive), by creating folders and renaming them, then copying the files from folder to folder. Then I installed MicroChip Studio 7 on my Win 10 boot on it's system drive C: Then I created a new empty solution and added the files to the solution using the add. I wanted to keep the original Win 7 solution "untouched" in case this whole experiment and upgrade went south, as it almost did. In retrospect I could have probably just copied the whole thing from it's root on E: to a new root on F: and opened the solution in MS7 and tweaked it there. I was a bit concerned that LUFA wouldn't transition well and that MS V7 would have it's own set of quirks. Lesson learned.
feline Posted - Jul 20 2021 : 07:40:39 AM
Thank you for the update, and yes, this is strange. I am not sure why VA is having a problem with your solution, but it does seem to be a solution specific problem. Are you aware of anything obviously "odd" or "different" about how this solution works, that might give us a clue as to where the problem came from?
ArKay99 Posted - Jul 19 2021 : 6:52:53 PM
Hi feline, thanks for the info. Here is what I did. I went to the Directories property page as you directed and copied the Platform: Project defined System include files to the Platform: Custom System include files and things started working again. I was then able to trace where the remaining errors were coming from and included the files required for that group into the Custom Source Files page. It's puzzling to me that VA isn't able to utilize the file group in Platform: Project defined - System include files. There must be some quirk in my project that is preventing VA from using the paths from there, but it's working again this way.

Thank you for the help and info and for getting me back on track.
feline Posted - Jul 19 2021 : 1:56:29 PM
For a first answer, it turns out that the:

#include <avr/io.h>

line is a special case, and VA deliberately skips over this file. Currently VA parses inside of #if blocks, since we want to help you with all of the code you are writing, but doing this inside this file would result in us parsing all of the include files for all parts, so far to many symbols.

For your main solution, do you know the main directories you want VA to search inside for your header files? If so, you might want to go to:

VA Options -> C/C++ Directories -> Platform

and set the Platform to "Custom" rather than "Project defined". This would let you tell VA which directories to search for your system include files, since obviously VA is having some problems working out the correct directories in this situation.
ArKay99 Posted - Jul 19 2021 : 11:44:20 AM
I think I have found the problem although I don't know the solution... When I put the caret on, in this case, the io.h segment of the #include statement and go to Edit->Intellisense->List Members It shows a list box of .h files. A second or two after that it shows an info popup with a Whole Tomato icon and the path to the file. IT is NOT the path that is in my project toolchain to the intended directory, in this case: C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\avr\include, but is instead C:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATmega_DFP\1.6.364\include\avr\io90pwm1.h. I suppose it's trying to reference any "io" file it finds, or the first one since there is no "io.h" file in that directoy.
ArKay99 Posted - Jul 19 2021 : 10:02:38 AM
One other oddity I've just seen is in the simple project, under the Edit menu I see the Intellisense menu item. There is no Intellisense menu item in the 'real' project...
Well, after a about 20 seconds the Intellisense option appears...sorry about that.
ArKay99 Posted - Jul 19 2021 : 09:47:35 AM
Hi feline and thanks for responding so quickly. I created a GCC Executable C project, no board just a device, in this case an ATmega16U4. It only has one file, main.c, and one function, main. It has one include: #include <avr/io.h>. When I look in VA View it shows includes h io.h (unresolved). If I place the caret into the filename I get nothing. If I place the caret on main I get the little info window showing info about main. This is what I was seeing in the 'real' project. I did see files in the real project that were resolved as external. Those were 3rd party files from a library, LUFA, and I had included directory references to those in the VAssistX->Options->C/C++ Directories page. If I check the Default Include Paths in both projects Toolchains by following the path in File Manager they are correct. It seems like the problem isn't with VA but with Microchip Studio. Possibly I should do a complete uninstall and reinstall?
feline Posted - Jul 19 2021 : 04:35:20 AM
Can you please try creating a new, default project, and tell me which type you created? I can then create the same type here, and compare results, or even just email you the test project I create here.

Since your solution compiles VA should be understanding it correctly, so I am trying to find out if somehow this is a solution specific problem, or if you are seeing problems like this in all solutions.

Are you using C++ or C for your code?

If you place the keyboard caret into the filenames for your #include lines, what, if anything, does VA show in its context and navigation fields? These are normally shown at the top of the editor window, and are where the Alt-M list appears.

VA should show you the filename in the Context (left side) field and the full path of the header file in the Definition (right side) field. If this is failing then the other errors you are seeing mostly make sense. But since the solution compiles, VA should not be having any problems finding these header files.

© 2021 Whole Tomato Software, LLC Go To Top Of Page
Snitz Forums 2000