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.

Compiler: Embedding Assembly Code in Code Composer Studio for Tiva™ TM4C1294NCPDT

Other Parts Discussed in Thread: TM4C129ENCPDT

Tool/software: TI C/C++ Compiler

Hi all,

I am trying to solve this issue relating to the use of assembly code in a C program with code composer studio.  The code compile well but in debugging, the execution generates a fault (certainly incorrect instruction ode).  For instance the following will generate faults:

__asm(" STMFD R0!, {R4}");


__asm(
//Recall the values the R4-R11 and SP_process stored in the state buffer
" LDMIA R0!,{R4-R11,R12}\n\t" //Store Values
" MSR PSP, R12\n\t" //Move contents of R1 to PSP
//Return from restore task using process stack
);

Hence the function below will also generate a fault. 

void createTask(unsigned *buf, char *stack, task_t task_start, task_t taskFinish)
{

// This line stores space for register R4-R11 and SP into
// threads[currThread].savedregs, which is the buffer to hold the state
// of the processor which is not saved automatically during a function
// boundary. The series of instruction stores a zero value for each of the
// registers except SP which is the value of the input pointer stack
__asm(" MOV R4, #0");
__asm(" STMFD R0!, {R4}"); //R4
__asm(" STMFD R0!, {R4}"); //R5
__asm(" STMFD R0!, {R4}"); //R6
__asm(" STMFD R0!, {R4}"); //R7
__asm(" STMFD R0!, {R4}"); //R8
__asm(" STMFD R0!, {R4}"); //R9
__asm(" STMFD R0!, {R4}"); //R10
__asm(" STMFD R0!, {R4}"); //R11


// Put space for all of the register onto the process stack
// for when the task returns (calls yeild). Space for registers
// R0-R3, R12, ReturnAddress (taskFinish), and xPSR.
__asm(" MOV R5, R2"); // getting the address of task_start
__asm(" MOV R6, R3"); // getting the address of taskFinish
__asm(" MOV R3, #0x1000000"); //Change R3 to xPSR value
__asm(" STMFD R1!, {R3}"); //xPSR
__asm(" STMFD R1!, {R5}"); //Return Address
__asm(" STMFD R1!, {R6}"); //R14
__asm(" STMFD R1!, {R4}"); //R12
__asm(" STMFD R1!, {R4}"); //R3
__asm(" STMFD R1!, {R4}"); //R2
__asm(" STMFD R1!, {R4}"); //R1
__asm(" STMFD R1!, {R4}"); //R0

//Store R1 into the SP spot in the savedregs buffer
__asm(" STMFD R0!, {R1}");

__asm(" MOV R4, #0");
__asm(" STMFD R0!, {R5}"); //R5
__asm(" STMFD R0!, {R6}"); //R6

*/


}

Is there anything settings or coding principles to follow?  I have followed the recommendations made in 

ARM Optimizing C/C++ Compiler
v17.3.0.STS
User's Guide.

Thanks for helping.

  • A function that is nothing but __asm statements should be written in hand-coded assembly.  __asm statements are intended for inserting one instruction (or directive) that is impossible or difficult to generate from C or C++.  

    If your question is more about why these particular instructions do not work in your circumstances ... It appears you are implementing some sort of runtime operating system.  We who watch this compiler forum lack the expertise needed to be helpful on this topic.

    Thanks and regards,

    -George

  • Dear George,

    Yes indeed my question is why the TI compiler is generating non-defined instruction binary codes that lead to faults in execution, even though instructions such as LDMFD and LDMIA are part of the instruction set (Table 2-13. Cortex-M4F Instruction Summary, Tiva™ TM4C129ENCPDT Microcontroller
    DATA SHEET), when they are used in a C/C++ program.

    Thanks,

    Lucien
  • When I compile your C function with TI ARM compiler version 17.3.0.STS, with option --silicon_version=7M4, I do not get any undefined instructions.   I get the following disassembly.  Please check the disassembly of createTask in the debugger before execution has started.  Do you see invalid instructions in the disassembler window?  Could you please post a screen shot of those invalid instructions?

    TEXT Section .text, 0x5E bytes at 0x0
    000000:              createTask:
    000000:               .thumb
    000000: F04F0400         MOV.W           R4, #0
    000004: F8404D04         STR.W           R4, [R0, #-4]!
    000008: F8404D04         STR.W           R4, [R0, #-4]!
    00000c: F8404D04         STR.W           R4, [R0, #-4]!
    000010: F8404D04         STR.W           R4, [R0, #-4]!
    000014: F8404D04         STR.W           R4, [R0, #-4]!
    000018: F8404D04         STR.W           R4, [R0, #-4]!
    00001c: F8404D04         STR.W           R4, [R0, #-4]!
    000020: F8404D04         STR.W           R4, [R0, #-4]!
    000024: 4615             MOV             R5, R2
    000026: 461E             MOV             R6, R3
    000028: F04F7380         MOV.W           R3, #16777216
    00002c: F8413D04         STR.W           R3, [R1, #-4]!
    000030: F8415D04         STR.W           R5, [R1, #-4]!
    000034: F8416D04         STR.W           R6, [R1, #-4]!
    000038: F8414D04         STR.W           R4, [R1, #-4]!
    00003c: F8414D04         STR.W           R4, [R1, #-4]!
    000040: F8414D04         STR.W           R4, [R1, #-4]!
    000044: F8414D04         STR.W           R4, [R1, #-4]!
    000048: F8414D04         STR.W           R4, [R1, #-4]!
    00004c: F8401D04         STR.W           R1, [R0, #-4]!
    000050: F04F0400         MOV.W           R4, #0
    000054: F8405D04         STR.W           R5, [R0, #-4]!
    000058: F8406D04         STR.W           R6, [R0, #-4]!
    00005c: 4770             BX              R14
    
  • I will install CCSV7 to recompile and post my findings.

    Thanks

  • If you don't have CCS installed, you can use the stand-alone disassembler "armdis"
  • I am generating with CS V7 the same code as shown below but when debugging step by step the execution generates a fault. 

    createTask():
    00000374: F04F0400 mov.w r4, #0
    00000378: F8404D04 str r4, [r0, #-0x4]!
    0000037c: F8404D04 str r4, [r0, #-0x4]!
    00000380: F8404D04 str r4, [r0, #-0x4]!
    00000384: F8404D04 str r4, [r0, #-0x4]!
    00000388: F8404D04 str r4, [r0, #-0x4]!
    0000038c: F8404D04 str r4, [r0, #-0x4]!
    00000390: F8404D04 str r4, [r0, #-0x4]!
    00000394: F8404D04 str r4, [r0, #-0x4]!
    00000398: 4615 mov r5, r2
    0000039a: 461E mov r6, r3
    0000039c: F04F7380 mov.w r3, #0x1000000
    000003a0: F8413D04 str r3, [r1, #-0x4]!
    000003a4: F8415D04 str r5, [r1, #-0x4]!
    000003a8: F8416D04 str r6, [r1, #-0x4]!
    000003ac: F8414D04 str r4, [r1, #-0x4]!
    000003b0: F8414D04 str r4, [r1, #-0x4]!
    000003b4: F8414D04 str r4, [r1, #-0x4]!
    000003b8: F8414D04 str r4, [r1, #-0x4]!
    000003bc: F8414D04 str r4, [r1, #-0x4]!
    000003c0: F8401D04 str r1, [r0, #-0x4]!
    000003c4: F04F0400 mov.w r4, #0
    000003c8: F8405D04 str r5, [r0, #-0x4]!
    000003cc: F8406D04 str r6, [r0, #-0x4]!
    000003d0: 4770 bx lr

  • What is the PC when the fault occurs? Which fault is it?
    It may be that one of R0 or R1 points to an invalid address. Perhaps the sequence of writes runs off the end of memory?