Upgrading to yagarto gcc 4.5.0

Rui Guest #1774979
Rate this post
• ▲ useful
▼ not useful 
I'm using yagarto gcc 4.4.2 and I'm trying to upgrade to yagarto gcc 
4.5.0.
I've changed the filenames from -elf to -none-eabi in my makefile.
My project compiles without problems but when I download the hex file to 
my LPC2292 nothing happens.
I'm not an expert on gcc some I'm kind of lost.
I couldn't found anything related on the net.

One diference I can find.

With gcc 4.4.2 I get:
Program size:
   text     data      bss      dec      hex  filename
  97688      260     1576    99524    184c4  GymVibe.elf
  97688      260     1576    99524    184c4  (TOTALS)

Reading ELF file:
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 61 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            ARM
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           ARM
  Version:                           0x1
  Entry point address:               0x200
  Start of program headers:          52 (bytes into file)
  Start of section headers:          306412 (bytes into file)
  Flags:                             0x2, has entry point, GNU EABI
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         2
  Size of section headers:           40 (bytes)
  Number of section headers:         19
  Section header string table index: 16


With gcc 4.5.0 I get:
  Program size:
   text     data      bss      dec      hex  filename
  95796      260     1564    97620    17d54  GymVibe.elf
  95796      260     1564    97620    17d54  (TOTALS)

Reading ELF file:
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           ARM
  Version:                           0x1
  Entry point address:               0x200
  Start of program headers:          52 (bytes into file)
  Start of section headers:          344912 (bytes into file)
  Flags:                             0x5000002, has entry point, 
Version5 EABI
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         2
  Size of section headers:           40 (bytes)
  Number of section headers:         20
  Section header string table index: 17

Can someone give me a hint on the problem?
Thanks.
Reply Quote Edit Move Thread sperren Anmeldepflicht aktivieren Anpinnen Delete topic Thread mit anderem zusammenführen Report post
Rui Guest #1778366
Rate this post
• ▲ useful
▼ not useful 
I use several IRQ in my code.

As an example, the I2C interrupt is defined as follows:

void vI2C_ISR( void ) _attribute_ ((interrupt("IRQ")));

The atribute keyword appers in this text as underlined because of some 
text editor configuration.
In the code the atribute keyword is prefixed and sufixed by 2 
underscores.

Don't know if this is what you were asking for.

Regards.
Rui
Reply Quote Edit Delete Report post
Martin T. Moderator #1779352
Rate this post
• ▲ useful
▼ not useful 
> Don't know if this is what you were asking for.
It is.

I once had similar problems with porting older. I'm currently do not 
have access to my projects-archive so just a few hints from what I can 
remember:
You may try to rebuild the code with the option -mapcs-frame and/or 
-fomit-frame-pointer. Also check for missing volatiles or non-dword 
hardware-register write/read: if in doubt use "full word" (32 bit) 
access only, not "half-word" (16bit) or byte-access, check your 
"LPC2292.h" for this. Maybe the older version of the toolchain/compiler 
"tolerated" the technically wrong code but the improved optimizations in 
the newer compiler-version does not.

If you still have problems create a minimal but buildable example where 
the issue can be reproduced (everything needed for a "make all"). Maybe 
just a simple "LED-Blink" with a Hardware-Timer and a Timer-ISR with all 
support files (makefile, linker-script, startup-code, application-code)
Reply Quote Edit Delete Report post
Rui Guest #1780524
Rate this post
• ▲ useful
▼ not useful 
I've try compilation with:
 -mapcs-frame;
 -fomit-frame-pointer;
 -mapcs-frame and -fomit-frame-pointer.
The behaviour is always the same.

I'm trying to compile a led blink example but so far no luck.
Tomorrow I will make another try.

In my code I have some register definition like this
#define PLLCFG  (*((volatile unsigned char  *) 0xE01FC084))

Are you saying that I must change the previous code to
#define PLLCFG  (*((volatile unsigned long *) 0xE01FC084))

All my hardware register definition have the volatile keyword.

Regards
Rui
Reply Quote Edit Delete Report post
Martin T. Moderator #1780863
Rate this post
• ▲ useful
▼ not useful 
Rui wrote:
>...
> In my code I have some register definition like this
> #define PLLCFG  (*((volatile unsigned char  *) 0xE01FC084))
>
> Are you saying that I must change the previous code to
> #define PLLCFG  (*((volatile unsigned long *) 0xE01FC084))
I did not say "must", it was just a proposal. But yes, try again after 
replacing unsigned char* and unsigned short* with unsigned long*. I can 
just remember that I have done such modifications in 
register-definitions during updates of older code. There have been core 
exceptions when not implemented  '32-bit' (sorry, currently no details, 
have to search my notes)

You may also check the assembler-listing and/or disassembly to see how 
the register-accesses have been compiled and/or single step using a 
debugger.

> All my hardware register definition have the volatile keyword.
o.k. Variables accessed in ISRs and "main-loop" have it too?
Reply Quote Edit Delete Report post
Rui Guest #1781266
Rate this post
• ▲ useful
▼ not useful 
Hi Martin.

I must apologize to you.
Yesterday my tests were wrong.

I’m working on 2 projects at the same time and yesterday I was compiling 
one project and downloading another one to my board.
So I was downloading the wrong hex file to my board.

Today I noticed my mistake and repeated the tests.

With the switch -mapcs-frame the program works ok.

I also found that -fomit-frame-pointer is enabled at levels -O, -O2, -O3 
and -Os.
Since in my case I use –O3 this switch was already being used.

If removed the optimization and the program works just fine, so I think 
-fomit-frame-pointer isn’t needed.

Thanks once more for helping me.
You were very helpful with this subject, and also in the past.

Regards.
Rui
Reply Quote Edit Delete Report post
Watch this topic

Reply

Please log in before posting.

Existing account

or

Log in with Google account

No account?

Registration is free and takes only a minute.

Register now