What has changed between WinAVR 20070525rc2 and WinAVR 20080430?

[Bob Paddock-3]

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.

 

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Anatoly Sokolov-2]

Hello.

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

 avr-gcc 4.3 don't save all call-used registers in interrupt handler routine
if it do function call, but should. It is in you ISR is function calls?

Anatoly.
_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[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: avr-gcc-list-bounces+sbell=dataplay.com@... [mailto:avr-gcc-list-bounces+sbell=dataplay.com@...] On Behalf Of Bob Paddock
Sent: Monday, May 12, 2008 2:35 PM
To: avr-gcc-list@...
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.

 

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Bob Paddock]

On Monday 12 May 2008 04:49:33 pm Anatoly Sokolov wrote:

>  avr-gcc 4.3 don't save all call-used registers in interrupt handler
> routine if it do function call, but should. It is in you ISR is function
> calls?

I'll check the code when I get back to work in the morning, but
it should not be calling any functions.  I try not to do that in
my interrupt handlers due to exactly this type of overhead.




--
                http://www.wearablesmartsensors.com/
 http://www.softwaresafety.net/ http://www.designer-iii.com/
                 http://www.unusualresearch.com/


_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Bob Paddock]

On Monday 12 May 2008 04:50:56 pm Stu Bell wrote:
> Umm, describe "no longer works correctly".

Ok, but don't know that it will help, as it doesn't really
help me any even with the unit in my hand. :-)

This unit is a type of Panic Alarm.  It has a big "Alarm" button
on the top of it.   The Alarm button is hooked up to INT0,
which sets a flag, and takes the unit of out sleep.
main() see the flag is set displays "Alarm" on the bit
mapped display, flashes a Red LED, and turns on
a vibrating motor, and transmits a radio message.
At this point with 4.3.0 the unit locks up, with 4.1.2 it
does not.  By "lock up" I mean main() has stopped looping.

> 1.  If a function is called from an ISR,

If I'm calling a function from my ISR it is by mistake and I've forgotten
about it, as I try really hard not to do that.  Will double check.

> 2.  On 3-byte PC processors (ATmega2560/2561),

This is a AT90CAN64.

My technician is wiring up the JTAG port, so I can get some
break points around to see if I can find out where it is locking
up.  Unit is size of pager and didn't have room for a real JTAG
connector...the parts and units keep getting smaller but for the most
part the debugging hardware isn't... :-(


_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Steven Michalske]

On May 12, 2008, at 5:04 PM, Bob Paddock wrote:

> This is a AT90CAN64.
>
> My technician is wiring up the JTAG port, so I can get some
> break points around to see if I can find out where it is locking
> up.  Unit is size of pager and didn't have room for a real JTAG
> connector...the parts and units keep getting smaller but for the most
> part the debugging hardware isn't... :-(

a bit off topic,  but a bed of nails works great for not having to  
have a connector for jtag and allows for ICT in assembly on plain ole  
test point pads.

All that is needed is a jig with precisely drilled holes.

Steve

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Bob Paddock]

On Monday 12 May 2008 08:13:31 pm Steven Michalske wrote:

> a bit off topic,  but a bed of nails works great for not having to
> have a connector for jtag and allows for ICT in assembly on plain ole
> test point pads.

The JTAG port in this case is six 18 mil holes on a similar grid spacing,
the "nails" don't fit in this case.  Use them regularly.  The normal
production test points do fit the "nails".   This unit really is the size of
a small pager there is little board space that isn't covered with parts.
The JTAG port is actually under the charger jack.

For anyone not familiar with Spring Probe "nails" I wrote a paper
for Circuit Cellar Online about them at the heights of the Dot-Com
era:

http://www.designer-iii.com/cco/SpringProbes.pdf

Most of the links there are long dead being written in the 90's.
Mouser carries IDI Spring Probes now.

Rest of my old Resource Pages can be found
here:  http://www.designer-iii.com


_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Weddington, Eric-2]

 

> -----Original Message-----
> From:
> avr-gcc-list-bounces+eweddington=cso.atmel.com@...
> [mailto:avr-gcc-list-bounces+eweddington=cso.atmel.com@nongnu.
> org] On Behalf Of Bob Paddock
> Sent: Monday, May 12, 2008 5:48 PM
> To: avr-gcc-list@...
> Subject: Re: [avr-gcc-list] What has changed between WinAVR
> 20070525rc2andWinAVR 20080430?
>
> On Monday 12 May 2008 04:49:33 pm Anatoly Sokolov wrote:
>
> >  avr-gcc 4.3 don't save all call-used registers in interrupt handler
> > routine if it do function call, but should. It is in you
> ISR is function
> > calls?
>
> I'll check the code when I get back to work in the morning, but
> it should not be calling any functions.  I try not to do that in
> my interrupt handlers due to exactly this type of overhead.
>

FYI, I just released WinAVR 20080512 that contains a patch from Anatoly
that fixes this problem.


_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Bob Paddock-3]

FYI, I just released WinAVR 20080512 that contains a patch from Anatoly
that fixes this problem.

 

Code is now running fine with that version.  Thank you.

I'll have to find the function call I put in the IRQ and didn't mean to...

 

BTW for the next release it might be nice if all of these

were in sync as far as what is current:

 

C:\WinAVR-20080512\WinAVR-user-manual.html

http://winavr.sourceforge.net/news.html
http://sourceforge.net/news/?group_id=68108

 

Is there a public all encompassing change log anyplace for WinAVR as a whole,

to tell what is different between releases?

 

Also the installer's license file has the old FSF address,

and everything is copyright 2006 rather than 2008.

 

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Bob Paddock-3]

On 5/13/08, Preston Wilson <pwilson@...> wrote:
> "Bob Paddock" wrote:
> >>
> >> FYI, I just released WinAVR 20080512 that contains a patch from Anatoly
> >> that fixes this problem.
>
> The other item you noted was code size increase, and I did not see (I could
> have missed it) anyone address that issue.

4.1.2/20070525rc2   33658
4.3.0/20080430:       34174
4.3.0/20080512:       34182

I expected the increase between 20080430 and 20080512 due to the nature
of saving more registers.  The 516 byte  increase between 20070525 and now
is more of the disappointment, but the price of bug fixes.  With this project
I still have 49% of the Flash free so it a none issue to me right now.

> Anatoly Sokolov suggested, in another thread or two on the avr-gcc list,
> using the gcc option "--param inline-call-cost=N"
> Where N is between 1 and 7
>
> I found that for the one project that I have going now where size really
> matters, that N=3 is giving me the smallest binary.  Oddly with
> WinAVR-20080430 N=2 gave the smallest binary.

Alas the boss has "Ship by X" on the schedule, not "put randomg settings
in to the tools to see what happens".  There would also the the "whole
program optimization" setting to try, someday, most likly when the
boss says "you can fit this one more feature in the part you have" for
the X time...  Personally putting random setting in is far more fun.
:-)

Anyway of doing "-Osmallest" without doing it by hand on each project?


_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Weddington, Eric-2]

 

> -----Original Message-----
> From:
> avr-gcc-list-bounces+eweddington=cso.atmel.com@...
> [mailto:avr-gcc-list-bounces+eweddington=cso.atmel.com@nongnu.
> org] On Behalf Of Bob Paddock
> Sent: Tuesday, May 13, 2008 11:11 AM
> To: avr-gcc-list@...
> Subject: Re: [avr-gcc-list] What has changed between
> WinAVR20070525rc2andWinAVR 20080430?
>
>  
> BTW for the next release it might be nice if all of these
> were in sync as far as what is current:
>  
> C:\WinAVR-20080512\WinAVR-user-manual.html
> http://winavr.sourceforge.net/news.html
> http://sourceforge.net/news/?group_id=68108

I haven't formally announced 20080512, hence no news item yet. It's on
the list for today. I'll see about updating the web pages as I haven't
done that in a while.

 
> Is there a public all encompassing change log anyplace for
> WinAVR as a whole,
> to tell what is different between releases?

No, and it would be difficult to do so. Mainly because I would have to
gather the changes done in any packages that have been updated, or new
patches added, so this would mean gathering up all changes in binutils,
gcc, avr-libc, avr-gdb, srecord, etc.
 
> Also the installer's license file has the old FSF address,
> and everything is copyright 2006 rather than 2008.

Thanks for catching that! Would you be willing to fill out a WinAVR bug
report?

Eric


_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Bob Paddock]

On Tuesday 13 May 2008 02:36:29 pm Bob Paddock wrote:

> > Anatoly Sokolov suggested, in another thread or two on the avr-gcc list,
> > using the gcc option "--param inline-call-cost=N"
> > Where N is between 1 and 7
> >
> > I found that for the one project that I have going now where size really
> > matters, that N=3 is giving me the smallest binary.  Oddly with
> > WinAVR-20080430 N=2 gave the smallest binary.
>
> Alas the boss has "Ship by X" on the schedule, not "put randomg settings
> in to the tools to see what happens".

Anyone tried this?:
http://www.coyotegulch.com/products/acovea/

"ACOVEA (Analysis of Compiler Options via Evolutionary Algorithm) implements a
genetic algorithm to find the "best" options for compiling programs with the
GNU Compiler Collection (GCC) C and C++ compilers. "Best", in this context,
is defined as those options that produce the fastest executable program from
a given source code. Acovea is a C++ framework that can be extended to test
other programming languages and non-GCC compilers."

I wonder if there is a "Best" for size rather than speed in ACOVEA?

--
                http://www.wearablesmartsensors.com/
 http://www.softwaresafety.net/ http://www.designer-iii.com/
                 http://www.unusualresearch.com/


_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Weddington, Eric-2]

 

> -----Original Message-----
> From:
> avr-gcc-list-bounces+eweddington=cso.atmel.com@...
> [mailto:avr-gcc-list-bounces+eweddington=cso.atmel.com@nongnu.
> org] On Behalf Of Bob Paddock
> Sent: Sunday, June 29, 2008 11:20 AM
> To: avr-gcc-list@...
> Subject: Re: [avr-gcc-list] What has changed between
> WinAVR20070525rc2andWinAVR 20080430?
>
> On Tuesday 13 May 2008 02:36:29 pm Bob Paddock wrote:
>
> > > Anatoly Sokolov suggested, in another thread or two on
> the avr-gcc list,
> > > using the gcc option "--param inline-call-cost=N"
> > > Where N is between 1 and 7
> > >
> > > I found that for the one project that I have going now
> where size really
> > > matters, that N=3 is giving me the smallest binary.  Oddly with
> > > WinAVR-20080430 N=2 gave the smallest binary.
> >
> > Alas the boss has "Ship by X" on the schedule, not "put
> randomg settings
> > in to the tools to see what happens".
>
> Anyone tried this?:
> http://www.coyotegulch.com/products/acovea/
>

I haven't tried it, though I've been aware of acovea for some years now.


_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list