• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 53 subscribers
  • Views 1776 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Three MSP430 Assembler Quirks With CCS5.2

Curt Carpenter
Expert 1255 points

Other Parts Discussed in Thread: MSP430G2211

o  Using CCS5.2 to assemble a program, you may get a message in the  "Problems" window that says ""[E0300] The following symbols are undefined:"   The message is not followed by a list of the undefined symbols however.  To get the list, you need to look in the "CDT Build Console" window.   No information is given as to where in the program source the undefined symbols appear, however.

o   In an absolute listing, the addresses that may be contained in a header file (eg. "msp430g2211.h") aren't resolved to absolute addresses, although they are resolved if you run Debug.

o   All of the example programs for use with the assembler under CCS contain the line    " .cdecls C,LIST,  "msp430g2211.h" .  However, as far as I can see this statement always generates an error   WARNING! at line 12: [E1000] error while processing C code in .cdecls directive."   

o  It seems odd to me that all of the "jump" instructions in the MSP430 assembler syntax can target a label (eg. JMP  MAIN   or JZ  MAIN), while the CALL instruction needs a "#" (eg. CALL #MAIN is correct per the docs, not CALL MAIN).

Most of these quirks may reflect my unfamiliarity with the MSP430 assembler and CCS5.2 set-up options for it, but I thought I would pass them along for information.  None of them is without a work-around.

  • 0
    TI__Guru**** 173310 points

    Curt Carpenter said:
    Using CCS5.2 to assemble a program, you may get a message in the  "Problems" window that says ""[E0300] The following symbols are undefined:"   The message is not followed by a list of the undefined symbols however. 

    This behavior seems quite inconsistent. Sometimes I see the Problems view showing the symbol name and sometimes it does not. I will file a bug for this so it gets looked into.

    Curt Carpenter said:
    In an absolute listing, the addresses that may be contained in a header file (eg. "msp430g2211.h") aren't resolved to absolute addresses, although they are resolved if you run Debug.

    All of the example programs for use with the assembler under CCS contain the line    " .cdecls C,LIST,  "msp430g2211.h" .  However, as far as I can see this statement always generates an error   WARNING! at line 12: [E1000] error while processing C code in .cdecls directive."   

    I think these are limitations in the absolute lister. I can file a enhancement request for these but I cannot tell with what priority they will be addressed.

    Curt Carpenter said:
    It seems odd to me that all of the "jump" instructions in the MSP430 assembler syntax can target a label (eg. JMP  MAIN   or JZ  MAIN), while the CALL instruction needs a "#" (eg. CALL #MAIN is correct per the docs, not CALL MAIN).

    This is really determined by the MPS430 instruction set defined by the processor.

  • 0 in reply to AartiG
    Expert 1255 points

    You're absolutely right about the issues I noted with the unresolved absolute addresses in my absolute listings and the ."error while processing C code in .cdecls directive"  message.  Both issues are due to the fact that I failed to include a --include_path option switch in my post-build assembly step.

    So these things too are down to my not knowing what I'm doing -- not problems in the assembler.   All straightened out now though!  Thanks again!