AnsweredAssumed Answered

Compiler bug, CW 8.3, 56F807, FYI

Question asked by j... on Sep 14, 2018
Latest reply on Sep 17, 2018 by ZhangJennie

FYI.

I run into compiler bug in these DSC compiler with reasonable frequency. I don't usually post them. I decided to post this one today as I have the bandwidth today.

 

These Legacy DSC compiler are buggy and, in my opinion, not finished. It is amazing that in its day it was actually considered a finished product. So much so that there has been no improvements in over 15 years. the help file is incomplete. It doesn't support post-build steps. It can't load symbol tables. It doesn't allow erase & program of select memory section while in debug to load bootloaders & apps for test. Several controls\menu items are not supported. Even the DSC compiler that is in CW 10\11 is just the old compiler & debugger with a new face. Too much MetroWerks DNA in these tools, just terrible.

 

It is amazing that they could charge so much for the compiler back in the day. Compared to Code Composer 2.2 &3.3 which are of a similar vintage, the MetroWerks\Motorola\Freescale\NXP Legacy CW looks like a high-school project. What is MORE AMAZING, it that it costs so much NOW, a nearly 20 year old product that was terrible 20 years ago. Talk about bilking the customer??!! Even, the community had to hack & document the tool to run it on 64-bit. You would think that at $2500-a-pop, that re-bundling of the installer would be done for the user-base as a released even if no improvements were made to the tool.

------------------------------------------------------------

Anyway, that leads to this compiler bug. I am trying to compare a 32-bit variable in a structure to a #defined constant using C. The issue is that the accumulators are 40-bit. When loading the constant, the compiler clears the upper 8-bits (32-39). However, when it loads the variable, the compiler does NOT clear these upper bits and the compare fails because there is left-over garbage there from who-knows-what.

 

See the attached image....

 

Here is the code snippet:

 

#define FDL_ERASE_REQ_ENA        0xAA55AB39UL

if(FDL_stat.EraseFlashRequest == FDL_ERASE_REQ_ENA)

 

I have tried adding\omitting the UL suffix on the #define, no difference.

I have tried ANDing the variable with a mask, no difference.

if( (FDL_stat.EraseFlashRequest & 0xFFFFFFFF) == FDL_ERASE_REQ_ENA)

 

This is occurring on the 56F807. I will say that the same code seems to work on the 56F8307 but I ran into 5 places in 8307 where I had to work around other compiler bugs.

 

So, the solution was to break up the unsigned long into 2 integers and compare those.

 

       unsigned int CompilerBugFix1a, CompilerBugFix1b, CompilerBugFix2a, CompilerBugFix2b;

        CompilerBugFix1a = FDL_stat.EraseFlashRequest & 0x0000FFFF;
        CompilerBugFix1b = FDL_stat.EraseFlashRequest & 0xFFFF0000;

        CompilerBugFix2a = FDL_ERASE_REQ_ENA & 0x0000FFFF;
        CompilerBugFix2b = FDL_ERASE_REQ_ENA & 0xFFFF0000;

        if(CompilerBugFix1a == CompilerBugFix2a)
        {
            asm(nop);  //Works! Hits this breakpoint
        }

        if(CompilerBugFix1b == CompilerBugFix2b)
        {
            asm(nop);  //Works! Hits this breakpoint

       }

Outcomes