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.

CCS/EK-TM4C1294XL: Cannot build my first assembly project

Part Number: EK-TM4C1294XL


Tool/software: Code Composer Studio

Hi!

I am very new to the EK-TM4C1294XL development kit and I wanted to write my first assembly project for it.

I followed this tutorial to make a Code Composer Studio project

_main:
	ADD R1, R2


Here is my code I tried to build. Once I build I get the following error

**** Build of configuration Debug for project HelloAssembly ****

/opt/ccstudio/ccsv8/utils/bin/gmake -k -j 4 all -O 
 
Building target: "HelloAssembly.out"
Invoking: ARM Linker
"/opt/ccstudio/ccsv8/tools/compiler/ti-cgt-arm_18.1.1.LTS/bin/armcl" -mv7M4 --code_state=16 --float_support=FPv4SPD16 -me --define=ccs="ccs" --define=PART_TM4C1294NCPDT -g --gcc --diag_warning=225 --diag_wrap=off --display_error_number --abi=eabi -z -m"HelloAssembly.map" --heap_size=0 --stack_size=0 -i"/opt/ccstudio/ccsv8/tools/compiler/ti-cgt-arm_18.1.1.LTS/lib" -i"/opt/ccstudio/ccsv8/tools/compiler/ti-cgt-arm_18.1.1.LTS/include" --reread_libs --diag_wrap=off --display_error_number --warn_sections --xml_link_info="HelloAssembly_linkInfo.xml" -o "HelloAssembly.out" "./program.obj" "./tm4c1294ncpdt_startup_ccs.obj" "../tm4c1294ncpdt.cmd"  -llibc.a 
<Linking>
 
 undefined first referenced                                                                                               
  symbol       in file                                                                                                    
 --------- ----------------                                                                                               
 main      /opt/ccstudio/ccsv8/tools/compiler/ti-cgt-arm_18.1.1.LTS/lib/rtsv7M4_T_le_v4SPD16_eabi.lib<boot_cortex_m.c.obj>
 
error #10234-D: unresolved symbols remain
error #10010: errors encountered during linking; "HelloAssembly.out" not built
 
>> Compilation failure
gmake[1]: *** [HelloAssembly.out] Error 1
makefile:140: recipe for target 'HelloAssembly.out' failed
gmake: *** [all] Error 2
makefile:136: recipe for target 'all' failed

**** Build Finished ****

Could anyone point me to the right direction where it goes wrong?

Assembly is a hard thing and the resources for Code Composer Studio are very limited, sadly.

  • Hello Jan,

    We do not support Assembly only projects for TM4C. Please download TivaWare and use our TivaWare driverlib if you wish to receive support for your application.

    While not directly called out along side with DRM coding, this request is in line with our official forum guidelines point #4: e2e.ti.com/.../695568
  • So if one wants to program at assembly level he/she needs to use another IDE?
  • Hello Jan,

    It has nothing to do with the IDE. It is simply that as the support team for TM4C MCU's, we will not support assembly code for our MCU.
  • Well, how would you explain  this post talking about writing assembly for the TM4C MCU? He is using Keil and it seems possible?

  • Hello Jan,

    That link doesn't work.
  • My bad,      should work.

  • If I may - as a 'long-time here' Outsider - note that 'both sides' - make Valid Points!

    While I 'Feel the Pain' suffered by the,  'Poster drawn to ASM'  - so too do I, 'Feel for this Vendor.'    

    Understand that neither my firm nor I - have a 'Dog in this Fight.'     (although several dogs - and 'different' fights - rage on - here!) 

    Our poster must (try) to understand & accept - that,  'while the desire to deploy & experiment w/ASM runs high (for him)'  - that desire & objective is FAR from universal!    'C code'  - most convincingly - over-whelms mention of ASM/other - surely here (and at most all other ARM MCU sites!)    As a general ARM Tech Consultant Firm (and focused manufacturer) - employing ARM MCUs from FOUR Different ARM Vendors - we know this to be true!

    This forum is - imho - the 'best' in providing skilled & on-going Tech Support.    (note that I contribute on other ARM forums - as well - yet always under different 'ID' - so that we can 'best track' - the source of Tech Contacts.)     How then - does such firm - 'Climb to the Top of the Mount?'     Clearly there must be FOCUS - and that must involve, 'Satisfying the greatest number of client-users - by addressing their 'predominate concerns.'      Highly skilled/trained & dedicated vendor agents perform the 'endless' task - of  'Resolving user issues & questions.'    Vendor agent 'numbers are limited' - thus it is natural - that 'To Best Serve the Masses' - some 'Limits must be emplaced & enforced.'     Our poster may ask - what would result if this forum received an 'Abundance of ASM requests?'     Quite predictably - the majority of  forum users (content w/'C') would be negatively impacted.      The 'Greatest Good' ... for the 'Greatest Number' - seems a most 'reasonable' objective - to me!

    Note too - that modern C Compilers - have vastly reduced the advantages of  'ASM' over 'C.'    Thus - the deployment of 'ASM' must be limited - to those instances where 'execution time' and minimal memory footprint - prove especially critical.    Should 'ASM' be used more expansively - then the time for code development, testing & completion - has been demonstrated  to increase (at minimum) by an 'order of magnitude!'     And the 'profits available' for 'early entry' to a 'hot market' - are sacrificed.     Thus - yet 'another nail' - has helped seal - the 'ASM coffin.'

    If - despite the above - ASM remains of interest - I would suggest the move to one of the 'PRO IDEs' (such as IAR - or Keil - as poster mentioned).    These have arrived long before this vendor's IDE - accept most ALL ARM MCUs - and in my firm's (and many of our clients') opinion - proves well superior to (any) single vendor, IDE offering.

    W/in (even) the 'free' (i.e. Kickstarter version) of IAR (for ARM) - there appear code guidance & examples - targeting ASM.    Further - books are available - if not directly focused upon ASM - then providing numerous examples - and 'making the case' - for 'when/where' ASM is best deployed.    I've (many times) noted:  Joseph Yiu's book,  'The definitive guide to the ARM CORTEX M3/M4 - which provides a solid foundation.    (both for general ARM MCU exploitation/understanding - as well as the "Use of ASM."

    Both parties here 'have registered their points' - I've attempted to, 'Bridge any gaps.'       (maybe)

  • Hello Jan,

    It's not a matter of it being possible or not. I am not saying you cannot code in assembly.

    I am saying that our stance from TI Applications is we will not support/help with assembly writing. You can do it. Use Google, learn about ARM assembly, etc. but we will not support it as it is outside of the scope of what we will help with on E2E.
  • The problem is that IAR and Keil are both not supported for the GNU/Linux OS. I can use mono and wine but I do not allow any of these software on my OS.
  • And - of course - none of these 'NEW RESTRICTIONS' (non support by GNU/Linux OS) received mention - earlier.
    Cannot you - at least temporarily - employ a 'PC' and 'IAR or Keil' - and  via  code study and exercise - 'Answer many of your ASM-bound questions' - in that manner?     After that - and (then) armed w/some success - you may revert to your (very unique) system & constraints.

    Under (either) of those 'far more established (and more powerful - imho) IDEs' - and several glances @ Joseph Yiu's fine book - you should be able to 'tease out' further insights - which may lead to your (quickest/easiest) success w/ASM.

    Might you reveal - in light of my earlier (detailed) writing (strictly in your behalf) - why you, 'SO Prize' - (Use and only Use) of ASM?     It proves difficult to maintain motivation - when such crucial facts - remain (glaringly) unexplained/absent!

  • In the embedded scene it is normal to write assembly for very specific applications or where one must know exactly what runs and what will happen in specific cases (and get the worst execution time eg system ticks).

    This can be achieved by fully inspecting the compiler generated assembly code, but is not always what meets requirements.
  • Thank you for describing 'what is normal' w/in the embedded scene.     Having past co-founded - then taken a Tech Firm PUBLIC - I just may have such knowledge.   (and it deviates from 'your view.')     You may note that my earlier writing detailed the (proper)  'time/place for ASM' - yet such ASM use 'pales'  - when contrasted against the vastly more efficient 'C.'

    Overuse of ASM - especially when such powerful 'C Compilers abound' - has been 'proven' to 'retard' project development - thus KILLING any chance for 'early arrival to a 'hot market!'     Such timely arrival - SO desired by Tech Biz Owners/Investors - as it  enables 'capture' of the,  'short - yet highest profitability  window' - and chance for (even a small firm) to 'take hold!'   (thus sustain!)    That's critical - don't you agree?

    Wish you well - any Venture Capital firm well notes that, 'An acceptably crafted product - arriving EARLY - far exceeds 'exactly crafted' - arriving (necessarily) LATE!'     And clearly - GIANT tech Firms (i.e.  this vendor) fully agree!    (thus focus their efforts - rightfully - upon 'C!')