WinAVR 20060125 hangs during compile with include files

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

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:

#include 
#include 

int main (void)
{
	while (1) ;
	return 0;
}

The compilation process will hang at this point:

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 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. :(

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

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:

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

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

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

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

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. :)

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

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

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

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? :)

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

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.

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

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

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

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 :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

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.

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

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

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

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

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

Thank you very much Torleifs for your kind and fast reaction to this. The update works for me. I'm back on track now ...

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

Very much appreciated. Thank you.

-Mike

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

Torleif -

Thanks for getting the update out so quickly. :D

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

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

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

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

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. :o

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....

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

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.

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

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 :wink:

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

> 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.

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

Jörg

Do you have the power to change this thread title as the mention of eeprom.h is too specific? At the very least the title should be "WinAVR 20060125 hangs during compile with eeprom.h/stdio.h included" but I think there are probably other system .h files that lead to it too. The implication of the current title is that it's only something to do with using EEPROM

Cliff

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

> Do you have the power to change this thread title as the mention of
> eeprom.h is too specific?

Done, albeit there's a length limit on thread titles which hit me.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

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

Note you need to install both AVR Studio 4.12 Service Pack 1 and AVR GCC Plug-in upgrade.
While the AVR Studio SP1 is available on the Atmel site, the AVR GCC Plug-in upgrade is only available on the Atmel Norway site: http://www.atmel.no/beta_ware/

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

The AVR GCC Plug-in upgrade has now been removed, and AVR Studio service Pack to has been added to http://www.atmel.no/beta_ware/

The AVR GCC plug-in fix is included in this service pack.
In addition, the part support has been made up to date with the lates WinAVR release.

Torleif

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

Torleifs,

Can you confirm whether the install sequence is therefore:

http://www.atmel.com/dyn/resourc...
http://www.atmel.com/dyn/resourc...
http://www.atmel.no/beta_ware/as...

or just

http://www.atmel.com/dyn/resourc...
http://www.atmel.no/beta_ware/as...

That is - does one install build 460, SP1, SP2 or just build 460, SP2 ?

(and if you have build 460+SP1+avr-gcc_fix installed then is it OK to just install SP2 on top?)

Cliff

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

Good point!

The install sequence is :
http://www.atmel.com/dyn/resourc...
http://www.atmel.no/beta_ware/as...

Service pack 2 contains service pack 1, and service pack 2 can be installed either "on top of" AVR studio 4 build 460, or on top of AVR studio 4 build 460 with sp1 installed.

This will be the case with all service packs for AVR studio.

Torleif

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

Thanks - wonder if a link to this should also be made sticky at the top of the Studio4 forum too because if a user gets a "hang" during Studio+WinAVR use then it's actually Studio that locks up so (exerience seems to show) that they may go looking for the solution in the Studio 4 forum rather than this GCC one.

Cliff

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

torleifs wrote:

The AVR GCC plug-in fix is included in this service pack.
In addition, the part support has been made up to date with the lates WinAVR release.

Torleif

Torleif -
I notice that the two previously reported bugs in the plug-in are still there. That is, the "UL" bug, and the corrupted paths bug (space replaced with "\").

Colin

Topic locked