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/TM4C129XNCZAD: Compiler generating misaligned data leading to fault ISR

Part Number: TM4C129XNCZAD

Tool/software: TI C/C++ Compiler

Target TM4C192XNCZAD
CCS 8.2.0.00007
Compiler Version v18.1.5.LTS

Exactly as the title says - a debug build of the TIVAC USB library is mis-aligning data and generating FaultISR when accessing data.
The problem can be fixed one at a time using a #pragma DATA_ALIGN (... , ... ), but the alignment issue just pops up somewhere else.

By inspection I can see that (so far) all the faulting instruction are a half word load in pre-indexed addressing mode, where R1 is an odd address.

    eg    LDRH    R0, [R0, #4]
    
Is there a compiler switch or CCS setting to force all variables to a particular alignment? Or can I turn off alignment faults in the CPU?

Not had this before with the TivaC libraries,

Very strange!



    

  • For the source file that is built when you see ...

    Tony Hanratty54 said:
    I can see that (so far) all the faulting instruction are a half word load in pre-indexed addressing mode, where R1 is an odd address.

        eg    LDRH    R0, [R0, #4]

    ... please follow the directions in the article How to Submit a Compiler Test Case.  In addition, we need some sort of indication about which LDRH goes wrong.  I'm not sure what is best.  Perhaps you can add a comment like // PROBLEM HERE to the C source, if you know where.  Or, maybe the line number of the problem LDRH in the compiler generated assembly file.  Or, something like that.

    Thanks and regards,

    -George

  • I'll try and prepare a stripped down test-case for you.
  • Please supply the requested test case.

    Thanks and regards,

    -George

  • I'm not sure why but this error has gone away. It was clearly something I was doing wrong, but a compiler re-base and full rebuild sorted it.

    My suspicion is that an old library included in the link had been built with an even older compiler version and had somehow knocked alignments out of whack.

    Thanks anyway,