Known Issues

From AVR-Eclipse

Jump to: navigation, search

Here is a list of all known problems with the Plugin. They are issues that cannot be fixed, usually because they are caused by the underlying Eclipse/CDT system.

Issues that are fixable are found in the plugin bugtracker on SourceForge. This is the place to check first if you think that you have found a bug in the AVR plugin. Also the CDT FAQ has some entries that might be helpful if you have problems.


Contents


After update of the avr-gcc toolchain Include paths still point to the old location (AVR Eclipse Plugin before 2.4)

Example of duplicate paths
Example of duplicate symbols

Eclipse/CDT uses a mechanism called 'Discovery' to get a list of all paths and symbols built into avr-gcc. This is done by internally executing avr-gcc with some special parameters and then parsing the output.

However there is a problem with the discovery feature. Once CDT has discovered a path or symbol, it will never forget it. So if you

  • are using a new avr-gcc toolchain at a different path or
  • have changed the project to a different MCU or
  • if you use different MCUs for individual build configurations

then you will end up with duplicate paths and wrong symbols.


This is a known bug of the CDT plugin. While this does not affect code generation (which will be correct), it does affect the editor, because #ifdef structures may get grayed out incorrectly and the 'Open Declaration' function (F3) can take you to old include files or may not work at all when the old include path does not exist anymore.

To see what paths and symbols were discovered open the project properties, go to the C/C++ General -> Paths and Symbols page and take a look at the Includes and Symbols tabs (the latter one with Show built-in values enabled) Note that the Delete button does not actually delete the symbol. Instead it gets added to the Undefine list in the compiler settings and is passed to the compiler with -U{SymbolName}.

Workaround: While this 'Bug' is basically just an inconvenience, there is currently only one way to remove discovered symbols: to move or delete the file where the symbols are stored. The file is located at
${workspace}/.metadata/.plugins/org.eclipse.cdt.make.core/${projectname}.sc

Quit Eclipse before deleting the file, as Eclipse keeps its content in memory. After restarting Eclipse rebuild your project and all paths and symbols should be fine.

[All configurations] does not work

With Eclipse 3.4 the CDT plugin has the a new [All configurations] setting for the build configuration. The plugin, which is programmed for Eclipse 3.3 is not aware of this new functionality and will treat {All configurations] as a distinct configuration. All changes made with [All configurations] selected are not propagated to other build configurations.

Known issues All configurations 1.png


Furthermore CDT has a known bug (Update: this has been fixed in "head and 5.0 branch" - gods know what versions that mean), which causes an internal Eclipse error when [All configurations] is selected on the C/C++ Build -> Settings -> Tool Settings page.

Known issues All configurations 2.png

Build stops after linking

This is a Bug in Eclipe/CDT, cause by empty resource configurations.

Example

Please check if you have any file in your project with a custom resource configuration. A custom resource configuration is indicated by a '<>' Symbol in the top right corner of the icon - like this one: Known Issues ResCfg Indicator.png

Workaround: Right click on affected file and select Build Configurations > Delete resource cfgs..., Select All and click on OK'.

The build should then be working normally again.


Error: 'This application has requested the Runtime to terminate it in an unusual way.'

For some development system configurations building a project will abort with the following error message:

Invoking: AVR Compiler
avr-gcc -Wall -g2 -gstabs -O0 -fpack-struct -fshort-enums -funsigned-char -funsigned-bitfields
-mmcu=atmega16 -DF_CPU=1000000UL -MMD -MP -MF"somefile.d" -MT"somefile.d" -c -o"somefile.o"
"../somefile.c"

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
make: *** [somefile.o] Error 3

While it is not quite clear what causes this behavior, it might help to add the path to your 'tmp' directory manually to the C/C++ environment.

Known issues tmp env.png


"Operation not permitted" error

In Ubuntu if you receive the error message:

avrdude: usb_open(): cannot read serial number "error sending control message: Operation not permitted"

This means that your permission settings to access the programmer are probably wrong. Setup a new rule in by typing:

sudo gedit /etc/udev/rules.d/41-atmega.rules

and entering the following into the new text file ...

before Ubuntu Lucid (10.04)

# JTAGICE mkII
SUBSYSTEM=="usb_device", SYSFS{idVendor}=="03eb", SYSFS{idProduct}=="2103", GROUP="users", MODE="0666", GROUP="dialout"
# AVRISP mkII
SUBSYSTEM=="usb_device", SYSFS{idVendor}=="03eb", SYSFS{idProduct}=="2104", GROUP="users", MODE="0666"
# Dragon
SUBSYSTEM=="usb_device", SYSFS{idVendor}=="03eb", SYSFS{idProduct}=="2107", GROUP="users", MODE="0666" 

Ubuntu Lucid (10.04) and later

In Ubuntu Lucid (10.04) udev rules file format has changed. File should look like that:

# Please test and place config for other programmers here
# JTAGICE mkII 
ATTR{idVendor}=="03eb", ATTR{idProduct}=="2103", GROUP="users", MODE="0666" 
# AVRISP mkII 
ATTR{idVendor}=="03eb", ATTR{idProduct}=="2104", GROUP="users", MODE="0666" 
# Dragon
ATTR{idVendor}=="03eb", ATTR{idProduct}=="2107", GROUP="users", MODE="0666"
# USBTiny
ATTR{idVendor}=="1781", ATTR{idProduct}=="0c9f", GROUP="users", MODE="0666" 


... either changing "users" to your own users group or adding yourself to the "users" group:

sudo usermod -a -G users your_username

Thereafter reload udev

sudo reload udev

and reconnect your programmer.

This should get rid of the "operation not permitted" error.

Ubuntu Debug setup

For some reason the default Ubuntu installation of avr-gdb is still at version 6.4. This results in a number of problems when attempting to connect the debugger.


To resolve this download the latest version of gdb [1]


Extract it and then compile for the avr:

tar -xzf gdb-version.tar.gz cd gdb-version

./configure --prefix=/usr/local/avr --program-prefix="avr-" --target=avr

make

sudo make install

exit

Your working copy of avr-gdb will be located in /usr/local/avr/bin/avrgdb

Personal tools