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?
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!
-----------------------------------------------------------------------------------------------------------------------
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.
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!
-----------------------------------------------------------------------------------------------------------------------
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?
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.
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!
-----------------------------------------------------------------------------------------------------------------------
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++.
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
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:
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!
-----------------------------------------------------------------------------------------------------------------------