Eclipse using the wrong MCU

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

I'm using an Atmega328p and coding from Eclipse with the AVR plugin.

I tried to edit the TIMSK1 register, only for Eclipse to throw an error saying "Symbol 'TIMSK1' could not be resolved". I could access the other registers just fine.

Pressing F3 on the registers that work, I noticed that io.h was importing iom16.h instead of iom328p.h.

 

I tried adding the code:

#define __AVR_ATmega328P__

before including io.h.

 

io.h now highlights the correct MCU:

but when I press F3 on the registers from earlier they still lead to iom16.h. TIMSK1 still can't be detected.

 

I then tried to build the project through Eclipse. The compiler has the argument:

-mmcu=atmega16

 

I guess it must have to do with the project's settings, even though I made sure to set the correct MCU when creating the project. 

I've read this thread and this bug report, but I can't find the .sc file. My workspace metadata folder only has a version.ini file. Could it be somewhere else?

Any ideas how to fix this? Thanks

 

 

 

This topic has a solution.
Last Edited: Wed. Jan 10, 2018 - 01:03 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gxavier38 wrote:
Eclipse to throw an error saying "Symbol 'TIMSK1' could not be resolved".

Note that Eclipse's symbol browsing in the editor is entirely separate from the compiler.

 

Is that just an Eclipse error, or is that (also) a compiler error?

 

However, passing the wrong MCU type to the compiler is not going to end well ...

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

I'm not sure. I assumed the compiler would get its arguments from Eclipse and so that the problem was with the project's settings.

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

I assume I just need to change the MCU somewhere in the project settings. 

The AVR plugin has screenshots showing how to do this.

And yet for some reason the entire AVR menu doesn't show on my project settings.

Strange..

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gxavier38 wrote:
I'm not sure. I assumed the compiler would get its arguments from Eclipse and so that the problem was with the project's settings.

Yes - for the -mmcu setting.

 

But, in general, it is still possible for Eclipse's symbol browsing in the editor to be out-of-step with what the compiler sees - so you can have the Eclipse editor saying stuff is undefined, yet it builds perfectly!

 

But here it does sounds like you have some fundamental problem(s) with the project set-up.

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

The atmega16 is the default mcu when you create an Eclipse project.  You need to enter your MCU in the project's properties, then the compiler will pick up the correct MC's symbols. 

 

Check the post in http://www.avrfreaks.net/comment/2264901#comment-2264901  It will show you how to assign your MCU and then have that assignment saved.  If the problem re-occurs when you re-start Eclipse on another day, just run the compiler and the symbols will re-appear for the rest of the Eclipse session.

 

Alan

Last Edited: Wed. Jan 10, 2018 - 02:57 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I did enter the MCU when creating the project. For some reason it reverted back to the 16.

 

Either way, I managed to fix the problem.

I ended up recreating the project a few times. The third time it set the MCU to the 328p, so everything works fine now.

No idea why they didn't work the first few times.

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

Found my post  http://www.avrfreaks.net/comment/2264901#comment-2264901  that solved this problem.  The fix is a two step process: change the MCU, then delete the project's *.sc file.   I would encourage you to try this fix since it will allow you to use the more general include <avr/io.h> in every other project.

 

Alan

 

Edit: added reference to this post and changed last sentence.

Last Edited: Wed. Jan 10, 2018 - 03:07 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gxavier38 wrote:

I noticed that io.h was importing iom16.h instead of iom328p.h.

 

I tried adding the code:

#define __AVR_ATmega328P__

 

Don't do this.  The correct way to specify a device is to specify -mmcu=atmega328p on the command line.  Defining reserved macros won't for incorrect command-line options (you still get wron startup code, wrong multilib libraries, wrong instructions, etc.)

avrfreaks does not support Opera. Profile inactive.

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

Now you got me curious.  I re-read your first post and noticed that you had already found the tread with my 'solution' post (did not notice that 'this' and 'bug' were blue).

 

What version of Eclipse are you using?

What is your avr-eclipse plugin version?

What is the version of your CDT?

What is your operating system?

Is there a {$workspace}\metadata\plugins\org.eclipse.cdt.make.core folder under your 'workspace' (or whatever you have named it) folder?

Have you searched for a *.sc file in your workspace or Eclipse installation (i.e eclipse\plugins\org.eclipse.cdt.make.core)?

 

Alan

 

The reason for these questions is that I believe the *.sc file is created by the avr-eclipse plugin and then used by the editor and CDTs make utility.  The avr-eclipse plug-in has not changed since 2011 so the *.sc file should still be created and located somewhere.

Last Edited: Thu. Jan 11, 2018 - 01:33 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I moved downstairs to my avr development computer and looked at the folder structure. 

You said that "workspace metadata folder only has a version.ini file. Could it be somewhere else?"

 

Yes, I looked under 'metadata' and see a "version.ini" file so I believe I'm looking at what you saw:

However, you should be looking at the subfolder: metadata\plugins\org.eclipse.cdt.make.core under that folder.  Open the link in post 8 and you will see the project's sc files are in that folder and instructions about how to delete and recreate the file.

 

Good luck,

Alan

 

Last Edited: Thu. Jan 11, 2018 - 03:26 PM