• State Resolved
  • Locked Locked
  • Replies 12 replies
  • Subscribers 54 subscribers
  • Views 1175 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Original question:

CCS build does not recognize "packed" keyword

Compiler: OMAP-L138 - packed attribute for structs - CCS with Ti ARM Compiler

koehmark
Prodigy 80 points
Other Parts Discussed in Thread: OMAPL138, OMAP-L138

Tool/software: TI C/C++ Compiler

Hello,

I have some structs in my project for which I need to use the "packed attribute" of TI ARM compiler.

Until now I did not find any solution or setting that works.

Here is my environment:

Processor: OMAPL138E

Code Composer Studio  Version: 5.1.1.00028

ARM Compiler Version: TI V4.9.1  (configured for variant "Genreic ARM9 device")

In this forum I already found some posts like this

https://e2e.ti.com/support/tools/ccs/f/81/p/38211/196004#196004

so I enabled "--unaligned_access=on", but there is still a compiler warning:

#1176-D the "packed" attribute is ignored in a typedef.

So my questions are:

  1. Does the toolchain (mentioned above) support the "packed attribute" for my Processor type (OMAPL138)?
  2. If yes, which additional compiler settings could be relevant for this?
  3. If not, is there a TI ARM Compiler version which does support this?

Thanks in advance for your support!

Best regards,

Markus

Here is an example ("packed" did not work - that means this struct is compiled with a 32Bit alignment):

typedef __attribute__ ((__packed__)) struct EPL_IRES_FRAME_Ttag
{
uint8_t bMtyp;
uint8_t bDest;
uint8_t bSrc;
uint8_t bSvid;
uint16_t usFlags;
uint8_t bNmtStatus;
uint8_t bReserved;
uint8_t bEplProfileVersion;
uint8_t bReserved2;
uint32_t ulFeatureFlags;
uint16_t usMTU;
uint16_t usPollInSize;
uint16_t usPollOutSize;
uint32_t ulResponseTime;
uint16_t usReserved3;
uint32_t ulDeviceType;
uint32_t ulVendorId;
uint32_t ulProductCode;
uint32_t ulRevisionNumber;
uint32_t ulSerialNumber;
uint32_t aulVendorExtension[2];
uint32_t ulVerifyConfigDate;
uint32_t ulVerifyConfigTime;
uint32_t ulApplicationSwDate;
uint32_t ulApplicationSwTime;
uint32_t ulIpAddress;
uint32_t ulSubnetMask;
uint32_t ulDefaultGateway;
uint8_t szHostName[32];
uint8_t abVendorExtension2[48];
} EPL_IRES_FRAME_T;

  • 0
    Prodigy 80 points

    Update:

    I have found this post

    e2e.ti.com/.../1800614 packed#1800614

    and inside a helpful tipp to move the attribute specifier:

    so with a moved attribute specifier

    typedef struct EPL_IRES_FRAME_Ttag
    {
    ...
    } __attribute__((__packed__)) EPL_IRES_FRAME_T;

    and compiler setting "--unaligned_access=on"

    I was able to compile this struct without warning.

    But now access to this struct wents wrong, because data is written to 32Bit adresses only.

    This means, that without the previously inserted padding words data is written to wrong struct elements now.

    So my remaining question is, if a newer version of the TI ARM compiler could solve this issue?

  • 0 in reply to koehmark
    TI__Guru**** 240215 points

    When this happens ...

    koehmark said:
    But now access to this struct wents wrong, because data is written to 32Bit adresses only.

    How can you tell that occurred?  Exactly what are you looking at?

    I am unable to reproduce the problem.  For the source file that defines this packed structure, please follow the directions in the article How to Submit a Compiler Test Case.

    ARM compiler version 4.9.1 is about 7.5 years old.  It is no longer supported.  It would be ideal if you upgraded both CCS and the compiler to the latest versions.  

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Prodigy 80 points

    Hello George,

    thanks for your reply. The project I am working on is a running application, which was started by colleagues about 2012. So the toolchain is really old, that's right, but to be honest an update was postponed due to stability reasons until now.

    So it is important to know, if a compiler update could help us in this situation, OR if the architechture of the ARM controller inside OMAP-L138 is not able to carry out non 32Bit accesses (even with a newer compiler version)?

    OK, let me explain a little bit more regarding your questions:

    The struct I inserted is part of a fieldbus stack and I am able to check the results of the compiler as well on the bus (fieldbus analyzer) as with a debugger on the ARM processor. So I can check the adresses of my struct elements and their content with the debugger.

    I could see, that first (without the packed attribute) padding words were inserted, what is a problem for all functions accessing this struct. That's why I wanted to use the "packed attribute".

    Now with the packed attribute I can see with my debugger, that the adresses of my struct elements are correct (no padding words are inserted), but data is written to wrong struct elements. As an example let us take a look at a part of the struct:

    ...
    uint16_t usFlags; // 32 Bits Block
    uint8_t bNmtStatus;
    uint8_t bReserved;

    uint8_t bEplProfileVersion; // 16 Bits Block
    uint8_t bReserved2;

    uint32_t ulFeatureFlags; // 32 Bits Block
    ...

    Without the packed attribute there was (due to the 32Bit alignment) a padding word inserted between "bReserved2" and "ulFeatureFlags". I could see this with my debugger because of the adresses of the struct elements (address gap of 2 Bytes between "bReserved2" and "ulFeatureFlags").

    A) Example content (OK) of the struct elements without "packed attribute" after write access to struct element "ulFeatureFlags":

    bEplProfileVersion == 0x00
    bReserved2 == 0x00
    "padding word"
    ulFeatureFlags == 0x12345678


    With the packed attribute, there is NO padding word inserted between "bReserved2" and "ulFeatureFlags" (thats what I wanted), but now I can see content (the lower 16 Bits) of "ulFeatureFlags" inside the struct element "bReserved2", after a write access to "ulFeatureFlags".

    B) Example content (NOT OK) of the struct elements with "packed attribute" after write access to struct element "ulFeatureFlags":

    bEplProfileVersion == 0x78
    bReserved2 == 0x56
    ulFeatureFlags == 0x00001234


    So it looks like, that write access is carried out at 32Bit adresses only!?

    I understand, that you can't test this without a compiler test case.

    My only question is, if a newer compiler could generate different code for the OMAP-L138, so that write access is not limited to 32Bit adresses?
    OR if the architechture of this processor is not able to do this, even with an actual compiler?

    Thanks in advance and best regards,
    Markus

  • 0 in reply to koehmark
    TI__Guru**** 240215 points

    An OMAP-L138 device has an ARM9 CPU on it.  The 32-bit wide load and store instructions on ARM9 do not support unaligned access.  (The ARM Cortex CPU's do support unaligned access.)  So, to support packed structures on ARM9, the compiler uses 8-bit wide load and store instructions to access the structure fields, regardless of the size of the field.  With regard to ...

    koehmark said:
    B) Example content (NOT OK) of the struct elements with "packed attribute" after write access to struct element "ulFeatureFlags":

    bEplProfileVersion == 0x78
    bReserved2 == 0x56
    ulFeatureFlags == 0x00001234

    When you run all the way through the function related to these fields, does everything work correctly?  If so, then this is not a problem with the compiler, but a problem in how CCS displays this structure.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Prodigy 80 points

    Hello George,

    thanks for your answer and explanations. I understand that with a correctly compiled source code, the read and write accesses to my struct should work with the "packed attribute" on the OMAP-L138 (ARM9 CPU).

    When I run all the way through the function, which is accessing my struct, it does NOT work correctly. I can see inside my ethernet frame exactly the content I saw with my debugger before. So it is unfortunately NO display problem inside the CCS. For me it looks like, that the "8-bit wide load and store instructions" don't take place or they don't work as expected. I don't know excatly what happens, but maybe there is a problem inside this old compiler version...

    As a workaround I started to change the source code (fieldbus stack) this way, that no "packed attributes" are necessary anymore. E.g. I divided the 32Bit variable "ulFeatureFlags" into an array of two 16Bit variables and so on... This way no padding bytes became necessary anymore without the "packed atrribute". It's not a nice solution, because I need to change all functions accessing the structs, too, but for this example it works without the "packed attribute". As well inside my debugger as on the bus the content seems to be OK.

    In a later (maintenance) step, we could check, if the "packed" behaviour ist different with a newer CCS and TI ARM compiler version. At the moment (due to the timeline of my project) I am not able to update and test everything for side effects.

    Thanks for your support and best regards,

    Markus

  • 0 in reply to George Mock
    Intellectual 529 points

    Hi George,

    a complete update of CCS is critical for us due to stability reasons. I would like to try updating the ARM Code Generation Tools only.

    The only source I can find is :http://www.ti.com/tool/arm-cgt

    Are the packets shown here intended to work with CCS 5.1? Is there another place where we can get older versions?

    Best regards

    Alexander

  • 0 in reply to George Mock
    Prodigy 80 points
    Hi George,

    some additional information regarding the question of Alexander:

    We already tried to update the ARM compiler via the integrated update function of CCS.
    But this went wrong, because we get a "signature problem" error message.
    It is excatly the same problem the following post is about:
    e2e.ti.com/.../1410751
    So it looks like, that we can't use the built-in update function of our old CCS V5.1.1.00028.

    That's why we would like to know, if the older compiler versions are available for download separately?
    AND which TI ARM Compiler Version would be the last one working with CCS 5.1?

    Thanks and best regards,
    Markus
  • 0 in reply to koehmark
    TI__Guru**** 240215 points

    koehmark said:
    we can't use the built-in update function of our old CCS V5.1.1.00028.

    Please try this method.  It shows how to download and install the compiler outside of CCS, then register it with CCS.  The screen shots are from a version of CCS more recent than CCS 5.1.  But I suspect they are close enough to be useful.

    koehmark said:
    which TI ARM Compiler Version would be the last one working with CCS 5.1?

    We do not keep track of that detail.  So, I cannot answer with precision.  CCS is tested with compilers that are recent as of the time of that release.  When newer compilers are released, they are not tested with older versions of CCS.  In practice, it usually works out with only minor problems, and often no problems.  However, the farther apart in time the releases, the more likely it is a problem will occur.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Prodigy 80 points

    Hi George,

    thanks for your answer and the informations. From your Compiler site
    http://software-dl.ti.com/codegen/non-esd/downloads/download.htm#ARM

    I downloaded the "ARM Code Generation Tools v5.2.9" (this is the oldest available toolchain but even much newer than our version 4.9.1).

    After download I installed them outside the CCS and then I did the steps described under
    http://software-dl.ti.com/ccs/esd/documents/ccs_compiler-installation-selection.html#outside-ccs
    to discover this compiler with CCS Version: 5.1.1.00028

    Unfortunately this compiler is not discovered by our old CCS version:

    As you can see in the picture, we already did these steps with a C6000 compiler v7.4.20 a few years before and this compiler was discovered correctly.

    Because with the ARM compiler tools v5.2.9 this did not work now, I did another test and downloaded / installed an actual CCS Version: 8.3.0.00009
    This new CCS version causes (as we already knew) trouble with our existing projects, but it is possible to access older TI ARM compilers (with CCS v8.3.0):

    As a test I downloaded and installed inside the new CCS v8.3 an ARM Compiler v4.9.9 (which is close to our v4.9.1).


    On your page: http://software-dl.ti.com/codegen/non-esd/downloads/download.htm#ARM
    the "oldest available compiler" is v5.2.9 but with the online update function of CCS I have access to older versions of the toolchain.
    E.g. the versions v4.9.9 / v5.0.11 / v5.1.14 are available ... and it would be interesting, if they work with CCS v5.1.1...

    Is there any possibility to get those old compiler packages for an installation outside the CCS?

    I would like to try, if versions below v5.2.9 and newer than v4.9.1 are discovered by our old CCS and if one of them could solve our problem.

    Thanks and best regards,

    Markus

  • 0 in reply to koehmark
    TI__Guru**** 240215 points

    With regard to ARM compiler version 5.2.9 you said ...

    koehmark said:
    Unfortunately this compiler is not discovered by our old CCS version

    Try clicking on Refresh.  Or restart CCS.  One of those will probably work.

    koehmark said:
    Is there any possibility to get those old compiler packages for an installation outside the CCS?

    Unfortunately, no.  However, once you have used the update feature built-in to CCSv8 to install a compiler, you can register that compiler with CCSv5.  

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Prodigy 80 points

    Hi George,

    thanks for your answer and hint. I already tried "Refresh and restart of CCS" after installation of the ARM compiler V5.2.9 outside the CCSv5 (it did not work), but I did not know, that registering compilers from CCSv8 would be possible. That's good to know!

    As a first short feedback: It looks like, that ARM compiler version 4.9.9 is the last one discovered by our old CCSv5.1.1.
    All newer versions are not discovered. So I will try this compiler version next week...

    Thanks for your support and have a nice weekend,

    Markus

  • 0 in reply to koehmark
    Prodigy 80 points

    Hi George,

    today I tried to compile our OMAP-L138 project with the TI ARM compiler v4.9.9 (instead of v4.9.1) and the old CCS v5.1.1.
    As a second feedback I can tell you now, that I have got an interesting message in the console output:

    >> ERROR: Unaligned access support is only available for ARM11 and higher architectures.

    So there is already a difference between our old TI ARM compiler v4.9.1 and the newer v4.9.9.
    The newer one seems to recognize, that the "--unaligned_access=on" option is not supported for the ARM9 device.

    As a conclusion of these tests, I can summarize, that your original suggestion to update as well CCS and the compilers may be the only solution.

    Thanks and best regards,

    Markus