EmbDev.net

Forum: ARM programming with GCC/GNU tools Upgrading to yagarto gcc 4.5.0


Author: Rui (Guest)
Posted on:

Rate this post
0 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.

Author: Martin Thomas (mthomas) (Moderator)
Posted on:

Rate this post
0 useful
not useful
Are interrupt(IRQ) function-attributes used in the source?

Author: Rui (Guest)
Posted on:

Rate this post
0 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

Author: Martin Thomas (mthomas) (Moderator)
Posted on:

Rate this post
0 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)

Author: Rui (Guest)
Posted on:

Rate this post
0 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

Author: Martin Thomas (mthomas) (Moderator)
Posted on:

Rate this post
0 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?

Author: Rui (Guest)
Posted on:

Rate this post
0 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

Entering an e-mail address is optional. If you want to receive reply notifications by e-mail, please log in.

Rules — please read before posting

  • Post long source code as attachment, not in the text
  • Posting advertisements is forbidden.

Formatting options

  • [c]C code[/c]
  • [avrasm]AVR assembler code[/avrasm]
  • [code]code in other languages, ASCII drawings[/code]
  • [math]formula (LaTeX syntax)[/math]




Bild automatisch verkleinern, falls nötig
Note: the original post is older than 6 months. Please don't ask any new questions in this thread, but start a new one.