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/TMS320F28377S: Advice for compiler workaround

Genius 5910 points

Part Number: TMS320F28377S

Tool/software: Code Composer Studio

I got an issue with optimization of the compiler:

   mem                 =   (SBLOCK_t *)((memblocks->memoryAddress + memblocks->size)); 
   mem->memoryAddress = 10;

The problem is mem->memoryAddress(uint32_t) is not allocated.  When it is uint16_t is works fine.

After hours disassemble I think I found the problem:

The compiler is re arranging this line of code. The problem with that is that mem->memoryAddress is unknown before mem is allocated.

So How do I prevent this from happening? So how do I force the compiler to allocate mem before continue.

Thanks

  • I was thing I  can add NOP to prevent optimization, that's work really good. Only that didn't solve the problem:

    the line of code that give me problems:

    41        mem->memoryAddress  =  10;

    088b31:   D008        MOVB         XAR0, #0x8

    088b32:   020A        MOVB         ACC, #10

    088b33:   1E94        MOVL         *+XAR4[AR0], ACC

    088b34:   7700        NOP          

    Result of executing this code:

    mem->memoryAddress unsigned long 0x00000000 (Hex) 0x0000D4E7@Data

    XAR4 Register 0x0000D4DF Register XAR4

    XAR0 Register 0x00000008 Register XAR0  

    ACC Register 0x0000000A Register ACC

    Can some please help me with this instruction:  MOVL         *+XAR4[AR0], ACC

    I assume it is * (XAR4 + OR0) =(uint32_t) ACC => *(0xD4DF + 0x08) = 0x10 => *(0xD4E7) = 0x10

    Only the result at mem location 0xD4E7 is 0 when the breakpoint is at the nop location? So what is wrong?

    For for comparison this work fine:

    // changed form uint32_t uint16_t

     41        mem->memoryAddress  =  10;
    088b15:   56BF0AFC    MOVB         *+XAR4[7], #0x0a, UNC
    088b17:   7700        NOP       

  • The MOVL instruction (and any other instructions which access 32-bits of memory at once) presumes the address is even, and not an odd address like 0xD4E7. For this reason, the compiler aligns all 32-bit wide memory objects to an even address.

    When you write an expression like ...

     mem = (SBLOCK_t *)((memblocks->memoryAddress + memblocks->size));  

    ... it is your responsibility to insure the alignment requirements are met.  I suspect that is not the case for this assignment.

    Thanks and regards,

    -George

  • George,

    Thanks for the answer.  Why didn't I get an illegal address/instruction exception?

    Thanks,

    Evs

  • I'm pretty sure the CPU has no support for such an exception.  If you want to pursue that further, I suggest you start a new thread in the C2000 device forum.  Or, if you prefer, I can move this thread to that forum.

    Thanks and regards,

    -George

  • No, Only I'm really really surprised, that I can use a correct assembler instruction so the result is different as intended. And TI thinks that is perfectly fine. This is impossible to debug at C level. I don't think I solved it without your help.