• State TI Thinks Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 55 subscribers
  • Views 1599 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.

Compiler/TMS320F28075: Compiling failure of F2807x_can.h with new compiler 16.9.1.LTS

HS FAE Germany
Mastermind 31690 points
Part Number: TMS320F28075

Tool/software: TI C/C++ Compiler

Hello,
customer switched from compiler 16.9.0.LTS to 16.9.1.LTS and got the failure attached:

"The aligment of an array element is greaater than the element size"

DSP:                                      F28075
TI Bibliothek                      v210

What is the reason?

Regards, Holger

  • 0
    TI__Guru**** 244470 points

    Thank you for reporting this problem.  I can reproduce it.  I filed CODEGEN-1968 in the SDOWP system to have this addressed.  You are welcome to follow it with the SDOWP link below in my signature.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    TI__Mastermind 31690 points
    Hello,
    how can I find the CODEGEN-1968 in the SDOWP system. I type 1968 in the search machine but could find anything.

    Regards, Holger
  • 0 in reply to HS FAE Germany
    TI__Guru**** 244470 points

    That's my fault.  I made an error when filing the issue.  I just fixed it.  Please accept my apologies.

    It will take few hours to propagate to the external view.  When you search for the bug, enter the full identifier: CODEGEN-1968 .

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    TI__Intellectual 2560 points

    Please note that this is not a bug in the compiler but rather in the CAN header files. The C2000 team has already filed a bug to fix their header files.

    The compiler error statement is correct. You can't declare an array of byte peripherals. The compiler guide has been updated to include this restriction. The reason is that byte peripherals are aligned larger than their size, and the C language requires that array elements not have an alignment larger than their size because of element address calculation. Note that prior to 16.9.1.LTS, the compiler silently accepted such arrays but did not increase the alignment of the elements. This was a bug for byte peripheral types and was corrected as a bug fix in 16.9.1.LTS.

    Thanks,

    Anna

  • 0
    TI__Guru 53165 points

    I fixed the issue as shown in the attached header file.


    F2807x_can.h


    Whitney

  • 0 in reply to Whitney Dewey
    Prodigy 115 points
    I posted a patch for the F2837x version of the header file. Unfortunately that post seems to have magically vanished..?
  • 0 in reply to Sebastian Neuser72
    TI__Intellectual 2560 points

    Dear Sebastian,

    As these headers are distributed by Texas Instruments, we cannot distribute your patch to our headers on the forum, as it was not verified to be correct by the C2000 team.  However, an engineer from the C2000 team has already posted a patch.  Please compare the posted patch to yours for any discrepancies and let us know if you have any questions.

    Thanks and Regards,

    Anna

  • 0 in reply to Anna Youssefi
    Prodigy 115 points
    And where might I find that patch? :-)

    So my post was deleted?
  • 0 in reply to Sebastian Neuser72
    TI__Guru 53165 points
    Hi Sebastian,

    The fixes shown in the F2807x_can.h version of the header file will also work fine with both the F2837xD and the F2837xS. They all use the same CAN peripheral. If you diff the header file I posted with the original, you'll see that the change was to switch the bp_32 arrays to uint32_t arrays in the last structure.

    Yes, your post was deleted to avoid confusion for anyone who might have downloaded it. Although it got rid of the errors, it looked like it wasn't providing enough reserved space in some places between the actual registers which would have put some of them at the wrong addresses.

    Whitney
  • 0 in reply to Whitney Dewey
    Prodigy 115 points

    Ooops, that patch was indeed totally broken. /o\
    So to anyone who might have downloaded the patch:

    Do not use my patch! It most likely breaks stuff.

    This might be a matter of taste, but I find simply deleting the post without any comment more confusing than openly stating that the patch is broken.