Eclipse unresolved symbols

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

Hello all,

Not sure if this is the section of the forum to post to with my question, so if it is in the wrong place, please excuse me.

My set up is Eclipse 3.7 Indigo with the AVR Eclipse Plugin 2.3.4 and WinAVR20100110 on a Windows 7 PC.

The issue I am having is sometimes (and I really mean only sometimes) Eclipse will show a little bug off to the side of some code I have written. When hovering the mouse over the bug I get the a pop up telling me that I have an unresolved symbol. The symbols that it cannot resolve are the AVR bit and register defines.

Here is what is not making sense, I will start a new project, configure for a mega48, and in my main.c file I will include avr/io.h, which includes iom48.h and iomx8.h which has the register defines. When I set a bit in a register (doesn't matter which bit or which register) I get the little bug on the side, which shows the symbols unresolved. I made sure all my tool chain settings were correct (Eclipse can find the include files no problem). I checked the Codan (Eclipse Code Analysis tool) settings, but didn't find anything that would explain the issue. So I built the code and it compiled and linked just fine. Downloaded to my AVR, and the program ran as expected. So I started another project the exact same way, and this time I did NOT get the little bug on the side - all symbols were resolved. Downloaded the code, and again everything ran fine.

So for some reason I am getting a false positive, and don't even know what part of Eclipse is causing it. I checked the Eclipse and CDT forums, but did not find anything remotely close to this issue. I did some searching on this forum, but haven't seen this issue posted yet. I did see the post about making sure in the .project file I need to have the AVR Eclipse plugin showing in the tags - but it is already there.

Well like I said this only happens every once in a while, but I would like to resolve it because I don't want to miss a real unresolved symbol. Ignoring the issue doesn't mean everything is working correctly.

Sorry it is long winded, but I want anyone looking at this to understand the issue. Has anyone run into this before? I don't remember if I had seen this in Eclipse 3.6 (Helios), so I am not sure if this just started with Indigo.

Thanks for any help,
Tony

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

Yes eclise does this to me too. Its trying to be smart; it doesnt seem to be able to look within an include in anouther include. To fix it; simply

#include
#include

Then it will work. its repetative; but thats the issue; it cannot look into io.h and then into the include io adds.

understand?

for example; when I work with a mega32; my includes must include both IO.h and the mega32 io file .h

like:
#include
#include

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

Yes, I got it. This was driving me nuts because I knew I had the correct include files. I just tried it with my mega48:

#include

That worked! Thanks for your help. It seems that in trying to be smart, Eclipse is acting kind of dumb. Oh well, back to programming.

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

ph0rkeh wrote:
it doesnt seem to be able to look within an include in anouther include.
Of course it is able to do that. Eclipse simply don't know in which one it should look. The inclusion of (e.g.) avr/iom32.h is done if __AVR_ATmega32__ is defined. But that is not defined somewhere in the code (so Eclipse can immediately see that), but by the compiler during compilation depending on the -mmcu switch.

Stefan Ernst

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

I also have the issue. But I don't pay attention to this one as I know what's the problem actually.

If you define an exact header (iom32.h, for example) you lost the advantages of Makefile which do it by itself. If you want to port the project to other chip you must just change MCU-string in Makefile. If you define the header manually you should redefine it every time when you are compiling the project for another mcu.

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

BTW folks you can find all the compiler pre-made defines using -E -dM. Get those then pre-define them in the project:

For example:

E:\avr>avr-gcc -E -dM -mmcu=atmega16 -I. -gdwarf-2 -DF_CPU=1000000UL -O0 -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes --save-temps -fverbose-asm -Wa,-adhlns=./test.lst  -std=gnu99 -MMD -MP -MF .
dep/test.o.d test.c
#define PRIXFAST32 "lX"
#define INT0 6
#define INT1 7
#define INT2 5
#define __DBL_MIN_EXP__ (-125)
#define OCF1A 4
#define OCF1B 3
#define __FLT_MIN__ 1.17549435e-38F
#define __DEC64_DEN__ 0.000000000000001E-383DD
#define WGM20 6
#define INT_LEAST16_MIN INT16_MIN
#define EE_RDY_vect _VECTOR(15)
#define FUSE_BOOTRST (unsigned char)~_BV(0)
#define PRIuPTR PRIu16
#define USART_RXC_vect _VECTOR(11)
#define __CHAR_BIT__ 8
#define EEAR _SFR_IO16(0x1E)
#define EECR _SFR_IO8(0x1C)
#define INT16_C(value) value
#define LB_MODE_1 (0xFF)
#define LB_MODE_3 (0xFC)
#define EEDR _SFR_IO8(0x1D)
#define INT8_MAX 0x7f
#define UINT_LEAST64_MAX UINT64_MAX
#define TIMER0_OVF_vect _VECTOR(9)
#define __GNUC_PATCHLEVEL__ 3
#define SIG_UART_DATA _VECTOR(12)
#define EERE 0
#define __AVR_MEGA__ 1

All I've done there is take the usual compilation command line and replace "-c" with "-E -dM"

BTW I just piped that output into "wc -l" and it tells me there are 832 pre-made defines. You would need to cherry pick the ones that are important for the IDE to parse the headers correctly!

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

clawson wrote:
BTW folks you can find all the compiler pre-made defines using -E -dM. Get those then pre-define them in the project:
Actually Eclipse already does that (or something similar) and caches the found pre-defines. That's why ...
Quote:
So I started another project the exact same way, and this time I did NOT get the little bug on the side - all symbols were resolved.

But it is easy to confuse this mechanism. E.g. if you change the mcu setting, then you have the pre-defines of both in the cache. And because the ioXXX.h inclusion in io.h is a long list of #elif, only one of it actually has an effect during the code analysis made by Eclipse (and of course not necessarily the one matching the current mcu setting). AFAIK (I merely tried Eclipse out a few years ago) there is an option to empty this cache which should help in such situations.

PS: Sorry for not telling the whole story in my first post and causing a waste of your time this way.

Stefan Ernst

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

Hi,

please try the new 2.4.0 version of the plugin on sourceforge. It is still marked as Beta but after 10 days and a few hundred downloads I haven't had any complaints so far.
https://sourceforge.net/projects/avr-eclipse/files/avr-eclipse%20beta%20versions/

It should fix the issue with the indefinitely cached Paths and Symbols. Just changing the MCU for a project once should cause reloading of all paths and symbols, as well as rebuilding the index.

Cheers,
Thomas

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

Thanks everyone for the information.

Thomas -
I'll give the new plugin version a try.

EDIT:
Thomas, is version 2.4.0 going to support the MHV AVR Tools?

For those that don't know the MHV AVR Tools is a WinAVR replacement toolchain from Make Hack Void makehackvoid.com

It is using avr-gcc 4.6.2, AVR-LibC 1.7.2rc2252, and AVRdude 5.11.1. I have been testing it in a separate Eclipse environment. It works, though so far the code I have compiled is slightly larger, maybe 0.5%. I have no hard numbers, just comparing MHV to WinAVR.

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

Excuse me! What actually advantages does the plugin provide? Should I use it if now I work well without this one? I just create new AVR project in the same way as PC project and so on. I had set up winavr compiler before in Eclipse.

Thank you!

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

I thought Thomas would have answered this as I believe he is the creator of the AVR Eclipse Plugin. As for what it does, I am not sure since I have not used Eclipse without it. I know it allows me to start an AVR-GCC project, Eclipse knows all about the AVR-GCC toolchain, all my paths are taken care of, and I can use the project wizard to set up my project. Plus you get a menu icon that you click and it invokes AVRdude to download your code into the AVR.

I think it also uses automake, as I have not had to create a make file. I don't know if this is any different from what you do. It has helped me, since my background was Visual Studio, and other programming environments that hide the little details from the user. I am slowly learning about GCC though, and get better with all the help from all the wise people on this forum.

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

OK! Well! Thank you so much for your extensive reply!
As I believe this plugin can do much work for me. This is good! I'll take it into account.

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

sternst wrote:
ph0rkeh wrote:
it doesnt seem to be able to look within an include in anouther include.
Of course it is able to do that. Eclipse simply don't know in which one it should look. The inclusion of (e.g.) avr/iom32.h is done if __AVR_ATmega32__ is defined. But that is not defined somewhere in the code (so Eclipse can immediately see that), but by the compiler during compilation depending on the -mmcu switch.

Of course this was the first thing I tried; didnt seem to work for me. I had to include the actual file name. So I dont know what the deal is then, if it works for you.

Also I would imagin eclise should be smart enough; as it grays out defined areas that will not be used. So it already knows what line in the io.h file will be loaded why shouldn't it already assume to look into that file, i dont know.

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

I use Eclipse Indigo. The projects created in Eclipse Helios are OK, but projects created in Eclipse Indigo can not find the right symbols.
If I go for the include files are correctly highlighted.
GCC project compiles OK.
AVR plugin v2.4.0 did not help. :(

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

@Pajdo,
sorry but I can't reproduce this.

I just downloaded a fresh Eclipse Indigo for C/C++ Developers,
installed the AVR Plugin 2.4.0,
created a new AVR Project,
created a new C Source File,
added "#include ",
saved the file and build project once (causing CDT to recognize and parse the include file avr/io.h)

and everything was OK: all Symbols were found, code completion worked, macro expansion view worked etc.

@tony
Sorry, no MHV Toolchain support in 2.4.0. But it is already included in the next version :-)

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

So I reinstall Eclipse Indigo. No change in errors.

But ... but when I create a new project with the same settings and same source code, everything was OK.

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

With your old projects, please try to change the MCU in the project properties and click on OK. This should cause a rebuild of index.
You can then reselect your original MCU.

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

Yes, this "trick" is better than creating a new project ...

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

Hi
do you guys still have the problems ?
cause, I reinstalled eclipse and avr plugin... and now eclipse cant recognize things like DDRA and all other HW related includes
even uint16_t and so on from inttypes.h is missing :S

What did I do wrong ?

uC's: Atmega16, 32, 64, 128 and Attiny13
Lang.: C
Interests: Small scale robots AND sensor monitoring system

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

B4Me wrote:
Hi
do you guys still have the problems ?
cause, I reinstalled eclipse and avr plugin... and now eclipse cant recognize things like DDRA and all other HW related includes
even uint16_t and so on from inttypes.h is missing :S

What did I do wrong ?

Try this:

after setting the correct MCU on project properties, hit OK.
Then, right-click on project name, go to "Index" entry, and hit "Rebuild".
All unresolved errors should have disappeared.