## WinAVR Release Candidate

67 posts / 0 new
Author
Message

Hello All,

There is a WinAVR release candidate available, 20070525rc2:
http://sourceforge.net/project/s...

Yes, that is "RC2". The first release candidate was used for internal testing. This is the second release candidate, but the first one offered to the public.

Please give it a try, bang on it, see if it breaks for you. Please report back anything bad, or good. If all goes well, the release will go out, obviously, on 20070525. :)

Thanks
Eric Weddington

Here are the release notes:

================================

It is recommended that you uninstall previous versions of WinAVR, before installing a new version of WinAVR.

Below is just a sample of what's new.

- Installer Changes

The installer has been changed and simplified. It no longer does automatic uninstallation of the previous version. However, all the registry keys and installation path is tied to the WinAVR version number, which should allow future multiple toolchain installations to coexist.

- GCC 4.1.2

New version. There have been many bugs fixed, thanks to Anatoly Sokolov.

- avr-libc 1.4.6

New version. Bugs fixed, user manual expanded.

- GDB/Insight 6.5

GDB is now a native Win32 executable! No longer linked to Cygwin!

- Added support for these devices:

* AT90USB82
* AT90USB162
* ATmega325P
* ATmega3250P
* ATmega329P
* ATmega3290P
* AT90PWM1
* ATmega16HVA
* ATmega8HVA

- LibUSB-Win32

LibUSB-Win32 drivers are included for the Atmel JTAG ICE mkII and the AVRISP mkII. However, these drivers will not work with the Jungo drivers that are installed by AVR Studio; they are mutually exclusive. If you want to have avrdude or avarice connect to these devices, then install these drivers.

- SRecord 1.31

New version.

- SimulAVR 0.1.2.2

New version.

New version.

- Updates to the WinAVR Makefile Template and MFile.

Last Edited: Fri. May 25, 2007 - 08:29 PM

- Dean :twisted:

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

Is it AVRstudio compatible?

There are pointy haired bald people.
Time flies when you have a bad prescaler selected.

If you mean "does the WinAVR release candidate work with AVR Studio", then yes, it should. Check it out for yourself. Yes, you need to use AVR Studio 4.13.

No need for Insight anymore with that WinAvr release. I'm able to do everything from within Eclipse, even debugging. It's great !!

srodrigue wrote:
No need for Insight anymore with that WinAvr release. I'm able to do everything from within Eclipse, even debugging. It's great !!

If this is with the new release candidate, then that's great news!

Seems to work fine on Vista 32-bits. It will probably still have problems on 64-bits but I can't check that.

Seems to work fine on Vista 32-bits.

That's great news! That was one of the main focuses of this release, and thanks for all your help! :)

It will probably still have problems on 64-bits but I can't check that.

True. At this time, 64-bit Vista is technically "unsupported". If it works, it is accidental. :oops:

Eric

Works fine with XP SP2, Studio 4.13 528
coding for an atmega32, debugging on a Dragon

Only new thing is a warning about delay routines not working correctly because optimization is turned off.

Investigating now...

Darren

----------------------------------------------------
Those whom the gods wish to destroy
they must first teach to use c
----------------------------------------------------

> Only new thing is a warning about delay routines not
> working correctly because optimization is turned off.

Intentional change in the library. Too many people have
stumbled across that, so I decided it's worth a warning.

If you don't want the "convenience" functions (_delay_us,
_delay_ms) but only the basic delay functions _delay_loop_1
and _delay_loop_2 (which are independant of the optimization
level), you can use instead of ,
and won't get the warnings then (neither the one about F_CPU).

Jörg Wunsch

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

Thanks Jörg,

By the way if you're ever in Melbourne i'll fulfil my licencing requirements for your sample code!

It helped an assembly/VB programmer make the switch!

Darren

----------------------------------------------------
Those whom the gods wish to destroy
they must first teach to use c
----------------------------------------------------

HI,

Thanks for the new release.

Regarding the delay and F_CPU warning. What if I add to the makefile:

F_CPU = 8000000

Is it going to solve this?

Thanks

Signature: We need more peripherals in DIP packages. Namely, USB, 12-bit ADC, 16-bit timer, cheaper tool as a programmer/debugger coz STK600 is expensive! Atmel Studio 5/6 sucks! coz it brings MS visual studio crap to AVR world..

You also need to set the optimization level to something other than zero (0).

Working great for me - no problems at all. Looks great!

- Dean :twisted:

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

I understand, thanks alot :)

Signature: We need more peripherals in DIP packages. Namely, USB, 12-bit ADC, 16-bit timer, cheaper tool as a programmer/debugger coz STK600 is expensive! Atmel Studio 5/6 sucks! coz it brings MS visual studio crap to AVR world..

Hello,

I tested the new release today and it works great so far (WinXP SP2, PN2 and AVRStudio 4.13, MEGA32).
All my old sources compile without any changes.
(but all of them got a few bytes larger again :twisted: )

I could not test this as I don't have the Win98 box up and running now, but did you also fix the "avr-gcc: _spawnv: No such file or directory"
Bug for older Win98SE systems?

Thanks,
SlyD

Well, if it's the same bug as for Vista (it also spits out a spawnv error), then hopefully it's fixed. I don't have a Win98 box to test this on, so if somebody has access to one and is willing to do it, I would be very grateful!

Eric

It might be worth adding this patch to the MSYS runtime DLL. I've done this and this at least solves the sync_with_child/fork/resource unavailable errors on Vista 64-bits (tested by other people). Only thing is that rm and mkdir will still crash, but maybe these should be recompiled after applying the patch as well. I only tried replacing msys-1.0.dll with a new version but this may cause some version conflict. I'm not really familiar with the build environment and couldn't get rm and mkdir to recompile. And I don't have a 64-bit Vista myself to test it. But I am pretty sure this patch solves a large part of the problem.

On Vista 32-bits the patch has no (negative) influence.

I try to be careful about what I do in terms of patching versus letting the upstream project handle it. WinAVR consists of a lot of projects, and it is time consuming already to keep track of the status, bring in patches as needed and getting everything built. I try to focus on patching the *AVR* tools as needed. I really don't want to get into patching MSYS and rebuilding MSYS. This is where I would recommend that this issue be taken up with the MinGW/MSYS folks. I know that they could always use more help too.

I also want to express that I'm certainly open to listening to all suggestions. I just have to be careful to keep my focus on the right things.

Eric

You've got a good point. Unfortunately it usually takes a long time before it gets officially fixed. I just thought of a possible error in that msys bugfix and already sent a new test DLL to someone for testing. If I get anything to work I'll put an unofficial fix for WinAVR on my website again just like with the current Vista patch.

In any case it is good news that the Vista 32-bit bug has been fixed properly now.

The rc does not work properly on XP SP2 and AVR Studio 4.13 528. I encounted cygwin heap error or "fatal error: opening dependency error"
Then I reinnstalled the version 20070122 and the patch from http://www.madwizard.org/extern/...
and now it works.

Maybe 69Mike should have tried this before merging to CodeVisionAVR, but I don't blame him, I was just about to cut my losses when I decided to try our the wizards patch.

You've got a good point. Unfortunately it usually takes a long time before it gets officially fixed. I just thought of a possible error in that msys bugfix and already sent a new test DLL to someone for testing. If I get anything to work I'll put an unofficial fix for WinAVR on my website again just like with the current Vista patch.

In any case it is good news that the Vista 32-bit bug has been fixed properly now.

Yes, thanks for all your help in that!

If I may suggest, if your fix for the DLL works, then perhaps could you work with the MinGW/MSYS project in getting the patch accepted and committed in their project? I know it will help WinAVR, but it could also help other projects as well.

It might be worth adding this patch to the MSYS runtime DLL. I've done this and this at least solves the sync_with_child/fork/resource unavailable errors on Vista 64-bits (tested by other people). Only thing is that rm and mkdir will still crash, but maybe these should be recompiled after applying the patch as well. I only tried replacing msys-1.0.dll with a new version but this may cause some version conflict. I'm not really familiar with the build environment and couldn't get rm and mkdir to recompile. And I don't have a 64-bit Vista myself to test it. But I am pretty sure this patch solves a large part of the problem.

On Vista 32-bits the patch has no (negative) influence.

I've been considering something for a while.

A lot of the Unix utils in \utils\bin have come from MinGW/MSYS. Running cygcheck (yes, util from Cygwin) on them shows that a lot of them link to the msys-1.0.dll. I've never been overly fond of DLLs, mainly due to versioning issues. And disk space is no longer the premium it used to be.

There is a project called GNUWin32:
http://gnuwin32.sourceforge.net/
which are a whole bunch of Linux/Unix programs and utilities built for Windows. I've thought of replacing all the utils that WinAVR ships with to these utilities.

The downside is that they still link to DLLs, but different ones. However, they are very good about packaging everything needed.

The other downside is that they don't have bash ported yet:
http://sourceforge.net/tracker/i...
(Yes, that is a feature request that I submitted over 2 years ago.) Bash is pretty much a requirement with running 'make'.

If bash could be ported, it would be interesting to see how well these utilities work on Vista 32-bit and 64-bit. I assume bash *can* be ported as the MinGW project has a version of their own. I just don't know what kind of patching it would need.

Eric

Good news on the Vista 64 front, I have a working msys DLL that shows no problems on Vista 64-bits! I just got an e-mail confirming that without this DLL WinAVR RC2 does not work on Vista 64 (same error as before), but after changing the DLL it was fixed and behavior was the same as on Vista 32.

It is still the same patch as described on Nabble but I made two modifications. Unfortunately I do not know yet whether both modifications are necessary but that can be easily tested with some more test versions.

EW wrote:
If I may suggest, if your fix for the DLL works, then perhaps could you work with the MinGW/MSYS project in getting the patch accepted and committed in their project? I know it will help WinAVR, but it could also help other projects as well.

I'll try that as soon as I have figured out the exact patch. Btw, is there are reason that WinAVR uses MSYS 1.0.8 instead of the current stable version 1.0.10?

EW wrote:
If bash could be ported, it would be interesting to see how well these utilities work on Vista 32-bit and 64-bit. I assume bash *can* be ported as the MinGW project has a version of their own. I just don't know what kind of patching it would need.

That may be an option too. However I think that if this bugfix shows no problems on other systems it's easier to just use the MSYS version.

Good news on the Vista 64 front, I have a working msys DLL that shows no problems on Vista 64-bits! I just got an e-mail confirming that without this DLL WinAVR RC2 does not work on Vista 64 (same error as before), but after changing the DLL it was fixed and behavior was the same as on Vista 32.

It is still the same patch as described on Nabble but I made two modifications. Unfortunately I do not know yet whether both modifications are necessary but that can be easily tested with some more test versions.

That's great news!

Btw, is there are reason that WinAVR uses MSYS 1.0.8 instead of the current stable version 1.0.10?

These utilities were put together quite some time ago. They worked and I haven't looked into them since. But, as you can see, they need some work.

Eric

EW wrote:
Well, if it's the same bug as for Vista (it also spits out a spawnv error), then hopefully it's fixed. I don't have a Win98 box to test this on, so if somebody has access to one and is willing to do it, I would be very grateful!

Eric

Sorry for that. For Win98 it's not fixed. The _spawnv error is still available on Windows 98SE.

I change the computer and load new versions of WinAvr Studio and KamAvr
I get this kind of error message from both (Studio and KamAvr) when build
{
AllocationBase 0x0, BaseAddress 0x71590000, RegionSize 0x170000, State 0x10000
C:\WinAVR\utils\bin\rm.exe: *** Couldn't reserve space for cygwin's heap, Win32 error 487
make: *** [clean] Error 1
2
}
is this same problem as above?
I was trying to update cygwin1.dll what is recommended somewhere but I'm littlebit out of these dll-updates so My humble request is that someone could give me simple answer what I should to do to get WinAVR and ide to work.

-Jarmo-

I could get avr-gcc.exe running without _spawnv error with the patch for pex-win32.c i used already for the previous WinAVR-20070122 version.

*** Revision_116495/pex-win32.c	Sun May 20 15:17:28 2007
--- patched/pex-win32.c	Sun May 20 15:19:52 2007
***************
*** 581,588 ****
--- 581,599 ----
}

newargv = fix_argv (argv);
+ #if 1
+   /* Fix required for Windows 98SE in order to avoid error
+      "-gcc: _spawnv: No such file or directory"
+      'newargv[0]' has seen backslashify via fix_argv and
+      it is suitable for _spawnv and CreateProcess (called
+      from _spawnv) but 'executable' isn't.
+      02/02/2007 Stefan Brueck */
+   pid = (((flags & PEX_SEARCH) != 0 ? _spawnvp : _spawnv)
+ 	 (_P_NOWAIT, newargv[0], newargv));
+ #else
pid = (((flags & PEX_SEARCH) != 0 ? _spawnvp : _spawnv)
(_P_NOWAIT, executable, newargv));
+ #endif

if (pid == -1)
pid = spawn_script (executable, newargv);


In detail i used a binary patch again, since i'm not able to compile avr-gcc for Windows from scratch.

The code from pex-win32.c might be used in other tools as well.

Thanks for providing the patch. Can you tell me where you got it from? Or did you do it yourself?

My concern is that the patch forcibly replaces the executable argument with newargv[0]. This may work on Win98, but does it work with other Win32 OSes? I like the fact that this fixes the problem, I just don't like how it goes about fixing it. Perhaps there is a better way...

jko wrote:

I was trying to update cygwin1.dll what is recommended somewhere but I'm littlebit out of these dll-updates so My humble request is that someone could give me simple answer what I should to do to get WinAVR and ide to work.

Are you saying that you have Cygwin installed elsewhere on your machine?

jko wrote:

C:\WinAVR\utils\bin\rm.exe: *** Couldn't reserve space for cygwin's heap, Win32 error 487

is this same problem as above?

No, this is a problem inherent to the way cygwin works. Cygwin wants to allocate a piece of memory at a specific address. There is no guarantee that this succeeds, but Cygwin requires it anyway. So every once in a while it cannot allocate the memory at the address it wants and fails. It's just dirty programming but AFAIK it cannot be fixed other than by changing the whole program structure.

You could try to rebase msys-1.0.dll, the DLL on my website does exactly that (and nothing else). This probably reduces the number of times you get this error but cannot completely fix it either.

StefB wrote:
I could get avr-gcc.exe running without _spawnv error with the patch for pex-win32.c i used already for the previous WinAVR-20070122 version.

[...]

This looks more like circumventing the problem than solving it. Since it is the same _spawnv error it is probably the same _access problem. Maybe there is still an _access error in one of the programs?

EW wrote:
Thanks for providing the patch. Can you tell me where you got it from? Or did you do it yourself?

My concern is that the patch forcibly replaces the executable argument with newargv[0]. This may work on Win98, but does it work with other Win32 OSes? I like the fact that this fixes the problem, I just don't like how it goes about fixing it. Perhaps there is a better way...

Yes, i "invented" the patch myself. The reason why i used newargv[0] instead of executable is: i had not enough patch space (three bytes) in binary code to do a backslashify of executable.

But i saw that fix_argv() did already a backslashify on the commandline. And the (new)argv[0] of the commandline is the program that is called. Fortunately in this case newargv[0] and executable have the same content.

You are right about the beauty of the patch. It is only a workaround that works for me and others with Win98 and (one report) XP SP2.

A better patch might be a "fix_executable()" function that does a backslashify for a copy of executable (newexecutable) like fix_argv() does for argv. I'm quite sure that you can not use fix_argv(), because this function has other tasks too.

Quote:

Are you saying that you have Cygwin installed elsewhere on your machine?

I had one other Cygwin1.dll. It wasn't in the PATH, I rename it anyway, but no help, I get the same heap error message.
Could it be some other Cygwin-file what makes this problem?

Quote:

You could try to rebase msys-1.0.dll, the DLL on my website does exactly that (and nothing else). This probably reduces the number of times you get this error but cannot completely fix it either.

Sorry but I'm out (again), could You explain littlebit more how to rebase the dll.

-Jarmo-

jko wrote:
Sorry but I'm out (again), could You explain littlebit more how to rebase the dll.

You would need the rebase utility that comes with Microsoft's platform SDKs. Then run from the command line:

rebase -b 0x30000000 msys-1.0.dll

But you can also use the DLL from my website, it is effectively the same thing.

Quote:

But you can also use the DLL from my website, it is effectively the same thing.

Magic! It works beautifully.
Many thanks of Your kind help and Great websites

I'm using XP, and all the OS reference was to Vista in Your website. Is this known in XP before?

Thanks
-Jarmo-

The cygwin memory problem is not related to Vista but is a problem on all Windows systems. I just included it in my patch because it is a problem that shows up often. It depends on a lot of things whether the problem occurs, some of which are random. Cygwin tries to allocate memory at a fixed address (it shouldn't do that but that's the way it works) but other DLLs may be assigned to the same location by Windows. In this case the msys DLL is often allocated in the same memory space. Rebasing changes the default memory address at which the DLL is allocated in memory and thus reduces the chance of collision.

The _spawnv problem is related to the version of msvcrt.dll. The newer DLLs have additional parameter checking which causes the _access function to fail. avr-gcc has always passed invalid parameters to _access but this has not been noticed or affected anything until the parameter checking was included. This problem can occur on any system when msvcrt is updated, but for most people this goes along with Vista which has the latest version by default.

Eric,

looks very good. I like to see that for Insight / GDB there is no Perl necessary as in the version before and there is a libc.pdf file.
A tiny thing to improve:
The WinAVR-user-manual.html shows a dead link in Chapter 5.1 as a Tip:

Quote:

There is a tutorial on how to use GDB and avarice at the WinAVR web site.

Cheers

Knut

Ah, thanks for catching that, Knut!

I think that is minor enough that it probably won't get fixed in time for the release, but I'll put it on the WinAVR bug list for the next time.

Installed 20070515rc2 and found that an ATTINY45 program that use to compile in 4034 bytes now takes 4156 bytes (-Os optimization) AND no error is reported.

The compile stats say that the program space is 101.5% full and the list file shows it certainly has gone beyond 1000H but I get "build succeeded with 0 warnings..."

I've reverted back to a previous version since RC2 has 'bloated' my code.

cheers,
george.

When I tried compiling a project with RC2 that works fine under the previous release, it compiled all of the ISRs as normal, but for some reason it didn't add any of them to the interrupt vector table. Here's the vector table as generated by the previous release:

00000000 <__vectors>:
0:	0c 94 d4 03 	jmp	0x7a8	; 0x7a8 <__ctors_end>
4:	0c 94 ef 03 	jmp	0x7de	; 0x7de <__bad_interrupt>
8:	0c 94 4a 18 	jmp	0x3094	; 0x3094 <__vector_2>
c:	0c 94 4b 18 	jmp	0x3096	; 0x3096 <__vector_3>
10:	0c 94 ef 03 	jmp	0x7de	; 0x7de <__bad_interrupt>
14:	0c 94 ef 03 	jmp	0x7de	; 0x7de <__bad_interrupt>
18:	0c 94 ef 03 	jmp	0x7de	; 0x7de <__bad_interrupt>
1c:	0c 94 4c 18 	jmp	0x3098	; 0x3098 <__vector_7>
20:	0c 94 ef 03 	jmp	0x7de	; 0x7de <__bad_interrupt>
24:	0c 94 ef 03 	jmp	0x7de	; 0x7de <__bad_interrupt>
28:	0c 94 ef 03 	jmp	0x7de	; 0x7de <__bad_interrupt>
2c:	0c 94 ef 03 	jmp	0x7de	; 0x7de <__bad_interrupt>
30:	0c 94 ef 03 	jmp	0x7de	; 0x7de <__bad_interrupt>
34:	0c 94 5b 18 	jmp	0x30b6	; 0x30b6 <__vector_13>
38:	0c 94 ef 03 	jmp	0x7de	; 0x7de <__bad_interrupt>
3c:	0c 94 ef 03 	jmp	0x7de	; 0x7de <__bad_interrupt>
40:	0c 94 ef 03 	jmp	0x7de	; 0x7de <__bad_interrupt>
44:	0c 94 ef 03 	jmp	0x7de	; 0x7de <__bad_interrupt>
48:	0c 94 ef 03 	jmp	0x7de	; 0x7de <__bad_interrupt>
4c:	0c 94 ef 03 	jmp	0x7de	; 0x7de <__bad_interrupt>
50:	0c 94 ef 17 	jmp	0x2fde	; 0x2fde <__vector_20>
54:	0c 94 74 0b 	jmp	0x16e8	; 0x16e8 <__vector_21>
58:	0c 94 ef 03 	jmp	0x7de	; 0x7de <__bad_interrupt>
5c:	0c 94 ef 03 	jmp	0x7de	; 0x7de <__bad_interrupt>
60:	0c 94 ef 03 	jmp	0x7de	; 0x7de <__bad_interrupt>
64:	0c 94 ef 03 	jmp	0x7de	; 0x7de <__bad_interrupt>
68:	0c 94 ef 03 	jmp	0x7de	; 0x7de <__bad_interrupt>
6c:	0c 94 ef 03 	jmp	0x7de	; 0x7de <__bad_interrupt>

Here's what it looks like with RC2:

00000000 <__vectors>:
0:	0c 94 d4 03 	jmp	0x7a8	; 0x7a8 <__ctors_end>
4:	0c 94 f1 03 	jmp	0x7e2	; 0x7e2 <__bad_interrupt>
8:	0c 94 f1 03 	jmp	0x7e2	; 0x7e2 <__bad_interrupt>
c:	0c 94 f1 03 	jmp	0x7e2	; 0x7e2 <__bad_interrupt>
10:	0c 94 f1 03 	jmp	0x7e2	; 0x7e2 <__bad_interrupt>
14:	0c 94 f1 03 	jmp	0x7e2	; 0x7e2 <__bad_interrupt>
18:	0c 94 f1 03 	jmp	0x7e2	; 0x7e2 <__bad_interrupt>
1c:	0c 94 f1 03 	jmp	0x7e2	; 0x7e2 <__bad_interrupt>
20:	0c 94 f1 03 	jmp	0x7e2	; 0x7e2 <__bad_interrupt>
24:	0c 94 f1 03 	jmp	0x7e2	; 0x7e2 <__bad_interrupt>
28:	0c 94 f1 03 	jmp	0x7e2	; 0x7e2 <__bad_interrupt>
2c:	0c 94 f1 03 	jmp	0x7e2	; 0x7e2 <__bad_interrupt>
30:	0c 94 f1 03 	jmp	0x7e2	; 0x7e2 <__bad_interrupt>
34:	0c 94 f1 03 	jmp	0x7e2	; 0x7e2 <__bad_interrupt>
38:	0c 94 f1 03 	jmp	0x7e2	; 0x7e2 <__bad_interrupt>
3c:	0c 94 f1 03 	jmp	0x7e2	; 0x7e2 <__bad_interrupt>
40:	0c 94 f1 03 	jmp	0x7e2	; 0x7e2 <__bad_interrupt>
44:	0c 94 f1 03 	jmp	0x7e2	; 0x7e2 <__bad_interrupt>
48:	0c 94 f1 03 	jmp	0x7e2	; 0x7e2 <__bad_interrupt>
4c:	0c 94 f1 03 	jmp	0x7e2	; 0x7e2 <__bad_interrupt>
50:	0c 94 f1 03 	jmp	0x7e2	; 0x7e2 <__bad_interrupt>
54:	0c 94 f1 03 	jmp	0x7e2	; 0x7e2 <__bad_interrupt>
58:	0c 94 f1 03 	jmp	0x7e2	; 0x7e2 <__bad_interrupt>
5c:	0c 94 f1 03 	jmp	0x7e2	; 0x7e2 <__bad_interrupt>
60:	0c 94 f1 03 	jmp	0x7e2	; 0x7e2 <__bad_interrupt>
64:	0c 94 f1 03 	jmp	0x7e2	; 0x7e2 <__bad_interrupt>
68:	0c 94 f1 03 	jmp	0x7e2	; 0x7e2 <__bad_interrupt>
6c:	0c 94 f1 03 	jmp	0x7e2	; 0x7e2 <__bad_interrupt>

Here's my makefile, for reference. It started out as an AVR Studio generated file, but I modified it substantially:

###############################################################################
# Makefile for the project TorqTraQ
###############################################################################

## General Flags
PROJECT = TorqTraQ
MCU = atmega644
TARGET = TorqTraQ.elf
CC = avr-gcc.exe

## Options common to compile, link and assembly rules
COMMON = -mmcu=$(MCU) ## Compile options common for all C compilation units. CFLAGS =$(COMMON)
CFLAGS += -Wall -gdwarf-2 -std=gnu99 -DTORQTRAQ -DF_CPU=7372800UL -Os -fwhole-program -combine -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums

LDFLAGS = -Wl,-u,vfprintf -lprintf_flt -Wl,-u,vfscanf -lscanf_flt -lm -lc

## Intel Hex file production flags
HEX_FLASH_FLAGS = -R .eeprom

## Build
all: $(TARGET) TorqTraQ.hex TorqTraQ.bin TorqTraQ.lss size ## Compile & Link$(TARGET): ../clock.c ../eeprom.c ../peripherals.c ../calib_32kHz.c ../serial.c ../measure.c ../main.c
$(CC)$(CFLAGS) $^$(LDFLAGS) -o $(TARGET) %.hex:$(TARGET)
avr-objcopy -O ihex $(HEX_FLASH_FLAGS)$< $@ %.bin:$(TARGET)
avr-objcopy -O binary $(HEX_FLASH_FLAGS)$< $@ cat TorqTraQ.bin vernumber.txt >TorqTraQ_signed.bin %.lss:$(TARGET)
avr-objdump -h -S $< >$@

size: ${TARGET} @echo @avr-size -C --mcu=${MCU} ${TARGET} ## Clean target .PHONY: clean clean: -rm -rf TorqTraQ.elf dep/* TorqTraQ.hex TorqTraQ.bin TorqTraQ.lss TorqTraQ.map ## Other dependencies -include$(shell mkdir dep 2>/dev/null) \$(wildcard dep/*)

I didn't change anything else in between (except for removing the trailing zeros from the names of the SPI registers and bits, which has apparently changed for RC2). I'm stumped. Any ideas?

Thanks,
Aaron T.

Hi Aaron,

Can you post how you are declaring the ISRs?

How has it been going with -fwhole-program -combine?

Hi EW,

-fwhile-program and -combine worked great with the previous release. Adding those two improved optimization and reduced my code size a little bit. A quick comparison shows I get 37888 bytes with them, versus 38312 without.

I'm not declaring the ISRs separate from when I define them, and they're defined in various source files. My definitions are written like this:

ISR(TIMER1_COMPA_vect)
{
//ISR code goes here
}

I have three ISRs defined as empty, like this:

EMPTY_INTERRUPT(INT1_vect);

EMPTY_INTERRUPT(INT2_vect);

EMPTY_INTERRUPT(PCINT3_vect);

The ISRs (including the empty ones) are being compiled and they appear in the .lss file just as before, they're just not being added to the vector table for some reason. Any advice would be appreciated.

Thanks,
Aaron T.

Could you post (attach) your map file? Also, can you try building without -fwhole-program -combine to see if that has any effect?

Aha, building without -fwhole-program -combine fixed the interrupt vector table so that it actually points to the ISRs. Binary size without those two options is 37808, with them is 37628, so less benefit than before. Attached is my map file, generated with RC2 and -fwhole-program -combine enabled. For comparison, my map file from 20070122 is also attached.

Thanks,
Aaron T.

eta: Hang on, today is 20070525. Shouldn't RC2 be called "20070515"?

## Attachment(s):

arteitle wrote:

eta: Hang on, today is 20070525. Shouldn't RC2 be called "20070515"?

This is the first time that I've done a release candidate. The idea was that, if all went well, then the release will happen on 20070525. So far, all looks good. I'll be doing the release a little bit later today.

Eric Weddington

I notice that the new release assigns data items RAM in a different order than with gcc v3.4.5. I realize that this is probably not a bug but it may affect your application if you've been relying on having data ordered the way that it had been done.

The difference, as far as I can tell, is that data items defined with the static attribute are now placed lower in RAM that those in the same section that are not static, irrespective of the order in which they are defined or referenced.

Consider this example program:

char d1        __attribute__ ((section(".noinit")));
static char d2 __attribute__ ((section(".noinit")));

int main (void)
{
d1 = 0;
d2 = 0;
return(0);
}

When compiled with gcc v3.4.5 (for the mega32), the content of the .sym file relating to RAM appears thusly:

00800060 B __bss_end
00800060 B __bss_start
00800060 D __data_end
00800060 D __data_start
00800060 D _edata
00800060 B d1
00800061 b d2
00800062 B _end

If you switch the order of the definitions of d1 and d2 in the source code, d2 will be assigned an address lower than d1.

With the release candidate (gcc v4.1.2) the data assignment is as shown below, irrespective of the order of the definitions in the source file.

00800060 A __bss_end
00800060 A __bss_start
00800060 A __data_end
00800060 A __data_start
00800060 A _edata
00800060 b d2
00800061 B d1
00800062 B _end

Don Kinzer
ZBasic Microcontrollers
http://www.zbasic.net

EW wrote:
arteitle wrote:

eta: Hang on, today is 20070525. Shouldn't RC2 be called "20070515"?
The idea was that, if all went well, then the release will happen on 20070525.
That's a very reasonable naming convention. I suppose the only issue is that if bugs arise and a release doesn't happen on that day. In that case, I think this issue is minor. There'd be a 20070525-rc2 release, but never a 20070525 release. Not a big deal, I think.
EW wrote:
I'll be doing the release a little bit later today.
Excellent. Thanks for your great work on the project.

kevinrosenberg wrote:
EW wrote:
arteitle wrote:

eta: Hang on, today is 20070525. Shouldn't RC2 be called "20070515"?
The idea was that, if all went well, then the release will happen on 20070525.
That's a very reasonable naming convention. I suppose the only issue is that if bugs arise and a release doesn't happen on that day. In that case, I think this issue is minor. There'd be a 20070525-rc2 release, but never a 20070525 release. Not a big deal, I think.

Ok, to be specific, I originally had the release candidate as 200705rc2, i.e. not tied to a specific date but sometime in the month of May.

This caused a conflict with AVR Studio and how it searches for a WinAVR installation and how it determines if the date is newer than a particular date. It looks like AVR Studio just converts the WinAVR version up to a space or character, making it only see a date of 200705, which was older than some date it was looking for, wreaking havoc with the install. (btw, I found all this out with "200705rc1", an internal release candidate.) So I changed it at the last minute to 20070525rc2, with the hopes that I wouldn't have to change anything for a final release. :) AVR Studio will be changed in the future to better work with WinAVR installations and version numbers.

Eric

As I mentioned above, remvoing "-fwhole-program -combine" from my makefile resulted in a functional binary, with a correct interrupt vector table. Should "-fwhole-program -combine" work with the new release, or is it unsupported?

Thanks,
Aaron T.

arteitle wrote:
As I mentioned above, remvoing "-fwhole-program -combine" from my makefile resulted in a functional binary, with a correct interrupt vector table. Should "-fwhole-program -combine" work with the new release, or is it unsupported?

Yes, and no. "-fwhole-program -combine" was added to the 4.x seried. However, there has not been much (none) testing of this with the AVR target. So, on one hand, I'm glad to see that it does optimize your application better, but on the other hand, I'm not terribly surprised that there are some issues with this.

It would be helpful if you could fill out a bug report at the GCC project.
How to report bugs:
http://gcc.gnu.org/bugs.html
Bug database:
http://gcc.gnu.org/bugzilla/

In the "target" field, put "avr" (no quotes). Feel free to put my email address in the CC list, so I can help keep track of the issue.

StefB wrote:
I could get avr-gcc.exe running without _spawnv error with the patch for pex-win32.c i used already for the previous WinAVR-20070122 version.
In detail i used a binary patch again, since i'm not able to compile avr-gcc for Windows from scratch.

Could anybody please send me binary patch for avr-gcc from WinAVR 20070525 to get it working in Win98?

I havn't looked in WinAVR 20070525 "final" yet (was in holidays in Spain ;-) I'll inform you soon whether a patch is required at all.

I have final WinAVR 20070525 and Win 98 - unfortunately patch IS required.

drzonca wrote:
I have final WinAVR 20070525 and Win 98 - unfortunately patch IS required.

Same result here with Windows98SE.

The binary patched avr-gcc.exe is attached. In the archive is also a small description how to find the patch position via disassembling.

Maybe other tools require the same patch - please write when you get the _spawnv error with other tools.

Stefan

## Attachment(s):

What is the issue in the source code that the binary patch fixes? I'd rather get this fixed in the source code...

The issue is a incompatibility of the format of parameter 'executable' with the _spawnv() function in Windows98 MSVCRT.DLL (MS C Runtime Library).

'executable' contains slashes as seperators and _spawnv() of MSVCRT.DLL (or to be more precise some of _spawnv's subfunctions such as access() and CreateProcess()) chokes on this.

Maybe this is fixed in later MSVCRT.DLLs on other Windows systems. I have MSVCRT.DLL version 6.10.9844.0 from Visual C++ 6. More investigations would require debugging different MSVCRT.DLL versions on different Windows systems.

I can understand when a source change in GCC's pex-win32.c is not considered. It is not a task of the GCC-team to fix older libraries of MS.

I poke 2 bytes in avr-gcc.exe and i am happy when the program works with the "broken" MSVCRT.DLL. The effect is, that the parameter 'executable' is replaced by the parameter 'newargv[0]'. This is a backslashified version of 'executable'.

StefB wrote:
The binary patched avr-gcc.exe is attached. In the archive is also a small description how to find the patch position via disassembling.

Thank you very much! Patched version works fine, tested.

StefB wrote:
The binary patched avr-gcc.exe is attached. In the archive is also a small description how to find the patch position via disassembling.

Strange... but did not work for me :(

AVRStudio version:

AVR Studio        4.12.498  Service Pack 4
GUI Version       4, 12, 0, 491
AVR Simulator     1, 0, 1, 8
AT90PWM3          153

Operating System
Major             4
Minor             10
PlatformID        1
Build             67766446

Windows 98SE 4.10.2222
msvcrt.dll 6.10.9844.0
WinAVR.20070525

I replaced the avr-gcc.exe and also avr-gcc-4.1.2.exe still no change.

Build started 22.6.2007 at 13:30:45
avr-gcc.exe  -mmcu=at90pwm3 -Wall -gdwarf-2 -O0 -MD -MP -MT pwm3.o -MF dep/pwm3.o.d  -c  ../pwm3.c
avr-gcc.exe: _spawnv: No such file or directory
make: *** [pwm3.o] Error 1

What else to check?

WinAVR20070525 output is NOT compatible with AVR Studio 4.12.491. You must upgrade to 4.13.528 which the understands the 32 bit ELF debugging format now generated by 20070525

Cliff

Wow! That was really fast reply. OK, upgraded to 4.13.528. Still the same. I will try on second machine with Win 2k.

UPDATE:
On fresh Win 2k the installer of AStudio.4.13 had problems, manual copy of some dll files (Visual Studio 8 runtime libraries) was necessary, but finally there is no error as in Win 98SE...
Any help on what can I else check to run it on Win 98SE?

AVR Studio 4.13 on Windows 98SE is difficult. I have some projects that work, others not (exception when project is opened). I avoid AVR Studio om Windows 98SE.

Sure there were no problems with overwriting original avr-gcc.exe? Try to compare original avr-gcc.exe and patches avr-gcc.exe with a hexeditor. There should be differences in three bytes. I have no other idea how to help you, sorry.

Finally I gave up on trying to run it on 98SE. Tried both avr-gcc patches and replacing some dll files in windows/system to different versions. Even on clean 98SE with "unofficial" service pack (hxxp://sp.up.pl/) - still the same. For sure it has nothing to do with install directories - checked several different locations. Those constant exceptions while trying to open an existing project got really annoying. Strange that creating new project works fine.

However, I got sometimes the same exception on 2k if I open projects from startup wizard, so I disabled it in options and open projects from menu. Works fine. Still bothers me why the installer on 2k reports errors with registering some dll files and where to get required mfc80 runtime libraries (luckily I had them on my 98SE, but what program installed those I have no idea). Till now it seems that on 2k everything works despite installer errors.

Thanks for help anyway :wink:

Not settled the program all full day until now.
Thanks so much! :o

Just FYI I had this issue on XP Professional SP1 machine, used the patch from this post and fixed it - thanks a lot!

I am still learning...

Thank you, Eric!

I just tried WinAVR-20071221 with Windows98SE. It worked right out of the box. No _spawnv errors like in previous versions.

Thanks for the feedback! I'm glad it worked for you!