• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 78 subscribers
  • Views 832 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.

CCE v3.1 optimizer bug?

graviton
Intellectual 435 points


Hi

I am working on two projects, one is on F5419, the other one is on FG4618. I am experiencing a interesting problem (bug!?) of the CCE 3.1 optimizer. In F5419 project, my code works OK no matter what optimization level I am using; And on the FG4618 project, in which I am sharing a major portion of the code with F5419 project, the program fails in the USCIA0 TX ISR while using optimization level 2 (default of release build), and the same code works OK while using debug build and optimization level 1.

By inspecting the generated ASM, I noticed that the optimizer extacted a portion of commonly used code to a routine called "abproc0" in almost each ASM file, and normally the the routine is returned with an "RETA" (non ISR code). However, while optimizing the FG4618 USCIA0 TX ISR, the optimizer extracted my buffer management code to a "abproc0" and the routine returns with RETI, I think the RETI caused the code run back to the _c_init00 and restart the software.

In the FG4618 project, the optimizer is doing that because I handled both USCIA0 and USCIB0 TX ISR in the same file, (they are sharing the same IRQ vector), so it can see the duplicated code (inline C++ code in my source), while in the F5419 project, each USCI port is handled in seperate source files, so I don't see the same problem.

My question is, is that really a optimizer bug, or could be something I did wrong? I found the easy work around (optimization level 1), but still curious, and will the CCEv4 potentially fix this?

I also noticed that CCEv4 is released, we purchased CCEv3.1 last spring, how can we get the upgrade?

Many thanks!

  • 0
    TI__Guru**** 173310 points

    DId you make sure that the ISRs are located in lower Flash memory as mentioned in this post, http://e2e.ti.com/forums/p/10011/38926.aspx#38926?

    The #pragma CODE_SECTION is necessary for all ISR routines so that they are linked to lower 64k memory. You can check your link map to make sure this happened correctly.

    If you purchased CCE after June 1 2008 you will receive a automatic update to CCS v4, otherwise you would need to repurchase CCS v4.

  • 0 in reply to AartiG
    Intellectual 435 points

    Yes, that's what I did, with: #pragma CODE_SECTION(".text:_isr") and the linker map file confirmed that, otherwise it won't even run under debug version.

    A function call inside the ISR will be returned with RETI or RETA? I know the ISR itself should be returned by a RETI. the optimizer generated the "abproc0", which is a sub routine called from ISR, has a RETI at the end of it, and I believe that is wrong.

     

     

     

     

     

    Please comfirm, thanks!

  • 0 in reply to graviton
    TI__Guru**** 173310 points

    I found that this is a known compiler bug (SDSCM00031208) in v3.1.0 of the MSP430 compiler tools when using -o2 or higher. Here is the description of the bug:

    "At optimization level -o2 or above the compiler's code size optimization pass that utilizes procedure abstraction may generate incorrect code for C functions declared as interrupt routines. Affected interrupt functions will likely result in runtime errors if called. As a workaround, interrupt routines should be compiled at optimization level 0 or 1."

    The bug is fixed in v3.2.1 of the compiler tools which is included with CCS v4.

**Attention** This is a public forum