Inconsistent results in compiling gcc-arm-none-eabi for Vex Cortex

Hi All,

I’m using Vex Cortex CPU to run hex file generated by GCC-arm-none.

The process: I take c file which runs some API of the Cortex,
compile it with GCC-arm-none-eabi, link, create hex file and download to the Cortex by utility called CortexFlash.

I made this process on Windows with GCC-arm-none version 4.5.1 and version 4.4.1 found here:
https://code.google.com/p/arduino/downloads/detail?name=gcc-arm-none-eabi-4.4.1-2010q1-188-win32.tar.gz&can=2&q=

I try to make the same process on Mac (Yosemite) with a version of GCC found here:
[Google Code Archive - Long-term storage for Google Code Project Hosting.

The result is that the hex file is downloaded to the Cortex but not running.

In both OS I use the same flags for the compilation and for the linking.

I made some experiments:
If I’m using the hex file created by GCC compiled on windows 7 and trying to download by the mac to the Cortex - everything works fine,
but if I’m trying to download using the hex file created by the GCC compiled on the Mac processes, it does not run.

When I compare the two created hex files that supposed to be equal (compiled on windows and compiled on Mac and the same source c code, both GCC version 4.4.1) - they looks different.

Any suggestion how to solve it?
Thank you very much,
Einat](Google Code Archive - Long-term storage for Google Code Project Hosting.)

Have you tried compiling the working version for OSX rather than Windows 7? It looks like the executables you use weren’t from the same source

Provide a whole lot more detail. Source files, makefile, linker script, compiler & linker options etc… for both OS scenarios. What’s does gcc --version show on each OS?
If you post code here please use

[CODE]
tags.

Yes, post a small example that does not work and we can try and duplicate. Also post the .map files so we can see what the linker is doing. Are you linking against the ST standard peripheral library or something else? (what I’m really asking is where does the startup code come from).

Thanks for your comments.
I have some more focused result and I’ll try to include here the relevant information you’ve asked:

I know now - the creation process of the elf file is the one goes wrong.
The objects files are well created on OS X. (I moved them to windows after created on OS X and created an elf file on windows and hex file which runs and works fine with the expected program.)

I also created object files, elf, and map on the OS X and replaced the elf file, then called objcopy to create hex file and everything works well.
(I tried that with several of compilers versions - 4.4.1, 4.7.4, 4.9.3, 4.8.4 all gave the same results)

Code example is meaningless, because every piece of code has the same behavior. and second because - The code I write includes other classes in c++ that should be included and cannot be included here (Its too much code)
(I can send it by email)

The gcc options and commands are:

using g++:


//1.compilation:
..../arm-gcc/bin/arm-none-eabi-g++ -MD -D_STM32F103VDH6_ -D_STM3x_ -D_STM32x_ -mthumb -mcpu=cortex-m3 sourcefilepath -o objectfilepath" -I includedirectory1  -I includedirectory2 -c -fsigned-char -fno-rtti -fno-exceptions -ffunction-sections -Wall -mlittle-endian -s > logfilepath 2>&1

//2.linking:
..../arm-gcc/bin/arm-none-eabi-g++ -mcpu=cortex-m3 -mthumb -Wl,-T -Xlinker ldscriptpath -u _start -Wl,-static -Wl,--gc-sections -nostartfiles -Wl,-Map -Xlinker mapfilename


//using objcopy:

..../arm-gcc/bin/arm-none-eabi-objcopy elffilepath --target=ihex hexfilepath
---------------------------

//my ld script:
SEARCH_DIR(“C:\ProgramData\Intelitek\Coderz\RobotDownloader\link”)
SEARCH_DIR(“C:\ProgramData\Intelitek\Coderz\RobotDownloader\scripts”)

INCLUDE “C:\ProgramData\Intelitek\Coderz\RobotDownloader\program\inp\input.ld”
INPUT(“startupinit.o”)
INPUT(“runtime_cortex.lib”)
STARTUP(“startup.o”)

EXTERN( __io_putchar )
EXTERN( _write )

GROUP(
“STM32x_IO_Putchar_thumb.a”
“std_sbrk_thumb.lib”
“e_stdio_thumb.a”
“libc.a”
“libm.a”
)

OUTPUT(“C:\ProgramData\Intelitek\Coderz\RobotDownloader\program\obj\program.elf”)

INCLUDE “STM32F103_384K_64K_FLASH.ld”

//Please note - map file is attached as zip because it was too large to normally attach.

Thanks all!!
program.zip (96.8 KB)

I had a look at the map file. An excerpt.

So you are either en employee of Intelitek or are using (I would assume) the Inteletek runtime against the terms of the EULA. I have a hard time believing an Intelitek employee would be asking this question here.

Either way, I can’t help you with this issue.

Seems to be related to this project http://hub.intelitek.com/h/i/114615195-intelitek

Perhaps you could explain a little about your background because that map file does suggest unusual things.