Posted on January 11, 2016 at 11:32I 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.
