Compiler bug, CW 8.3, 56F807, FYI

j___ — Fri, 14 Sep 2018 13:14:27 GMT

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

}

Re: Compiler bug, CW 8.3, 56F807, FYI

ZhangJennie — Mon, 17 Sep 2018 09:25:05 GMT

HI,

Thank you for posting your issue.

To investigate the problem, we need more information:

1. Your CW version

2. Please create a demo project for us. Thus we can reproduce the problem directly.

3. Screenshot of how to reproduce your problem step by step.

Thanks for your cooperation.

Have a great day,
TIC

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

Re: Compiler bug, CW 8.3, 56F807, FYI

j___ — Sat, 22 Sep 2018 16:05:25 GMT

Hi Jennie,

I just posted this as an FYI in case other users run into this issue. I already worked around it as I described.

Basically, the tools are crap and were never finished back in the day. The fact that customers have to pay for these 20-year-old, unfinished, buggy tools is just legal robbery from the "once-loyal" customer-base. I realize this is not your issue, it goes higher than that. However, it is not good marketing on Freescale & now NXP's part.

So, there is no need to take this further. That is why you will not be receiving a test-case project from me.

Regards

Jim

topic Re: Compiler bug, CW 8.3, 56F807, FYI in Classic/Legacy CodeWarrior

Compiler bug, CW 8.3, 56F807, FYI

Re: Compiler bug, CW 8.3, 56F807, FYI

Re: Compiler bug, CW 8.3, 56F807, FYI