Why would code work when compiled with Atollic - but not with Code Sourcery ??

[jlchoobs]

Posted on May 31, 2012 at 20:16

I successfully compiled the stm3240g Sample Project using Code Sourcery.

But, it does nothing on the Discovery Board.

But, this code is directly converted from as WORKING Code on the Discovery Board

- when compiled with Atollic Compiler.

-> Why should the Code not run successfully if it compiles by the Code Sourcery too ??

What could cause this problem - difference ? Would WinArm work any better ?

[frankmeyer9]

Posted on May 31, 2012 at 20:21

What happens if you try to debug it ?

[Tesla DeLorean]

Posted on June 01, 2012 at 01:18

Compiling code successfully does not preclude issues with libraries and linkage. If you are really interested in why one binary works and another does not, you will need to examine the code. Get a disassembly listing, walk through it, get a debugger and step into it.

Other than that you are just asking everyone to guess what options, linkage, or libraries might be causing you grief.

[jlchoobs]

Posted on June 01, 2012 at 09:57

Clive - thanks for the response,

Actually, I am asking what tweaks are needed to get the stm3240g Sample code to compile under WinArm and/or Code Sourcery.  The Discovery Sample Codes are supposed to be generally compatible with most Gcc Compilers - YES ? * I used the stm3240g sample project. * I used the Stm32 Libraries. * It compiled and executed under Atollic - with minimal changes (you even gave me a suggestion of Clock that I missed). -> But it Does NOT work under Code Sourcery - so easily * I need to know common Problems, * And, what is needed to compile/run this under Code Sourcery and/or WinArm. - It must be common Code (stm3240) and Compilers (WinArm as you say) to many Developers - what's with the Stiffness ?? - I can't be the only person who has tried this.  I will be glad to put the Code out (with my notes) - if I can get it to run.  ...  As, I already have for many other Projects.

[frankmeyer9]

Posted on June 01, 2012 at 10:31

You have asked a very unspecific question.

''I successfully compiled the stm3240g Sample Project using Code Sourcery.'' That presumes no compiler/linker errors, and a loadable ELF file. CodeSourcery is a different toolchain, with different linker scripts, different startup files and different libs. Anyone supposes you are aware of that, and changed your Atollic project accordingly.''But, it does nothing on the Discovery Board.'' This is an error description as specific as you can expect from a female secretary. No further details are provided, only:''-> Why should the Code not run successfully if it compiles by the Code Sourcery too ??'' This is contradictory.

[jlchoobs]

Posted on June 01, 2012 at 10:49

I followed the standard procedure for compiling Stm32 on Code Sourcery.

I had to make ONLY 10 specific Tweaks to get this stm3240g Sample Code to COMPILE and RUN on ATOLLIC. So you do not know the standard procedure quirks for setting up and linking Stm32 Discovery on Code Sourcery ? Am I supposed to guess ? I have been doing Embedded Work/Asm (Avr/Pic/6502/6811/etc) for about 30 years. I got a lot more info and help from the AVR Docs and Group. All I am asking is for common problems and issues and tweaks with Stm32 Discovery on Code Sourcery. Do you have any ideas/suggestions - or just want to argue. I spend 40 hours per week working during the day - writing Linux Code for Website Video Streaming for 1000 Clients who log in to use it. - I hope at home that I do not have to stay up till 2am every night debugging Linker problems, etc. Don't have these messy quandries at work. Do you compile professionally - or just do this for fun ?

[frankmeyer9]

Posted on June 01, 2012 at 11:28

''I have been doing Embedded Work/Asm (Avr/Pic/6502/6811/etc) for about 30 years.''

So you probably aware of the fact that any code, either new or ported, does usually not run perfectly at the first try. So if you have successfully build some code, can't you check where it fails, say, with debugging ?''I spend 40 hours per week working during the day - writing Linux Code for Website Video ...'' That does not make one an ARM Cortex M expert - I'm speaking of my own experience here. I did, and do mess with 8 Bit uC's (PIC18, 8051, z80), even professionally, to answer qour question.

[Tesla DeLorean]

Posted on June 02, 2012 at 01:37

You're attacking the problem backward, instead of muntzing with the compiler/linker options go and look at your two binary examples of working vs not working. A gross failure is a pretty easy one to deal with, and if you're spending hours on this you need to work on your technique. I've been doing this a while too, and I own a lot of my own tools, and build others.

Once you understand the code generation issue you will be better placed to judge what the compiler/linker are doing, and why. The classic failure modes are : Bad stack pointer, non RAM or unaligned Bad vector location, not on a 512 byte boundary Bad vector table content, linked/physical address disagreement Bad linker scripts and code/data placement Broken C initialization code Presence of 32-bit assembler or library code. This fatal on an M3/M4 Use of FPU instructions on an M4 without enabling the unit Mismatch of external clock crystal, and coded assumption (HSE_VALUE) There are millions of reason why code won't run, and buggy code can compile and link without error. Walk the code listings, map files or break out the debugger.

[jlchoobs]

Posted on June 02, 2012 at 18:40

Thanks Clive,

As for the Debugger - I have not been able to get it to run yet. I assume another configuration issue. I have been building a successful coding project on Atollic without it - soI assume so with Code Sourcery.

[jlchoobs]

Posted on June 02, 2012 at 19:56

Results that I do have :

Map File: all Objects mapped to 0x00000000 Compiler Warning: 

d:/_eclipse/codesourcery/sourcery_codebench_lite_for_arm_eabi/bin/../lib/gcc/arm-none-eabi/4.6.1/../../../../arm-none-eabi/bin/ld.exe: warning: cannot find entry symbol Reset_Handler; defaulting to 08000000

Fixed: somehow forgot the .s to .S on the startup_stm32f4xx.S file. Still a problem though ...