Compiler/Optimisation error CW10.2 (Kinetis)

[mjbcswitzerland]

Hi All

The following code (simplified to a minimum from original case but simple to reproduce) fails from optimisation for size -O2 (is OK for -0-and -O1). If the code is simplified - eg. removing inner if () level, the problem no longer occurs.

Since the working project is almost complete and tested I can't upgated to CW10.5 (yet) but maybe someone would like to see whether it has been solved there (?)

#define NUMBER_OF_ANALOGUE_INPUTS 8

signed short diInput1[NUMBER_OF_ANALOGUE_INPUTS];

static const int ADC0channel[8] = {0,1,2,3,4,5,6,7}; // in reality the numbers may be mixed around

static const int ADC1channel[8] = {0,1,2,3,4,5,6,7};

void function(void)

{

static int iDinIndex = 0; // multiplexed input index (counts 0,1,2,3,4,5,6,7,8,9,10,11)

diInput1[ADC0channel[iDinIndex]] = (signed short)0x0080; // fixed ADC values

diInput1[ADC1channel[iDinIndex]] = (signed short)0x0080;

if (iDinIndex & 0x01) { // every even sample

register signed short sSample = diInput1[ADC0channel[iDinIndex]]; // ADC input sample

register iADC;

for (iADC = 0; iADC < 2; iADC++) { // for each ADC (2 digital channels)

fnDebugHex(sSample, (sizeof(sSample) | WITH_LEADIN | WITH_CR_LF));

usSample = diInput1[ADC1channel[iDinIndex]]; // ADC1 input sample (ADC1)

}

if (++iDinIndex >= 8) {

iDinIndex = 0;

}

}

else { // odd samples

++iDinIndex;

}

}

fnDebugHex() can be replaced by printf() and shows the following incorrect output (the function needs to eb called twice since it jumps the loop on every odd call) but can be called from any code in an operating project environment that can display the output.

Without the debug output the error can also be seen by stepping the code with debugger.

0xff80  <- incorrect

0x0080 <- correct

When the following is inserted before the debug output line it is then correct (2 x 0x0080).

if (iADC == 0) {

sSample = diInput1[ADC0channel[iDinIndex]];

}

That means that loading the value before the loop is bad but inside the loop is good.

The problem can be seen in the assembler code generated:

- inside the loop ldrsh r7,[r6,r3,lsl #0x1]    <- sign extends from a half-word (correct)

- before the loop ldrsb r0,[r6,r2,lsl #0x1]    <- this sign extends from a byte (incorrect)

Regards

Mark

[Rick_Li]

I would suggest using the latest CodeWarrior v10.5, please try it to see if the problem still remains?

[mjbcswitzerland]

Hi

I am trying to get the project to work in CW10.5 but it is not going well. After half a day of downloading and installing and importing projects I find that the files build using a newer version of the compiler (Version 5.1 build 42 (build 42) now and Version 5.1 build 59 (build 59) in CW10.2) but the linker now fails.

Looking at example projects, which build OK, they look to be using a different tool chain (ARM Ltd Windows GCC (G++ Lite)) so I don't know whether the standard method when moving to CW10.5 is to move to this other compiler or fix the new problems?

This is what happens:

'Invoking: ARM Linker'

"C:/Freescale/CW MCU v10.5/MCU/ARM_Tools/Command_Line_Tools/mwldarm" -o "uTaskerV1.4.afx" @@"uTaskerV1.args" 

C:/Freescale/CW MCU v10.5/MCU/ARM_Tools/Command_Line_Tools/mwldarm|Usage|Error

>Specified file 'C:/MJBC/Internal/Freescale/Kinetis/workspace/uTaskerV1.4/

>Applications/uTaskerV1.4/KinetisCodeWarrior/Project_Settings/Linker_Files/

>MK60N512VMD100_ram.lcf

>

>-main main

>

>-map

>

>-map unused

>

>-map keep

>

>-symtab

>

>-lC:/Freescale/CW' not found

>Operating system error:

>The syntax for the file name, directory or

>disk is incorrect.

Errors caused tool to abort.

mingw32-make: *** [uTaskerV1.4.afx] Error 1

It looks like a path needs to be put into "" so that it handles spaces in the path name but I can't locate the source of this to be able to do anything about it. Any ideas??

Regards

Mark

[mjbcswitzerland]

Hi All

After solving the problem with CW10.5 (incompatibility with a path reference between the two versions) I can confirm that the problem no longer exists with the newer Metroworks compiler version delieverd with it.

Regards

Mark

[mjbcswitzerland]

Yong Li

I will be trying CW10.5 shortly but, as you probably know, it takes quite a lot of time to install. I will also first need to de-install the older CW10.1 so that there is space for it.

Regards

Mark

[ZhangJennie]

Can you please send us the project to reproduce the problem

[mjbcswitzerland]

Jennie

A service request was opened and the complete project has been sent.

Regards

Mark