BLX label - illegal on ARM Cortex-M4

[johnstrohm]

We are using Code Warrior for the Kinetis K50 family.

Our code is mixed C++ and C.

I am getting an illegal instruction trap.

The compiler generates:

    bl   __aeabi_i2f

to call an int-to-float conversion.

The linker converts it to:

    blx  __aeabi_i2f

which is, indeed, illegal on the K50 (ARM Cortex-M4).

Web searches have proved fruitless.  It is probably a library issue somewhere, but I have no idea how to fix it.

Eliminating the floating-point operations completely is the last resort, and I have at this time no way to be certain that the problem won't show up somewhere else.

Suggestions?

[trytohelp]

Hi John,

I've created a short example to reproduce the problem.

I'm using CW for MCU v10.6 with all updated installed.

I've disassembled the code at .c and at .elf level.

I got the following

from main.c file:

+++++++++++++++++++

float test;

int main(void)

{

  0:    b580          push    {r7, lr}

...

          counter++;

  c:    687b          ldr    r3, [r7, #4]

  e:    f103 0301    add.w    r3, r3, #1

  12:    607b          str    r3, [r7, #4]

          test=counter;

  14:    6878          ldr    r0, [r7, #4]

  16:    f7ff fffe    bl    0 <__aeabi_i2f>

            16: R_ARM_THM_CALL    __aeabi_i2f

  1a:    4602          mov    r2, r0

  1c:    f240 0300    movw    r3, #0

            1c: R_ARM_THM_MOVW_ABS_NC    test

  20:    f2c0 0300    movt    r3, #0

            20: R_ARM_THM_MOVT_ABS    test

  24:    601a          str    r2, [r3, #0]

    }

+++++++++++++++++++

from test.elf file:

+++++++++++++++++++

	for(;;) {
	counter++;
1fffc49c:    687b		ldr    r3, [r7, #4]

1fffc49e:    f103 0301    add.w    r3, r3, #1

1fffc4a2:    607b		str    r3, [r7, #4]
	test=counter;
1fffc4a4:    6878		ldr    r0, [r7, #4]

1fffc4a6:    f7ff ff43    bl    1fffc330 <__aeabi_i2f>

1fffc4aa:    4602

mov    r2, r0

1fffc4ac:    f240 031c    movw    r3, #28

1fffc4b0:    f2c2 0300    movt    r3, #8192    ; 0x2000

1fffc4b4:    601a

str    r2, [r3, #0]

    }

...

1fffc330 <__aeabi_i2f>:

1fffc330:    f010 4300    ands.w    r3, r0, #2147483648    ; 0x80000000

1fffc334:    bf48          it    mi

1fffc336:    4240          negmi    r0, r0

...

+++++++++++++++++++

Have a great day,
Pascal
Freescale Technical Support
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[johnstrohm]

Something in your libraries or your project setup is different from something in mine, causing your reconstruct attempt to fail.  For some reason, your linker did not make the (erroneous) change of "bl <label>" to "blx <label>".

When I look at the .lst file, showing the generated assembly language, I see a "bl __aeabi_i2f", which is correct.  When I try to run it, from the final executable, the debugger shows me a "blx __aeabi_i2f". 

Which libraries are you linking, created on what date?

Alternatively, can I recreate the libraries from source code, compiling for ARM Cortex-M4?  If so, what is the procedure?

This is potentially a showstopper for our project.

[trytohelp]

Hi John,

Attached is the example I used.

Have a great day,
Pascal
Freescale Technical Support
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[johnstrohm]

Thank you.  I found something.

Your link map shows that you are getting the problematic routines from library e:/freescale/cw_mcu_v10.6/cross_tools/arm-none-eabi-gcc-4_7_3/bin/../lib/gcc/arm-none-eabi/4.7.3/armv7e-m\libgcc.a(_arm_addsubsf3.o)

My link map shows that I am getting it from library c:/freescale/cw mcu v10.6/cross_tools/arm-none-eabi-gcc-4_7_3/bin/../lib/gcc/arm-none-eabi/4.7.3\libgcc.a(_arm_addsubsf3.o)

Your linker is going one layer deeper, to fetch from 4.7.3/armv7e-m/libgcc.a.  Mine is fetching from 4.7.3/libgcc.a.

What controls that?

[johnstrohm]

I renamed the 4.7.3 libraries to something else, then copied the armv7e-m variants in and rebuilt.

That fixed the problem.

I need to know why the incorrect libraries were getting loaded in the first place, but we now at least have a workaround.

[trytohelp]

Hi John,

The library is defined in the linker settings

I've created the project via the wizard.

Have a great day,
Pascal
Freescale Technical Support
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[johnstrohm]

Picture too small to be readable.

It is our understanding that the wizard only knows how to create C projects, and we're doing C++.

[trytohelp]

The new dialog

The project wizard allow you to select C++ too.

Now if your project is using Processor Expert only C is available.

Processor Expert is not available in C++

Pascal

[johnstrohm]

That's the library path setting I am currently using.

The problem is with libgcc.a.

The linker is pulling libgcc.a from:

     c:/Freescale/CW MCU v10.6/Cross_Tools/arm-none-eabi-gcc-4_7_3/lib/gcc/arm-none-eabi/4.7.3

This is the wrong place for an ARM Cortex-M4.

It should be pulling it from:

     c:/Freescale/CW MCU v10.6/Cross_Tools/arm-none-eabi-gcc-4_7_3/lib/gcc/arm-none-eabi/4.7.3/armv7e-m/

My libpath settings are essentially identical to yours:

[trytohelp]

John,

On my MCU V10.6 installation, I've created 2 projects using the wizard.

The projects are running fine on my side - using correct library.

May be there is a problem with your project properties.

Do you used the project wizard too ?

Very difficult to know what is the cause of the problem.

Have a great day,
Pascal
Freescale Technical Support
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------