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 ?

[linas2]

Posted on June 03, 2012 at 21:41

I have same problem.

Developed code on Atollic don't work with IAR, it looks like 0 errors/warnings but touchscreen just don't work. and sometimes i get pointer out of stack size, but even if i make simple paint program which is very small in code size, touchscreen is non responding have no idea how to fix that

[Tesla DeLorean]

Posted on June 03, 2012 at 21:58

Well it's probably because GCC tools typically set the stack to the top-of-RAM so the stack can be stupidly large. Keil and IAR examples typically only have a 1KB stack allocation before it ploughs into the statics/heap. If you have large automatic/local variable allocations without reconsidering the stack size much chaos will ensue.

[jlchoobs]

Posted on June 10, 2012 at 14:29

Well - I got it to compile.

Nothing to do with stack size. Still disappointed in the Code Sourcery. The compiled code runs with a Buzzer and Blink Led,  but only running at half the speed than from the Atollic compile. And of course, the USB functionality does not work at wrong Clock speed. Do not understand why. Same Initialization code for 168MHz PLL.

No real Code changes in the project.

I can say twice as slow -because the Heartbeat Led blinks now at 4 sec, instead of 2 sec like the Atollic compile.

[Tesla DeLorean]

Posted on June 10, 2012 at 17:40

The stack response was directed @Kilohercas, where stack placement is very different between GCC/GNU based compilers, and others which are not.

Your timing/speed issue might well be to do with the external setting of HSE_VALUE, and the differences in the external clocking via HSE. The STM32F4-Discovery board, as I recall, uses a 8 MHz crystal, the software library defaults to 25 MHz, and other STM32Fx board designs have used 16 MHz. The biggest tell of a disparity between software and hardware settings is a broken serial port baud rate. Timers and tick interrupts clearly being another.

[jlchoobs]

Posted on June 10, 2012 at 20:32

That is what I first guessed.

But, all the files are the same, including the system_stm32f4xx.h/c which still specify pll_m=8; pll_n=336; pll_p=2; pll_q=7 So that is not it. I can only assume the problem is in the makefile or startup.S

[Tesla DeLorean]

Posted on June 10, 2012 at 20:54

But, all the files are the same, including the system_stm32f4xx.h/c

To my point that it's external, like -DHSE_VALUE=8000000, or for that matter that the library is built independently of the settings for the application. This is probably less of an issue for the current libraries, but was the case in the original F1 versions. Looking at a disassembly, map file, or printing out key values, should certainly permit you to track down why the speed is different in rather short order. If I had the code I'd figure out, as it is I don't have enough details, so I get to guess.

[jlchoobs]

Posted on June 10, 2012 at 21:02

Well, I am looking through it now.

The Asm/Lst files seem to look correct. And, I searched through for 25000000 and 16000000 in all h/c files,  -and all are set to 8000000 Also, the Makefile nor the Link files seem to have any speeds defined. ... I can't think of anything else ...

[jlchoobs]

Posted on June 11, 2012 at 05:55 The original post was too long to process during our migration. Please click on the provided URL to read the original post. https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I6ky&d=%2Fa%2F0X0000000buh%2F2sF3FUYCoEADXKxpKkOHObtfO7hPOfl4RZ8AdQtEC3w&asPdf=false

[jlchoobs]

Posted on June 11, 2012 at 05:58

Beginning of SYSTEM_STM32F4XX.C :

/////////////////////

/* PLL_VCO = (HSE_VALUE or HSI_VALUE / PLL_M) * PLL_N */

 // #define PLL_M      25  #define PLL_M      8 #define PLL_N      336

/* SYSCLK = PLL_VCO / PLL_P */

#define PLL_P      2

/* USB OTG FS, SDIO and RNG Clock =  PLL_VCO / PLLQ */

#define PLL_Q      7

[jlchoobs]

Posted on June 11, 2012 at 06:00 The original post was too long to process during our migration. Please click on the provided URL to read the original post. https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I6l3&d=%2Fa%2F0X0000000buk%2FHEZTCcjsmpvE9ZZx8jKCzeEslC0W1TIW9J5murbX49o&asPdf=false