CMSIS Library build error in CCS V6.1.0.0014 for TM4C1294NCPDT

Dear Amit
Thank you for replay. No I have version CMSIS-SP-00300-r4p3-00rel0 and it was working perfectly.
Regards
Franz

Hello Franz,

Thanks for the update. Also we must note that if ARM changes anything major in the next release(s) the Application Note Shall be updated at the earliest.

Regards
Amit

Hi Amit,

I think we are still having problems, not on the library side, but on the application side... the predefined symbol "_LINKAGE" effectively bypassed the "linkage.h" header file, although "_CODE_ACCESS" and "_DATA_ACCESS" are taken care of in the same predefined symbol section, "_IDECL" still cause errors while compiling some standard c library headers, such as ctime, stdlib, etc. in release built (C++ project).

Should I apply more patches? Is there a more permanent solution?

Thanks!

Hello Graviton,

At this point we do not have any additional patches. The ARM CMSIS requires the pre defined list of examples to be run as a qualifier which do work. Any further application code needs to be implemented by the user. This is the unfortunate nature of CCS changing.

Regards
Amit

Hi Amit,

Thanks for the immediate reply! It is indeed unfortunate that CMSIS DSP lib doesn't play along with TI ARM compiler, or vice versa. One work around tends to disturb more code, that's the ripple effect in real life, more substantial applications. I can try the GCC ARM compiler, but I am also using TI-RTOS and TivaWare, so I could open a bigger can of warm if I chose that route... that being said, has anyone compiled TI libraries with GCC?

Thanks again!

Hello Graviton,

As I see in the CCS v6.1.0, the GNUC option is being deprecated. More info can be received if the post is taken to the Code Composer Forum on the product road map for compilers/

Regards
Amit

Hi Amit,

After I (unwillingly) added the _IDECL and _IDEFN patch in the Predefined symbol list, the project compiled. But the generated code won't fit in the target chips Flash! I am using FFT function and the target processor TM4C123. Before the upgrade, the project only consumed a little more than 128KB of the total 256KB, now the image won't fit!

To figured out why and make sure it is not something stupid I did during the CCS/DSP lib upgrade, I loaded the "arm_fft_bin_example_f32.c" sample code, and followed your app note EXACTLY to build this sample, the project built OK, but when I looked the map file, I noticed the entire common table was brought into the .const section!

////////////////////////////////////////////////////////////

SECTION ALLOCATION MAP

output attributes/

section page origin length input sections

-------- ---- ---------- ---------- ----------------

.intvecs 0 00000000 00000208

00000000 00000208 tm4c1294ncpdt_startup_ccs.obj (.intvecs)

.const 0 00000208 0002b370

00000208 00008000 DSPLib-CM4F.lib : arm_common_tables.obj (.const:twiddleCoef_4096)

00008208 00006000 : arm_common_tables.obj (.const:twiddleCoef_4096_q31)

0000e208 00004000 : arm_common_tables.obj (.const:twiddleCoef_2048)

00012208 00003000 : arm_common_tables.obj (.const:twiddleCoef_2048_q31)

00015208 00003000 : arm_common_tables.obj (.const:twiddleCoef_4096_q15)

00018208 00002000 : arm_common_tables.obj (.const:twiddleCoef_1024)

0001a208 00001f80 : arm_common_tables.obj (.const:armBitRevIndexTable4096)

0001c188 00001f80 : arm_common_tables.obj (.const:armBitRevIndexTable_fixed_4096)

0001e108 00001dc0 : arm_common_tables.obj (.const:armBitRevIndexTable2048)

0001fec8 00001800 : arm_common_tables.obj (.const:twiddleCoef_1024_q31)

000216c8 00001800 : arm_common_tables.obj (.const:twiddleCoef_2048_q15)

00022ec8 00001000 : arm_common_tables.obj (.const:twiddleCoef_512)

00023ec8 00000f80 : arm_common_tables.obj (.const:armBitRevIndexTable_fixed_2048)

00024e48 00000e10 : arm_common_tables.obj (.const:armBitRevIndexTable1024)

00025c58 00000c00 : arm_common_tables.obj (.const:twiddleCoef_1024_q15)

00026858 00000c00 : arm_common_tables.obj (.const:twiddleCoef_512_q31)

00027458 00000800 : arm_common_tables.obj (.const:twiddleCoef_256)

00027c58 000007c0 : arm_common_tables.obj (.const:armBitRevIndexTable_fixed_1024)

00028418 00000600 : arm_common_tables.obj (.const:twiddleCoef_256_q31)

00028a18 00000600 : arm_common_tables.obj (.const:twiddleCoef_512_q15)

00029018 00000400 : arm_common_tables.obj (.const:twiddleCoef_128)

00029418 000003c0 : arm_common_tables.obj (.const:armBitRevIndexTable_fixed_512)

000297d8 00000380 : arm_common_tables.obj (.const:armBitRevIndexTable512)

00029b58 00000370 : arm_common_tables.obj (.const:armBitRevIndexTable256)

00029ec8 00000300 : arm_common_tables.obj (.const:twiddleCoef_128_q31)

0002a1c8 00000300 : arm_common_tables.obj (.const:twiddleCoef_256_q15)

0002a4c8 00000200 : arm_common_tables.obj (.const:twiddleCoef_64)

0002a6c8 000001e0 : arm_common_tables.obj (.const:armBitRevIndexTable_fixed_256)

0002a8a8 000001b0 : arm_const_structs.obj (.const)

0002aa58 000001a0 : arm_common_tables.obj (.const:armBitRevIndexTable128)

0002abf8 00000180 : arm_common_tables.obj (.const:twiddleCoef_128_q15)

0002ad78 00000180 : arm_common_tables.obj (.const:twiddleCoef_64_q31)

0002aef8 00000100 : arm_common_tables.obj (.const:twiddleCoef_32)

0002aff8 000000e0 : arm_common_tables.obj (.const:armBitRevIndexTable_fixed_128)

0002b0d8 000000c0 : arm_common_tables.obj (.const:twiddleCoef_32_q31)

0002b198 000000c0 : arm_common_tables.obj (.const:twiddleCoef_64_q15)

0002b258 00000080 : arm_common_tables.obj (.const:twiddleCoef_16)

0002b2d8 00000070 : arm_common_tables.obj (.const:armBitRevIndexTable64)

0002b348 00000070 : arm_common_tables.obj (.const:armBitRevIndexTable_fixed_64)

0002b3b8 00000060 : arm_common_tables.obj (.const:armBitRevIndexTable32)

0002b418 00000060 : arm_common_tables.obj (.const:twiddleCoef_16_q31)

0002b478 00000060 : arm_common_tables.obj (.const:twiddleCoef_32_q15)

0002b4d8 00000030 : arm_common_tables.obj (.const:armBitRevIndexTable_fixed_32)

0002b508 00000030 : arm_common_tables.obj (.const:twiddleCoef_16_q15)

0002b538 00000028 : arm_common_tables.obj (.const:armBitRevIndexTable16)

0002b560 00000018 : arm_common_tables.obj (.const)

....

//////////////////////

It used to just link the table being referenced before the upgrade, in this example, would only be "arm_common_tables.obj (.const:twiddleCoef_1024)", etc. and that was the way it supposed to be. Linking entire common tables into the image can't be right, hope you can reproduce the problem and there is a way to fix it.

Thanks,

Hello Graviton,

Since I do not have the exact set of options (both in driverlib generation and the project), I would suggest checking the following option in the project properties

ARM Linker -> Advanced Options -> Linktime Optimization -> Eliminate Sections not needed in executable (--unused_section_elimination) to ON

And then check if the size of the executable comes done. Otherwise in steps 1-2-3 if you can guide me through the list of changes you have w.r.t. to the Application Note, it would be easier for me to reproducing the issue. (You may add comments to the Application note and attach the document to the post). Do make sure that you have specified the CCS version, ARM Compiler Version and CMSIS version as per the application note to remove any uncertainty.

Regards
Amit

Hi Amit,

Thanks for the reply, in the arm_fft_example_f32.c example, I am not using driverlib, ti-rtos, tivaware, I just started the empty dsplib-cm4f project, followed every single step to build the library and then started a clean empty project, added the arm_fft_example_f32.c and arm_fft_data.c files to the project, changed the compile options according to your app note, and still got the same result, the entire common tables are linked into the output image. I checked that "ARM Linker -> Advanced Options -> Linktime Optimization -> Eliminate Sections not needed in executable (--unused_section_elimination)" is set to ON, although I believe it should be on by default. This is really strange... BTW, I am using compiler version 5.24. Could you confirm this is an issue? I really hope it was something stupid I did...

Thanks!

Hello Graviton,

I am able to reproduce the issue as well. However a google search of the same indicates that this is due to CMSIS version 4.00 onwards and users are bypassing it by using 3.2 version

mcuoneclipse.com/.../tutorial-using-the-arm-cmsis-library

Search for the text "4.00" on this post.

Regards
Amit

Hi Amit,

Thanks you for confirming the issue, embedded developers need sanity check from time to time! Knowing the problem is not cause by my stupid mistake can save me a lot time. Guess I will stick with the compiler version 5.18 and CMSIS 3.2 for now.

Thanks again!

Hello Graviton,

Apologies for not being able to check the same. But I will try to post an update if the latest compiler version can work with the same memory footprint. It would be a good exercise going forward for developers

Regards
Amit