| Author |
Message |
|
|
 Posted: Jan 27, 2006 - 10:01 AM |
|
Joined: Dec 25, 2003
Posts: 94
|
|
I have a very repeatable problem with AVR Studio 4.12b462 and WinAVR 20060125 where AVR Studio freezes during the compilation process whenever eeprom.h is included. Note: this appears to be AVR Studio related since it does NOT hang when compiled with the same makefile from a command lind.
Generate a new GCC proejct in AVR studio for any micro (I tried the attiny45 and atmega8) and try the following source:
Code:
#include <avr/io.h>
#include <avr/eeprom.h>
int main (void)
{
while (1) ;
return 0;
}
The compilation process will hang at this point:
Code:
avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" --change-section-lma .eeprom=0 -0 ihex asdf.elf asdf.eep
If you comment-out the #include <avr/eeprom.h> it will compile just fine. The project appears to be corrupted if you try and re-open it after force-quitting AVR Studio during the hang, but deleting the "default" configuration directory fixes that.
If I compile using the AVR Studio generated makefile in Programmer's Notepad, it compiles just fine. So this seems to be some AVR Studio related error...
I apologize if this is a known bug, I just ran in to this after 5 minutes of trying the new WinAVR and AVR Studio.  |
|
|
| |
|
|
|
|
|
|
Posted: Jan 27, 2006 - 11:08 AM |
|
Joined: Jul 18, 2005
Posts: 62922
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
Yup, I see exactly the same lockup. I found that the solution could be narrowed down to not deleting the ENTIRE default build directory but just the target.o.d in the default\dep directory. Rather curiously, in my case, this consists of:
Code:
eric.o: ../eric.c C:/WinAVR/avr/include/avr/io.h \
C:/WinAVR/avr/include/avr/sfr_defs.h C:/WinAVR/avr/include/inttypes.h \
C:/WinAVR/avr/include/stdint.h C:/WinAVR/avr/include/avr/iom16.h \
C:/WinAVR/avr/include/avr/portpins.h \
C:/WinAVR/avr/include/avr/version.h C:/WinAVR/avr/include/avr/eeprom.h \
C:\WinAVR\bin/../lib/gcc/avr/3.4.5/include/stddef.h
C:/WinAVR/avr/include/avr/io.h:
C:/WinAVR/avr/include/avr/sfr_defs.h:
C:/WinAVR/avr/include/inttypes.h:
C:/WinAVR/avr/include/stdint.h:
C:/WinAVR/avr/include/avr/iom16.h:
C:/WinAVR/avr/include/avr/portpins.h:
C:/WinAVR/avr/include/avr/version.h:
C:/WinAVR/avr/include/avr/eeprom.h:
C:\WinAVR\bin/../lib/gcc/avr/3.4.5/include/stddef.h:
In this all path separators are the Unix style forward-slash APART from those two back slashes on the lines that reference stddef.h - if I edit them to be forward slashes the AVR Studio no longer locks up when the project is loaded.
So there seem to be two faults here - one is the inclusion of the wrong slashes in the first place which is presumably something introduced by the new WinAVR but the other is clearly a fault in Studio - it should be abe to handle both Windows and Unix style directory separators.
Cliff |
_________________
|
| |
|
|
|
|
|
|
Posted: Jan 27, 2006 - 11:27 AM |
|
Joined: Sep 01, 2003
Posts: 158
Location: Norway
|
|
Thanks for reporting this problem!
And thanks for narrowing it down to the handling of dependencies.
This is bug #4260 in our bugtracking system.
regards,
Torleif |
|
|
| |
|
|
|
|
|
|
Posted: Jan 27, 2006 - 08:05 PM |
|
Joined: Dec 25, 2003
Posts: 94
|
|
|
clawson wrote:
So there seem to be two faults here - one is the inclusion of the wrong slashes in the first place which is presumably something introduced by the new WinAVR but the other is clearly a fault in Studio - it should be abe to handle both Windows and Unix style directory separators.
Cliff
Nice work. Looks like it's back to KamAVR again for me.  |
|
|
| |
|
|
|
|
|
|
Posted: Jan 29, 2006 - 11:35 AM |
|
Joined: Sep 01, 2003
Posts: 158
Location: Norway
|
|
Ok, the problem has been fixed.
I had not considered forward slashes as path separators when processing the dependency files and this resulted in an infinite loop.
I am sorry for the trouble this has caused.
regards,
Torleif |
|
|
| |
|
|
|
|
|
|
Posted: Jan 29, 2006 - 01:50 PM |
|
Joined: Dec 25, 2003
Posts: 94
|
|
|
torleifs wrote:
Ok, the problem has been fixed.
I had not considered forward slashes as path separators when processing the dependency files and this resulted in an infinite loop.
I am sorry for the trouble this has caused.
regards,
Torleif
Great! So is there a beta version of AVR Studio lurking somewhere with this fix? |
|
|
| |
|
|
|
|
|
|
Posted: Jan 29, 2006 - 02:29 PM |
|
Joined: Dec 20, 2002
Posts: 7279
Location: Dresden, Germany
|
|
|
torleifs wrote:
I had not considered forward slashes as path
separators when processing the dependency files ...
Just for the record, they have always been valid path name separators
in MS Windows internally (i.e. on the syscall level), and even in
MS-DOS dating back to at least MS-DOS version 3.x (probably even 2.x).
The reason they adopted two path name separators when incorporating
the Unix-style file system hierarchy was mainly their command shell
(COMMAND.COM, now CMD.EXE) inherited the forward slash as an option
separator from its anchestor CP/M, so that character wasn't available
on the command level for that purpose. Well, in theory, there was
even a syscall to change the option delimiter from slash to dash (so
to be fully unix compatible), but I think this feature has never been
seriously implemented in any program.
The "drive" letters are another inheritance from CP/M, btw...
To make the long story short: when programming MS Windows, you should
always be aware that both '/' and '\\' are valid path name separators. |
_________________
Jörg Wunsch
Please don't send me PMs, use email if you want to approach me personally.
Please read the `General information...' article before.
|
| |
|
|
|
|
|
|
Posted: Jan 30, 2006 - 01:07 AM |
|
Joined: Apr 06, 2001
Posts: 86
|
|
|
torleifs wrote:
Ok, the problem has been fixed.
Torleif -
I also noticed that the memory usage report has disappeared with the new WinAVR.
I would post this in the Studio forum, but thought best to stay in this thread.
Regards,
Colin |
|
|
| |
|
|
|
|
|
|
Posted: Jan 30, 2006 - 01:25 AM |
|
Joined: Jan 23, 2004
Posts: 9878
Location: Trondheim, Norway
|
|
Colin, that's because the new WinAvr's memory usage script has been incorperated into one of the binutils. You could either reimplement the new commands youself via a custom AVRStudio makefile (or at least force AVRStudio to run custom Makefile commands) - see the new makefile template. Otherwise i'm sure Torleif can implement that extreamly easily just by changing WinAVR's internal makefile.
- Dean  |
_________________
Atmel Studio 6.1 is now released, grab it here.
Report AS6/ASF bugs here.
|
| |
|
|
|
|
|
|
Posted: Jan 31, 2006 - 05:00 PM |
|
Joined: Apr 12, 2005
Posts: 59
Location: Belgium
|
|
|
jimbotko wrote:
torleifs wrote:
Ok, the problem has been fixed.
I had not considered forward slashes as path separators when processing the dependency files and this resulted in an infinite loop.
I am sorry for the trouble this has caused.
regards,
Torleif
Great! So is there a beta version of AVR Studio lurking somewhere with this fix?
Would greatly benefit from this too, a couple of my projects are freezing. 
For the size report, a quick fix I found waiting for the next (and soon  avrstudio version is to copy avr-mem.sh into winavr/bin. You can get it from your previous winavr installation or better use the latest version which should have a download link somewhere in these forums. |
|
|
| |
|
|
|
|
|
|
Posted: Jan 31, 2006 - 06:48 PM |
|
Joined: Sep 30, 2005
Posts: 63
Location: San Carlos, CA
|
|
I'm running into this bug compiling for the ATtiny45. I'm very happy to hear it's been fixed, but I'm a bit confused as to whether the fix is available for download somewhere. Any further details regarding how to get this fix would be most helpful.
Thanks,
-Mike |
|
|
| |
|
|
|
|
|
|
Posted: Feb 01, 2006 - 12:49 PM |
|
Joined: Sep 01, 2003
Posts: 158
Location: Norway
|
|
The fix is now available from this location:
http://www.atmel.no/beta_ware/
Release notes:
This upgrade fixes the following problems that the plug-in had with the WinAVR 20060125 release.
-Infinite loop when determining dependencies. (After completing a build.)
-No reporting of memory usage.
Regards,
Torleif |
|
|
| |
|
|
|
|
|
|
Posted: Feb 01, 2006 - 03:15 PM |
|
Joined: Apr 12, 2005
Posts: 59
Location: Belgium
|
|
| Thank you very much Torleifs for your kind and fast reaction to this. The update works for me. I'm back on track now ... |
|
|
| |
|
|
|
|
|
|
Posted: Feb 01, 2006 - 05:27 PM |
|
Joined: Sep 30, 2005
Posts: 63
Location: San Carlos, CA
|
|
Very much appreciated. Thank you.
-Mike |
|
|
| |
|
|
|
|
|
|
Posted: Feb 01, 2006 - 11:36 PM |
|
Joined: Apr 06, 2001
Posts: 86
|
|
Torleif -
Thanks for getting the update out so quickly. 
Unfortunately, this bug has re-surfaced:
Quote:
In a GCC project, set include file paths to a path with spaces in the name, eg "c:\program files\...."
Include files are correctly found by the compiler, but where the file names show up in the 'External Dependencies' tree, the path is corrupted. Double clicking the filename does not bring the file up in the editor.
Regards,
Colin |
|
|
| |
|
|
|
|
|
|
Posted: Feb 02, 2006 - 12:09 PM |
|
Joined: Sep 01, 2003
Posts: 158
Location: Norway
|
|
It seems I may have been a bit too fast then.
When you write 'corrupted' do you mean that the spaces are preceded by a '\'?
That is what I observe at least.
Unfortunately, I don't have time to look into it right now, so it might be a while before a fix is distributed.
Torleif |
|
|
| |
|
|
|
|
|
|
Posted: Feb 02, 2006 - 07:45 PM |
|
Joined: Apr 06, 2001
Posts: 86
|
|
|
torleifs wrote:
It seems I may have been a bit too fast then.
No worries. We appreciate the quick response to the WinAVR changes.
torleifs wrote:
When you write 'corrupted' do you mean that the spaces are preceded by a '\'?
That is what I observe at least.
That's exactly it.
Colin
**Edit:**
I just found another small bug for you. 
On saving the project options, 'UL' is appended to the frequency (new feature). Now go back into the options, and change anything. When saving, an additional 'UL' is appended ('ULUL'). And so on.... |
|
|
| |
|
|
|
|
|
|
Posted: Feb 03, 2006 - 04:37 PM |
|
Joined: Apr 12, 2005
Posts: 59
Location: Belgium
|
|
| I reported the UL problem some while ago to Atmel and they were already avare of it. Should be there in the next version or Service Pack I guess. |
|
|
| |
|
|
|
|
|
|
Posted: Feb 26, 2006 - 01:18 AM |
|
Joined: Feb 26, 2006
Posts: 170
Location: Philadelphia, PA
|
|
I am still having a problem with AVRStudio freezing. From what others are saying, the problem seems to be fixed with version 20060125 and Service Pack 4.12 so I assume the problem is with me.
Without adding avrlib include folders, I am able to comile without freezing(with the exprected cannot find file.h error) . It is when I include avrlib folders that it freezes while compiling. I do not see eeprom.h listed in the .o.h file so I am not sure what is causing the problem. Suggestions / Things to try are very welcome |
|
|
| |
|
|
|
|
|
|
Posted: Feb 26, 2006 - 02:18 PM |
|
Joined: Dec 20, 2002
Posts: 7279
Location: Dresden, Germany
|
|
> From what others are saying, the problem seems to be fixed with
> version 20060125 and Service Pack 4.12 so I assume the problem is
> with me.
No, you need the beta version from the Norway beta site. |
_________________
Jörg Wunsch
Please don't send me PMs, use email if you want to approach me personally.
Please read the `General information...' article before.
|
| |
|
|
|
|
|
FAQ
Search
Register
Log in to check your private messages
Log in
Maximize
RSS
