cancel
Showing results for 
Search instead for 
Did you mean: 

Compiling STM32 PMSM FOC LIBv4.2 projects with GCC.

re.wolff9
Senior
Posted on December 20, 2015 at 20:45

Hi, 

After about 20 hours of work I've managed to compile an example FOC application with GCC.  

I have to link with the ''non-source-code'' precompiled library that is provided. In my case: ''MC_Library_STM32F302x8_single_drive''.

There are two such libraries in the FOC LIB. One with a ''.a'' extension, as delivered for IAR. And one with a ''.lib'' extension delivered for KEIL uVision. 

The IAR version turns out to initialize the function pointers inside objects to the actual address that the function resides at. This leads to a run-time hardfault when the CPU tries to execute the function in ARM mode as opposed to Thumb mode (lower bit set). 

The uVision version doesn't want to link due to architecture mismatch.  ''Conflicting CPU architectures 13/0''

Does anybody know of an option on the linker that will fix the addresses of the thumb-functions in my library? Does anybody know an option on the linker to make it ignore the architecture mismatch? (Would that work?) 

Would it be possible to get a gcc-compiled library from ST?

I've also spent a day installing the PMSM FOC kit and keil uVision on a virtual windows machine. I've given up (Windows doesn't like me, and the feeling is mutual. It had something like ''permission denied'' when trying to create output files. ). 

Anyway,  I'd be happy to just compile a test program once to see it work in Keil, but 1) I couldn't get it to work. 2) the stated limit is 32k code, and with the library I'm now at ''about 48k code'' so I don't think that will fit. 

Suggestions?

4 REPLIES 4
sam23
Associate
Posted on January 11, 2016 at 05:46

Wolff,

Did you get anywhere?  I am not as far along but this what I've run into:

You mentioned a permissions problem -- seems like installer sets everything to read only.  I ended up running Kiel ''as administrator'' (right click) and that seemed to avoid the issue.

I also ran into an error where crosscheck.h at two different lines that look like this:

#elif (defined(STM32F302x8) && defined(STM32F302X8))

The lower case x version is defined by ''control stage parameters.h'' but not sure where the upper one is defined.  I bypassed this but am concerned that I have avoided fixing a real problem.

I believe I have the parameters correct after discovering the /FOC SDK/SM32 PMSM FOC LIBv4.2/Web/Utilities/WB_Projects/SDK42x directory with a SDK42x-P-Nucleo-ihm001-BullRunnig.stmcx file for the workbench.

Unfortunately, I then get an error:

.\STM32F302x8\STM32F302x8_SINGLEDRIVE.axf: error: L6047U: The size of this image (33320 bytes) exceeds the maximum allowed for this version of the linker

I would much prefer a GCC based approach... now going to try IAR
re.wolff9
Senior
Posted on January 11, 2016 at 11:32

I have managed to get it to compile and run with Gcc. 

The keil codesize limit is hit. Just change the configuration to eliminate the UI code or something like that. Then it becomes about 25k, and that is allowed by keil. 

gcc has taken a different approach to ''eliminating dead code'' from the binary. It's called -fdata-sections -fcode-sections . Each function and variable is put in a separate section and the linker is then asked to eliminate sections that are never referenced. 

This works very well, except when you link against an IAR library: all code from the library is then in ''.text'' segment and won't be eliminated. That increases the binary by about 50%. 

Getting to the point where it compiles with GCC was a long road. Difficult to debug. But partly also complicated by not knowing the FOC software enough to know what I was doing. So for ''software engineering'' reasons I decided not to put the generated headers in the same directory as where other headers were located. Good decision from a software engineering viewpoint, but makes it difficult to get working. New approach is go with the flow, do it as ST does, overwrite the headers that are already there. 

Anyway, If you're getting the hardfault on an attempt to execute ARM mode instructions which the cortex M processor don't have, then you have a bug in your linker: 

 https://bugs.launchpad.net/gcc-arm-embedded/+bug/1421389?comments=all

Another thing you might run into is: If you take the approach of compiling, looking what symbols are missing, and adding the appropriate source file, you'll get ALMOST there... You'll need the interrupt file form SystemDriveParameters directory. There are weak symbols somewhere so you won't get an error if you leave it out, but it won't work.....

I'll see if I can create a package/howto on how to compile using gcc. But it will be a while: the coming two weeks are ''full'' with other stuff. 

-- Roger. 

tiwag
Associate
Posted on February 24, 2016 at 04:09

...

tiwag
Associate
Posted on February 24, 2016 at 04:09

@Roger

how did you manage to compile the MC FOC lib 4.2 examples using gcc ?

i have a STM32F302R8 board with a IHM07M1 driver board and would like to

use this with a custom BLDC motor. any hints?

thank you

Stephan