stm32f4 DSP_Lib project build issue

Hi,

I tried to build one DSP lib example from ST's peripheral standard driver lib (STM32F4xx_DSP_StdPeriph_Lib_V1.0.1), with somehow limited success. I'm using Crossworks for ARM, V2.2.0, under Linux in this case.

When trying to use the precompiled library version in STM32F4xx_DSP_StdPeriph_Lib_V1.0.1/Libraries/CMSIS/Lib/ARM/, I got a "undefined reference" linker error. Obviously, a library named "arm_cortexM4lf_math.lib" could not be handled.

I renamed it to "libarm_cortexM4lf_math.a", which gave me the following errors about "conflicting CPU architectures", which I'm unable to decode accurately:

Building "f4_fft_test" in configuration "THUMB Debug"
Linking f4_fft_test.elf
    ../Project/STM32F4xx_DSP_StdPeriph_Lib_V1.0.1/Libraries/CMSIS/Lib/ARM/libarm_cortexM4lf_math.a(arm_cmplx_mag_f32.o): Conflicting CPU architectures 13/0
    /usr/share/crossworks_for_arm_2.2/lib/libc_v7em_fpv4_sp_d16_t_le_eabi.a(__vfprintf_int.o): Conflicting CPU architectures 0/13
    /usr/share/crossworks_for_arm_2.2/lib/libc_v7em_fpv4_sp_d16_t_le_eabi.a(libc2.o): Conflicting CPU architectures 0/13
    /usr/share/crossworks_for_arm_2.2/lib/libc_v7em_fpv4_sp_d16_t_le_eabi.a(libc_asm.o): Conflicting CPU architectures 0/13
    /usr/share/crossworks_for_arm_2.2/lib/libc_user_libc_v7em_fpv4_sp_d16_t_le_eabi.a(user_libc.o): Conflicting CPU architectures 0/13
    THUMB Debug/f4_fft_test.elf section `.constdata' will not fit in region `UNPLACED_SECTIONS'
    region `UNPLACED_SECTIONS' overflowed by 8705 bytes
Build failed

I have checked seveal settings like ABI, FP-ABI, endianess etc., without detecting a source of the problem I ended up pulling the library source file into the project, which works at least.

I'm not sure if this precompiled libs are usable within Crossworks.

Can Crossworks deal with libs named "<name>.lib" at all, or do I have to rename them ?

Do I need to rebuild this libs with Crossworks ?

Ben Rector

October 13, 2012 21:05

Did you ever figure out this problem? I have the same error with a different library and MCU, but unfortunately I don't have the source :(

frank meyer

October 14, 2012 14:22

In practical terms, yes.

I gave up on this (Keil-) prebuild library, and pulled the required sources over in my project. I only used some FFT related files, much less than the whole library. In general, this has the distinct advantage that all properties regarding optimization and debugging follow the rest of the project ...

I used this code for the STM32F4xx from ST. The DSP-Lib part of the firmware library is delivered by ARM, and not ST, and contains code/options for M0, M3 and M4 variants. Since it is basically a core-related library, and agnostic of specific peripherals, you should not have too big problems getting it running for another MCU.

The ST firmware sources can be found here: http://www.st.com/internet/mcu/product/252148.jsp

and are named " STM32F4 DSP and standard peripherals library, including 82 examples for 26 different peripherals and template project for 5 different IDEs".

I guess most newer firmware packages of Cortex M vendors contain the DSP lib code - if this vendor does his job to include it in his firmware packages.

I hope this helps.

stm32f4 DSP_Lib project build issue

Comments

Didn't find what you were looking for?