• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 53 subscribers
  • Views 1989 views
  • Users 0 members are here
Support feedback
Options
Options

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/TMS320F28377S: C28x Compiler / Optimizer adressing error: page error if structure crosses page boundary

fmdhr
Expert 1530 points
Part Number: TMS320F28377S

Tool/software: TI C/C++ Compiler

Hi,

it took me half a day to discover the following issue: I try to initialise a structure that crosses an AMODE = 0 page using inline functions, -O2 set. The structure starts at 0x809c, the element I want to set is at 0x80c0 = page 203, offset 0. Compiler sets 0x8080 = page 202, offset 0 instead (red 5.0).

I hope the CCS screenshot gives you enough additional information.

A

#pragma DATA_ALIGN(pctf, 0x40);
/* position controller as transfer function */
tdf2tf      pctf;

provides a workaround.

Is this a known issue? If requested, I think I can build a test case for you.

Thanks,

Frank

  • 0
    TI__Guru**** 244840 points

    While I am not certain, that does appear to be a problem in the compiler.  To understand how it happened, I need a test case which lets me reproduce it.  For the source file duc_cla_init.c, please submit a test case as described in the article How to Submit a Compiler Test Case.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Expert 1530 points

    Hi George (again),

    I hope you have received the pp-file requested via mail.

    In the asm-file generated are the following interesting lines:

    885        MOVW      DP,#_pctf+34          ; [CPU_U]

    897
        .dwpsn    file "..\tdf2tfi.h",line 159,column 5,is_stmt,isa 0
            MOVL      @_pctf+34,ACC
    939
        .dwpsn    file "..\tdf2tfi.h",line 160,column 5,is_stmt,isa 0
            MOVL      @_pctf+36,XAR6        ; [CPU_] |160|

    Seems that I (un)fortunately catched the unlikely case, that the page border lies between the structure members ymin and ymax. Here again the generating C-function:

    static inline
    void
    tdf2tf_init_limits(struct tdf2tf *tf, float32_t ymin, float32_t ymax)
    {

        tf->ymin = ymin;
        tf->ymax = ymax;
    }

    The compiler accidentially assumes both in the same page, but actually, they are not.

    Please let me know if you need more information.

    Thanks & regards,

    Frank

  • 0 in reply to fmdhr
    TI__Guru**** 244840 points

    Your analysis looks correct.  Unfortunately, you forgot to give me the compiler build options.  Please copy-n-paste that from the Console view in CCS.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Expert 1530 points

    Hi George,

    the original build options can be seen in the screenshot in my first post, I had adjusted the console view accordingly.

    Sorry, I did not post them for the .pp - file. Here they are:

    **** Build of configuration debug_ram for project duc_firmware ****

    "C:\\ti\\ccsv7\\utils\\bin\\gmake" -k duc_cla_init.obj
    'Building file: ../duc_cla_init.c'
    'Invoking: C2000 Compiler'
    "C:/ti/ccsv7/tools/compiler/ti-cgt-c2000_16.9.1.LTS/bin/cl2000" -v28 -ml -mt --vcu_support=vcu2 --cla_support=cla1 --float_support=fpu32 --tmu_support=tmu0 -O2 --include_path="C:/ti/ccsv7/tools/compiler/ti-cgt-c2000_16.9.1.LTS/include" --include_path="J:/workspace/firmware/duc/device_support/f2837xs/common/include" --include_path="J:/workspace/firmware/duc/device_support/f2837xs/headers/include" --include_path="J:/workspace/firmware/duc/driverlib/f2837xs/driverlib/inc" -g --preproc_with_comment --preproc_with_compile --define=CPU1 --display_error_number --diag_warning=225 --diag_suppress=10063  "../duc_cla_init.c"
    "..\tdf2tfi.h", line 122 (col. 25): advice #2614-D: (Performance) Use --fp_mode=relaxed to enable TMU hardware support for FP division.
    'Finished building: ../duc_cla_init.c'
    ' '

    **** Build Finished ****

    Except the pp-options, I see no difference.

    Fine that you agree with my analysis so far.

    Thanks & regards,

    Frank

  • 0 in reply to fmdhr
    TI__Guru**** 244840 points

    Thank you for sending in the test case.  I can reproduce the problem assembly code.  Now that I understand everything better, I can see that it is a known issue.  You can look up SDSCM00050582 with the SDOWP link below in my signature.  The workaround is to define all data shared between CLA and C28x in the .c files, and not the .cla files

    This issue was reported quite some time ago.  I don't know why it has not been addressed.  I will look into that.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Expert 1530 points

    Hi George,


    I visited the SDSCM00050582 page you suggested. Unfortunately there is only a few information, the link
    e2e.ti.com/.../355250.aspx
    is broken.

    I assumed that I have to do something like

    #pragma DATA_SECTION(pctf,              ".bss_cla");
    struct xxxx      pctf;

    in a (e.g.) cla_data.c file and to use extern ... pctf etc. in the .cla file. I did this way, and the structures (and vectors) now are aligned to page boundaries, wasting some memory, here the entries in the .map-file:

    00008058     201 (00008040)     _cc_test_ampl
    00008080     202 (00008080)     _pctf
    000080c0     203 (000080c0)     _cctf
    00008100     204 (00008100)     _maf_state


    Assembler code appeared unchanged, program executes correctly (as it did with my #pragma DATA_ALIGN(pctf, 0x40); suggestion).
    To be sure, I did an additional check: I inserted a fill into the structure, so that the members ymin and ymax again are placed in different pages, and really, the compiler inserts an additional

            MOVW      DP,#_pctf+64          ; [CPU_U]


    Some additional questions:

    Since I set the preprocessor options for duc_cla_init.c as requested, it is marked with a little key in the project view. What does it mean and how to clear it ("restore default options" did not)?

    Are other compiler versions affected too? (No, I am not keen on compiler updates, just good to know.)

    I revisited F28377 TRM spruhx5e and Compiler manual spru514p, no hint concerning this issue, at least not at a prominent place. Will there be any in a future version?

    Thanks & regards

    Frank

    PS: I have to admire TI's optimistic view on its software: In SDSCM00050582, the severity is classified as 'minor'. Please consider a users view: He adds/changes some data anywhere in his program. This may shift other data across a page border, and without any warning at a totally other place in a formerly well running part of the software an error rises (in my case, the controller still worked, but only in one direction). One kind of error IMHO most difficult to find.
    What does TI consider to be a 'major' severity?

  • 0 in reply to fmdhr
    TI__Guru**** 244840 points

    fmdhr said:
    I assumed that I have to do something like

    #pragma DATA_SECTION(pctf,              ".bss_cla");
    struct xxxx      pctf;

    in a (e.g.) cla_data.c file and to use extern ... pctf etc. in the .cla file.

    That is correct.   Note, however, the pragma DATA_SECTION is optional.

    fmdhr said:
    the structures (and vectors) now are aligned to page boundaries, wasting some memory

    To understand that better, please see the article Data blocking in the C2000 MCU compiler explained.

    fmdhr said:
    Since I set the preprocessor options for duc_cla_init.c as requested, it is marked with a little key in the project view. What does it mean and how to clear it ("restore default options" did not)?

    Please see the File Specific Options part of the article on CCS Project Management and Build.

    fmdhr said:
    Are other compiler versions affected too? (No, I am not keen on compiler updates, just good to know.)

    Yes.  All C28x compilers have this limitation.

    fmdhr said:
    Please consider a users view: He adds/changes some data anywhere in his program. This may shift other data across a page border, and without any warning at a totally other place in a formerly well running part of the software an error rises (in my case, the controller still worked, but only in one direction). One kind of error IMHO most difficult to find.

    You make a valid point.  I made a similar point to the compiler development team.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Expert 1530 points

    George,

    thank you for your profound and thorough help. Just one remark:

    George Mock said:
    Note, however, the pragma DATA_SECTION is optional.

    No, I do not think so. Because I want to have this controller to be initialised by the CPU, but the sample steps to be executed by the CLA, I have to place the data into .bss_cla, not into .bss (the default section). Except the GNU style version of section placement I see no other way to do that.

    Thanks & regards,

    Frank