RE: [avr-gcc-list] What has changed between WinAVR 20070525rc2 andWinAVR 20080430?

[Stu Bell]

Umm, describe "no longer works correctly".  There are two defects that I know of that can cause problems:

 

1.  If a function is called from an ISR, the ISR will not pre-save all of the "call-used" registers before calling the function.  This can cause serious and hard-to-track-down problems.  The only workaround on this that I know of is to hand-save all call-used registers on entry to the ISR and restore them before exit.  WinAVR defect 1956569  A patch has been submitted according to Eric.

 

2.  On 3-byte PC processors (ATmega2560/2561), the EEPROM routines will not work correctly.  This is because they were rewritten to use function pointers, and GCC only knows about 2-byte function pointers.  A patched eeprom.h file has been submitted.  AVR-LibC Bug 22878

 

These are both changes from WinAVR 20071221 that caused my code to fail.  There may be more, but because of problem 1 above, I cannot get my code to run long enough to find anything else.

 

If you can live with 20071221, I would stick with that.  From your problem description, I would definitely suspect problem #1 above.

Best regards,

Stu Bell
DataPlay (DPHI, Inc.)

 

---

From: address@hidden [mailto:address@hidden On Behalf Of Bob Paddock
Sent: Monday, May 12, 2008 2:35 PM
To: address@hidden
Subject: [avr-gcc-list] What has changed between WinAVR 20070525rc2 andWinAVR 20080430?

Can anyone tell me what has changed from:

avr-gcc (GCC) 4.1.2 (WinAVR 20070525rc2)

to?:

avr-gcc (WinAVR 20080430) 4.3.0

I recompiled code for a working product using 4.1.2 with 4.3.0 and it
no longer works correctly.

Fairly complex product so trying to localize the problem would not be
all that much fun, without some insights as to what might be
different.

The unit has a bit mapped display.  With 4.3.0 I have random pixels
that I don't have with 4.1.2, which probably indicates that I have
something marginal in my display driver timing.  When I assert INT0
the unit eventually locks up with 4.3.0, but not with 4.1.2.

All rather vague descriptions, I know...

 

RAM and EEPROM usage remained the same, code size

grew by 516 bytes going from 4.1.2 to 4.3.0.