This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Problem compiling the CMSIS library in CCS



Hi,

I want to use dsp functions provided with the CMSIS library on a Stellaris Cortex-M4. I followed TI's guide on how to build the library: http://www.ti.com/lit/an/spma041b/spma041b.pdf

It gets through most of the compilation, but generates a few function declared implicitly warnings on compiler intrinsic functions. Here's one of the lines:

/* extract two q7_t samples to q15_t samples */
inA1 = __SXTB16(__ROR(input1, 8));                 

I did see __sxtb16() listed in the compiler documentation so it is a legitimate function.

The warning may be referring to __ROR(), though. There are 4 implicit declaration warnings on the compile and one of them is:

*pDst++ = (__ROR(in, 8)) & 0xFF000000;                    

 TI provides header files to make ARM's CMSIS code compatible with CCS and I did notice that some of the info in the .pdf is not accurate as of the current release of CMSIS. The guide steps through modifying CMSIS source files to make them compatible with CCS, but the source files I got from ARM already have the modifications.

I'm not sure why I'm getting the warnings when the functions should have declarations as part of the compiler, correct?

Any input is appreciated

-Brandon

  • Brandon,

    Could you send us one of the source files that generates the "function declared implicitly" warnings? We would need a preprocessed version of the file though so we can build it stand-alone and reproduce the warning.

    This page describes how to generate a preprocessed file. Just use that procedure to create the preprocessed file for one of the CMSIS source files that generates the warning and attach the preprocessed file here. Thanks.

  • Thanks,

    I attached the pre processed file. The warning popped up in a few files but the lines that generated the warnings we're mostly the same so I just chose the first file with a warning.

    0268.arm_dot_prod_q7.txt

    I changed the extension to .txt because .pp wasn't allowed as an attachment

    -Brandon

  • Thanks for attaching the file, I can reproduce the warnings. A couple of observations and comments:

    The intrinsic supported by the TI compiler _sxtb16 takes two arguments (as documented in the ARM Compiler Users Guide), while the function in the source file only takes one. The way the code is currently written the compiler assumes it is a function call and is not finding a function protoype for it, hence is generating the "function declared implicitly" message. If it were meant to use the compiler intrinsic, it should be written with single-underscore and and two arguments similar to the _smlad intrinsic a few lines below it (something like _sxtb16(input1, 8)).

     

  • Thanks for updating the thread status, I should have done that. 

    I went back and modified the lines that were generating the warning and now everything seems to be okay. Here's what I did:

    1.) In the cmsis_css.h file provided by TI, I added these lines:

    #define __SXTB16   _sxtb16      
    #define __ROR        _ror             

    2.) The sign extend intrinsic sxtb takes a value to shift and a rotate amount. The source files from ARM just passed one pre rotated argument to the sxtb instruction.

    So I changed these lines from this:

    __SXTB16( __ROR(input1, 8) );  

    To just this:

    __SXTB16( input1, 8 );                

  • BrandonM said:

    1.) In the cmsis_css.h file provided by TI, I added these lines:

    #define __SXTB16   _sxtb16      
    #define __ROR        _ror             

    Two comments on that:

    a) There should be two underscores before the ror instrinsic, not one. (with the TI ARM compiler v5.0.5)

    b) As previously noted, the TI ARM compiler _sxtb16 intrinsic takes a 2nd parameter which is the amount to rotate. By changing the definition of the __SXTB16 macro to include a rotate of zero avoids the need to change the ARM provided source code.

    i.e. in the cmsis.h include file I added the following defines, which then allowed the CMSIS 3.01 library to compile without any implicit function definition warnings and without having to change any of the ARM provided source code:

    #define __ROR __ror

     #define __SXTB16(src) _sxtb16((src),0)

  • I'm actually going back to this now and I'm interested in how you got it to compile so easily. I had more luck when I tried this a few months ago, but now I'm getting tons of errors that I can't seem to squish.

    The majority of my errors come from the assembly code, and the big one is " "#" not expected here ". From arm_bitreversal2.S in TransformFunctions:

    arm_bitreversal_32 PROC
        ADDS r3,r1,#1
        CMP r3,#1
        IT LS
        BXLS lr
        PUSH {r4-r9}
        ADDS r1,r2,#2 
        LSRS r3,r3,#2

    ...

    Everywhere a # is encountered, an error is thrown. 

    I'm using ti compiler v. 5.0.4

    Did you have to do anything special here to get it working?

    Edit: I got it working with an older version of CMSIS (3.01) as opposed to the newest version (3.20)

    This will suit my needs

  • BrandonM said:
    I'm actually going back to this now and I'm interested in how you got it to compile so easily. I had more luck when I tried this a few months ago, but now I'm getting tons of errors that I can't seem to squish.

    The majority of my errors come from the assembly code, and the big one is " "#" not expected here ". From arm_bitreversal2.S in TransformFunctions:

    It was CMSIS Version 3.01 I compiled, using TI ARM compiler v5.0.5. That version doesn't have a  arm_bitreversal2.S assembler source file, but a CMSIS-SP-00300-r3p1-00rel0\CMSIS\DSP_Lib\Source\TransformFunctions\arm_bitreversal.c C source file.

     I will have a look as version 3.2.0.

  • Hi, I'm also trying to build from source cmsis v3.20 using CCS v5.5.00077 for stellaris Launchpad lm4f120 part and my build errors circles around the arm_bitreversal2.S file. I will try building cmsis v3.01 as you said but was hoping you have an answer for v3.20. Attached are the preprocess file plus the CDT build console outputs. Any info will be highly appreciated.

    noel s cruz  seattle

    noel_s_cruz@yahoo.com

     

    dsplib_pp.zip
  • Noel37807 said:
    Hi, I'm also trying to build from source cmsis v3.20 using CCS v5.5.00077 for stellaris Launchpad lm4f120 part and my build errors circles around the arm_bitreversal2.S file.

    I found the thread Missing <system_*.c/h> and CMSIS header files for TIVA C Series, where the problem is explained as:
    ARM has started writing some functions in assembly to further optimize things, which caused a few build issues (the TI ARM assembler doesn't play very nicely with other assemblers... it doesn't support #if statements, which makes things fun).
    Stellaris Jordan was working on an update to the Using the CMSIS DSP Library in Code Composer Studio"
    for Stellaris® Application Report (SPMA041) on how to build r3p2-00rel1 (CMSIS 3 patch 2) in CCS. However, I can't seem to find the updated Application Report. 

  • hi, thanks for the info. i was able to compile n build successfully cmsis v3.01 w/ ccs 5.5 w/ arm compiler v5.1.1 n it generated the dsplib-cm4 lib file. i plan to test dis lib file for use in the 11 arm example projects provided. hope it works n following as guide spma041b w/ f120 launchpad as my target board. the example projects contain just one or two c files so should be easy assuming the built lib file is correct.

    noel

  • BrandonM said:
    The majority of my errors come from the assembly code, and the big one is " "#" not expected here ". From arm_bitreversal2.S in TransformFunctions:

    The first problem is that CCS 5.5 and the TI ARM 5.1.2 compiler don't agree on the extension for assembler source files.

    When the arm_bitreversal2.S assembler file is added to a CCS 5.5 project, the CCS project properties reports the file type as "Assembler Source File".

    CCS uses the TI ARM Compiler armcl to compile the arm_bitreversal2.S source file. However, by default armcl only treats .asm files as assembler files. Therefore, the .S assembler source file is attempted to be compiled as C source code which fails. To get the .S source file compiled as assembler under CCS project properties -> CCS Build -> ARM Compiler -> Advanced Options set "Extension for assembly files" to .S

     

    The second problem is that the TI ARM assembler doesn't support the C style preprocessor #if / #else / #elseif / #endif / #define directives used in the ARM supplied arm_bitreversal2.S source file. The attached 6862.arm_bitreversal2.zip contains a arm_bitreversal2.S source file which compiles under the TI ARM assembler. The changes were:

    - Use .asg instead of #define

    - Use .if / .else / .endif inplace of #if / #else / #endif

    With these changes was able to set CMS 3.2.0 to compile under CCS 5.5 with TI ARM compiler 5.1.2

  • ur info is good news for v3.20 w/c i'll try. just finished building 3 of the example projects using v3.01 & the newly built lib file. wen debugged, they all go to an infinite loop (ok) except for the linear interpolation example where it still goes to the while(1) inside the:

    if( snr2 > snr1)
        {
            status = ARM_MATH_SUCCESS;
        }
        else
        {
            status = ARM_MATH_TEST_FAILURE;
        }
        
        /* ----------------------------------------------------------------------
        ** Loop here if the signals fail the PASS check.
        ** This denotes a test failure
        ** ------------------------------------------------------------------- */
        if( status != ARM_MATH_SUCCESS)
        {
            while(1);     goes here w/c is not ok
        }

        while(1);                             /* main function does not return */

    i've excluded the arm files from build and replaced w/ the 2 ti-supplied linear interp files contained in sw01291. changed the arm linker file search stack size option to 512. just moving on and thanks for all the info and help.

    noel