Posted on:
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.
Posted on:
Are interrupt(IRQ) function-attributes used in the source?
Posted on:
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
Posted on:
> 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)
Posted on:
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
Posted on:
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?
Posted on:
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
Enable email notification
Enable multi-page view