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/TMS320C6713B: Bit Field overwrite complete register

Part Number: TMS320C6713B

Tool/software: TI C/C++ Compiler

Hi,

I am working on tms320c6713 PLL. instead of ORing and ANDing each bit in PLL registers, I wrote bit fields for each PLL register like:

struct PLL_XYZ_REG {

      unsigned int w:5;

      unsigned int x:1;

      unsigned int y:10;

      unsigned int z:16;

}


I have written a linker script to map these structures to appropriate memory locations and verified each register memory location using CCS watch window.

Now when i write something like;

struct PLL_XYZ_REG PLL;

PLL.w = 0x5;

PLL.x = 1;

Now the  PLL.x = 1; bit field assignment overrides the whole register!!!!!! How exactly is that possible???? Kindly help.

Regards,

  • A bitfield is a *size* not a location. w is 5 bits wide. You probably want to make them unsigned too. There is no guarantee as to the placement of the bitfield in the int.

  • I can shed some light.  Though I cannot answer everything.

    You don't share a complete test case I can compile.  But based on what you do show, it is likely that this line ...

    aimal khan said:
    PLL.x = 1;

    ... results in generated assembly similar to ...

               MVKL    .S1     _PLL,A3
               MVKH    .S1     _PLL,A3
               LDBU    .D1T1   *A3,A4            ; |14| 
               NOP             4
               SET     .S1     A4,5,5,A4         ; |14| 
    
               STB     .D1T1   A4,*A3            ; |14| 
    

    Note the load-byte and store-byte instructions used to access the PLL memory location.  I don't know the correct way to change a bit in the PLL.  But perhaps this isn't it.

    Thanks and regards,

    -George

  • Thanks George for your reply.

    Other registers configured this way functions properly. only PLL registers (DIV0-3 and OSCDIV0) behave this way. Strange.