STM32F103 - different processing rate

[zexx86]

Posted on May 12, 2014 at 15:19

Hello

I have a problem with different speed of processing rate while doing even trivial changes in source code.I mean it seems as CPU is changing its clock, so for same instructions it takes significantly longer for CPU.For example my code contains primitive delay function with NOPs. But when I add somewhere (from point of programmer - does not matter where) piece of additional code then sometimes it happen. Same source code works significantly slower (20-50%) and the rate is dependent on changes.Strange is, I checked Clock and it is still 72Mhz. Also I've examined some options in RCC, PWR, etc, but I am unable to determine what is wrong.I am nearly sure problem is in uninitialised memory.It seems as such thing in CPU is reading memory from some address used for firmware.It is enough to for example add or remove some lines in source code - if (variable), changing variable type, ... to fix slow rate but it is very tricky to fix it sometimes.This rate is only changing when program is compiled again with such changes.It must be memory related, since I found more issues with unitialised structures in my case.I checked my BSS section is zeroed too.It seems PWM rate and other interrupts are not affected even it is hardcoded to 72Mhz in init functions.My code is based on ST StdLibrary 3.4.0, no additional changes in template.Using Linaro GCC.Thanks for any help #compiler-processing-speed

[zexx86]

Posted on May 13, 2014 at 15:13

It works with Latency 1 pretty good, with 0 it does not work at all. I am sure it is running 72Mhz frequency, because I changed latency inSetSysClockTo72 (). Other methods confirms frequency too.

Unfortunately I can't get newer compiler, because I can't compile StdLibrary (3.4.0 nor 3.5.0): Error:

/tmp/cclGeLXK.s: Assembler messages:

/tmp/cclGeLXK.s:508: Error: registers may not be the same -- `strexb r0,r0,[r1]'

/tmp/cclGeLXK.s:533: Error: registers may not be the same -- `strexh r0,r0,[r1]'

in „lib/cm3/CoreSupport/core_cm3.o“

Compiler:gcc version 4.7.3 20130102 (prerelease) (Linaro GCC 4.7-201) UPDATE: I fixed compilation problem with: __attribute__( ( always_inline , optimize(''O0'')) ) but problem is, my firmware is not running correctly. I getting Hard Fault.

[Tesla DeLorean]

Posted on May 13, 2014 at 15:34

One might surmise it's a command line issue, here I've used Yagarto 4.5.1, 4.6.2 and 4.7.2 versions of GNU/GCC without issue for the STM32 series parts. I had some issues with 4.7.1

[zexx86]

Posted on May 13, 2014 at 15:38

My fault, it seems newer version of Summon ARM Toolchain does not support software FP. This is reason for Hard Fault.

[zexx86]

Posted on May 13, 2014 at 20:53

OK, I tried it with newer compiler but problem is even bigger.

With gcc 4.7.3 it is 2 times slower..

[Tesla DeLorean]

Posted on May 13, 2014 at 21:44

My fault, it seems newer version of Summon ARM Toolchain does not support software FP. This is reason for Hard Fault.

With -mcpu=cortex-m3 -mthumb  I'm hard pressed to believe it would generate HW FP code that would fault. What board are you using? What pins for LED and USART? It would be simpler for me to build a GNU/GCC template from scratch than to try and fight through your configuration/project settings.

[zexx86]

Posted on May 13, 2014 at 22:29

Indeed it was missing -mcpu=cortex-m3 -mthumb in linker. Now it works with GCC 4.8.3 arm-embedded toolchain. 

OK, it seems newer GCC makes optimization in different way. -Os is now absolutely without any optimization, but -O3 is optimized little bit better (55 vs 64kB for old GCC).I found that with this GCC 4.8.3 and -O3 -falign-functions=8 it works correctly in all tested conditions and Latency 2!Thats pretty good, code speed is identical as with 4.5.1 and -Os or -O3, but all the time :)I hope I am not wrong and its final solution. With Latency 1 main loop is even +40% faster what is great. I'll test it longer time, I like/need extra power so if possible, I want to use this latency permanently too.Unfortunately I can't post my source code. It is around 50 000 lines long and confidental. It is running on our board. But while it seems to be fixed, it is not needed.So thank you very much, I love your very good support.