Hello,
I am trying to get the embedded version of fpc for arm to work. Currently i try it for the lpc1768 from NXP using the lpcxpresso board. The example compiles, but doesn't run on the target...

I created a simple example and it seems that the code it generates is NOT thumb2 code. I disassembled the elf-file generated by fpc using "arm-none-eabi-objdump -S" I also disassembled it using the debugger "arm-none-eabi-gdb" Here is a fragment of the code from both:

From objdump:
000001c4 <FPC_INITIALIZEUNITS>:
1c4: e92d4070 push {r4, r5, r6, lr}
1c8: ebfffff5 bl 1a4 <SYSTEM_$$_FPC_CPUINIT>
1cc: e59f006c ldr r0, [pc, #108] ; 240 <FPC_INITIALIZEUNITS+0x7c> 1d0: e5904000 ldr r4, [r0]
1d4: e3a05001 mov r5, #1
1d8: e1540005 cmp r4, r5
1dc: ba00000f blt 220 <FPC_INITIALIZEUNITS+0x5c>

From gdb
0x000001c4 <fpc_initializeunits+0>: 70 40 eors r0, r6 0x000001c6 <fpc_initializeunits+2>: 2d e9 f5 ff stmdb sp!, {r0, r2, r4, r5, r6, r7, r8, r9, r10, r11, r12, sp, lr, pc} => 0x000001ca <fpc_initializeunits+6>: ff eb 6c 00 ; <UNDEFINED> instruction: 0xebff006c 0x000001ce <fpc_initializeunits+10>: 9f e5 b.n 0xfffffd10 0x000001d0 <fpc_initializeunits+12>: 00 40 ands r0, r0 0x000001d2 <fpc_initializeunits+14>: 90 e5 b.n 0xfffffcf6 0x000001d4 <fpc_initializeunits+16>: 01 50 str r1, [r0, r0] 0x000001d6 <fpc_initializeunits+18>: a0 e3 b.n 0x91a 0x000001d8 <fpc_initializeunits+20>: 05 00 movs r5, r0 0x000001da <fpc_initializeunits+22>: 54 e1 b.n 0x486 0x000001dc <fpc_initializeunits+24>: 0f 00 movs r7, r1

Note how the interpretation of the code is different, as is the length of most instructions. It looks to me as if the code in the elf-file are (mostly) 32-bit values, while the debugger does interpret thee code as thumb2 (i think).

In the Makefile in rtl/embedded I find:

ifeq ($(SUBARCH),armv7m)
CPU_UNITS=lm3fury lm3tempest stm32f10x_ld stm32f10x_md stm32f10x_hd stm32f10x_xl stm32f10x_conn stm32f10x_cl lpc13xx lpc1768 lm4f120 xmc4500 cortexm3 cortexm4 # thumb2_bare endif

So that suggest (via the comment) that fpc can do thumb2 code, which it should for cortexm3.

My PC is debian/jessie/64bit: Free Pascal Compiler version 2.6.4+dfsg-3 [2014/07/12] for x86_64 I got the sourcecode for the port from svn as described on the website. To create the port I do:

make clean buildbase installbase CROSSINSTALL=1 OS_TARGET=embedded CPU_TARGET=arm SUBARCH=armv7m BINUTILSPREFIX=arm-none-eabi-

For the binutils I use the (current) stuff for the lpc1768 from NXP: lpcxpresso_7.4.0_229

To create a program I do:

ppcrossarm -Ch1024 -Cs1024 -Tembedded -Parm -Cparmv7m -XParm-none-eabi- -Wplpc1768 -vu prog.p

Is there anybody that did get this port to work?

Thanks in advance,
Sietse

Are you sure those are the precise steps you took? Because that should work as you expected it unless you have a broken binutils version. It's normally very quick to complain about incompatible ARM versions

Try to disassemble the objects in the source directory at rtl/units/arm-embedded
Those should largely contain variable length thumb2 code.

I remember seeing the problem that gdb does not correctly disassemble code...

Please do a

arm-none-eabi-readelf -A xxx.elf

you should see:

File Attributes
Tag_CPU_name: "7-M"
Tag_CPU_arch: v7
Tag_CPU_arch_profile: Microcontroller
Tag_THUMB_ISA_use: *Thumb-2*

Compiling, linking and running is fine for me, difference in setup is that I use another processor (stm32f407) and that I used trunk sources to compile the crosscompiler.
But as Jeppe already mentioned, this all should have worked fine with 2.6.4 version too.

And your commandline you used for both creating the crosscompiler / build the program is exactly the same I use.

Michael

One more thing:

Did you try to run the code directly on the device after uploading it or did you use a debugger to start the program?

When I remember correcly all LPCxxx devices need a magic checksum so that they are started on the device. The creation of this checksum is in trunk, but I am pretty sure that it is not in release 2.6.4.

Michael

Jeppe Græsdal Johansen wrote

Are you sure those are the precise steps you took? Because that should work as you expected it unless you have a broken binutils version. It's normally very quick to complain about incompatible ARM versions Try to disassemble the objects in the source directory at rtl/units/arm-embedded Those should largely contain variable length thumb2 code.

Hello,
thanks for the reply.
My program code is ok, and also lpc1768.o and the cortexm3_start code is ok. But code from system.o is wrong.
And thanks to Michael Ring I now can be more consise:

arm-none-eabi-readelf -A lpc1768.o
Attribute Section: aeabi
File Attributes
Tag_CPU_name: "7-M"
Tag_CPU_arch: v7
Tag_CPU_arch_profile: Microcontroller
Tag_THUMB_ISA_use: Thumb-2

arm-none-eabi-readelf -A system.o
Attribute Section: aeabi
File Attributes
Tag_CPU_arch: v5TE
Tag_ARM_ISA_use: Yes
Tag_THUMB_ISA_use: Thumb-1

So why is system.o generated in the wrong version? I think that I did everything as I said.
I will do the compiler starting from scratch again, just to be sure. I now know where to look for.

Sietse

This smells like some system.o left over from an old build or from an incorrect setting in fpc.cfg. Please use the switch -vu when you compile your program to find out where this file is in your filesystem.

If you do not get the correct path then please add the parameter -sh to your commandline. This does create a link script, the good thing is that you can now do:

cat link.res
SEARCH_DIR("/usr/local/lib/fpc/2.7.1/units/arm-embedded/rtl/") SEARCH_DIR("/usr/local/lib/fpc/2.7.1/units/arm-embedded/") SEARCH_DIR("/usr/local/lib/fpc/2.7.1/")
INPUT (
peephole.o
/usr/local/lib/fpc/2.7.1/units/arm-embedded/rtl/system.o /usr/local/lib/fpc/2.7.1/units/arm-embedded/rtl/objpas.o /usr/local/lib/fpc/2.7.1/units/arm-embedded/rtl/stm32f40x.o )

and you can see where system.o comes from.

Michael

Michael Ring wrote

This smells like some system.o left over from an old build or from an incorrect setting in fpc.cfg. Please use the switch -vu when you compile your program to find out where this file is in your filesystem.

I redid the creation of the compiler, and all is well now! I still can't remember where i went wrong before, but all generated code is thumb-2 now!

Thanks for the quick help!
Sietse