• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 82 subscribers
  • Views 1554 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.

TMS320F28379D: Blocked data vs Non-blocked data warning

Ed Sanders
Genius 4085 points
Part Number: TMS320F28379D


Greetings,

I am bring some older code up-to-date with CCS10 and compiler version 20..2.5.LTS.  It builds, but produces a warning which says the following:

warning: Symbol, "<variable name>", referenced in "<FileName1>.obj", assumes that data is blocked but is accessing non-blocked data in "<path/FileName2>.obj". Runtime failures may result.

What does it mean by blocked vs non-blocked data?

Thank you,

Ed

  • 0
    TI__Guru**** 251300 points

    Please see this forum thread.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Genius 4085 points

    Hi George,

    Some more information.  Using CCS10, I am re-building some old code which was originally built using CCS8, and does not use the CLA as the articles suggest.  Is there another way to generate this?

    Thank you,

    Ed

  • 0 in reply to Ed Sanders
    TI__Guru**** 251300 points
    Ed Sanders said:
    Is there another way to generate this?

    It can occur any time there is assembly code (which may be generated by the compiler) similar to ...

            MOV       AL,@$BLOCKED(_symbol)

    ... and the definition of the memory associated with that symbol is not blocked.  Typically, the symbol is defined in CLA code.  But it could also be defined in hand-coded assembly.  

    Ed Sanders said:
    but is accessing non-blocked data in "<path/FileName2>.obj

    Is the source code which generates FileName2.obj a hand-coded assembly file?

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Genius 4085 points

    Hi George,

     

    Filename1 is written in cpp, and Filename2 is written in assembly where the variable in question is declared as follows:

     

    MY_STRUCT       .cstruct

    Var1                       .ulong

    Var2                       .ulong

    MY_STRUCT_len              .endstruct

     

    <_variable_name> .tag MY_STRUCT

    <_variable_name> .usect "MyTag", MY_STRUCT_len

     

    In the cmd file, MyTag is in the SECTIONS area within a UNION as follows:

    MEMORY

    {

                    PAGE 1:

                                    MySpace : origin = <start_address>, lenght = <size>

    }

     

    SECTIONS

    {

                    UNION : > MySpace, PAGE = 1

                    {

                    MyTag

                    AnotherTag

                    }

    }

     

    Thank you,

    Ed

  • +1 in reply to Ed Sanders
    TI__Guru**** 251300 points

    Because of this line ...

    Ed Sanders said:
    <_variable_name> .usect "MyTag", MY_STRUCT_len

    ... the error diagnostic is correct.  That variable is not blocked, but the code generated by the compiler assumes it is blocked.  

    There are two ways to fix it.

    1. Block the data
    2. Tell the compiler the data is not blocked

    To block the data, add ,1 to the end of the .usect directive.

    <_variable_name> .usect "MyTag", MY_STRUCT_len, 1

    For further details, please search the C28x assembly tools manual for the sub-chapter titled Uninitialized Sections.

    To tell the compiler the data is not blocked, use the variable attribute noblocked.  Here is an example ...

    __attribute__((noblocked))
extern struct sss global_struct;

    For further details, please search the C28x compiler manual for the sub-chapter titled Data Page (DP) Pointer Load Optimization.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Genius 4085 points

    Good references.  That worked.  Thank you George,

    Ed