I guess not, when I remember correctly this has already been repaired for armv6m. The problem for me is that .Lj9 is defined as a negative number. As a consequence r13 points to nirvana and

str r0,[r13, #8] creates an Exception.

# [87] begin
push {r4,r14}
ldr r4,.Lj9
add r13,r13,r4
# Var bit located at r13+0
# Var direction located at r13+4
# Var $self located at r13+8
str r0,[r13, #8]
strb r1,[r13]
str r2,[r13, #4]
.Ll2:

.....

.Lj9:
.long -32840
.Lj7:
.long 32768
.Lj10:
.long 32840
.Lt2:

I have boiled down my problem to this democode. The problem is in the begin line of set Direction. The sp gets moved to 0x0fff8f94 which is unititialized Space before RAM.

The Reason is that the offset for the local var .Lj9 (.long -32840) is plain wrong. It might be me doing something strange (Setting the record to absolute) but this works fine on armv7m.

Jeppe, could you perhaps have a look, I compared with armv7m code and there the whole handling of local vars seems to work totally different.

I am doing something unusual here, so another conclusion is that my problem is most likely not related to the segfault described, sorry for messing this thread up.

Michael

program hello;
{$mode objfpc}
{$modeswitch advancedrecords}
type
   TGPIO_Bit = 0..11;
   TGPIO_Direction = (GPIO_Input, GPIO_Output);
type
   TGPIO_Registers = record
     MASKED_ACCESS: array [0 .. 4095] of longword;
     RESERVED1    : array [0 .. 4095] of longword;
     DIR          : longword;
     &IS           : longword;
     IBE          : longword;
     IEV          : longword;
     IE           : longword;
     RIS          : longword;
     MIS          : longword;
     IC           : longword;
     procedure setDirection(bit : TGPIO_Bit; direction : TGPIO_Direction);
   end;
const
   LPC_AHB_BASE   = $50000000;
   LPC_GPIO0_BASE = (LPC_AHB_BASE + $00000);
var
   GPIO0 : TGPIO_Registers absolute(LPC_GPIO0_BASE);
procedure TGPIO_Registers.setDirection(bit : TGPIO_Bit; direction :
TGPIO_Direction);
begin
   DIR := DIR and (not (1 shl bit)) or (longWord(direction) shl bit);
end;
var
   i : integer;
begin
   i := 0;
   GPIO0.setDirection(i,GPIO_Output);
end.

Should be fixed now. The cpupi code estimated that it needed a copy of the TGPIO_Registers record on the stack even though it was passed by reference :)

One day (In a far far away future) I will understand how this whole compiler magic works ;-)

Thank you very much for your fix, the LED's on my Board are not (yet) blinking, but at least now the code seems to run fine in gdb.

Have a nice evening, will contact you when I have a little more code working for nxp and stm chips...

Michael

Michael Ring wrote

One day (In a far far away future) I will understand how this whole compiler magic works ;-)

Same here. ;-)

About a year ago, a programmer in Austria and myself tried to get Lazarus based cross development for ARM based QNAP NAS boxes running. He even started to write a document on how to do this. (I promised to push same into the Lazarus Wiki in German and English, once we get it going.)

But we gave up for several reasons.

- We only could get fpc, gdb, and gdbserver compiled after installing the complete "Code Source" C cross development suite (including Eclipse). We did not find any smaller and more handy package that did work for that purpose. We did not thinks that it is worth (or even legal) to recommend this in the Wiki.

- We could not get the Lazarus remote debug feature decently working. In theory same can be activated in two different flavors:
1) Using gdbserver on the target: this supposedly is doable "out of the box", but here you can't manually stop a running program that not by itself reaches a breakpoint. Additionally, in fact you need to create a "cross-gdb" (running on PC, targeting ARM) which is independent of FPC but a real PITA to built.
2) Using gdb on the target and accessing same from Lazarus by SSH. Here, some code to do this is existing in the Lazarus svn, but it is commented out, supposedly because nobody got it decently running yet.

As we shared the opinion that cross-compiling without decent remote debugging does not make any sense on headless target devices, we gave up.

-Michael

Michael Schnell wrote

"Code Source"

Sorry: "Code Sourcery"

-Michael

Just curious : are you sure ? When I started "cross-compiling" I thought also I needed a whole tool-chain. Now I'm using just binutils, comiled for my processor. But in my case I'm just working with arm-embedded, so no real OS envolved. That works fine.

Koenraad.

The programmer from Austria did research on this. I only reproduced that it did work when installing "Code Sourcery".

Did you try to create the PC->ARM cross gdb and ARM cross-compile the ARM gdbserver ? It might be that this in fact was why he needed the huge libraries.

I myself was not that much interested in the gdb->gdbserver remoting. I would be more after a decent implementation of SSH->gdb remoting in Lazarus. But as he gave up, I was not inclined to continue working on this all alone, while the project I intended could be made working by first debugging it on a PC and then doing some code-instrumentation to find the last few bugs that only showed in the target environment.

-Michael

Michael Schnell wrote

Did you try to create the PC->ARM cross gdb and ARM cross-compile the ARM gdbserver ? It might be that this in fact was why he needed the huge libraries.

I did create a cross-gdb, I think. But no server. I'm using JTAG, with openocd. I use Insight compiled for arm-embedded. Insight is a GUI for GDB, and maybe gdb is compiled in, I don't know.
I connect the JTAG-dongle to the PC via USB. Then I start openocd. Then I can telnet to openocd to erase and program the flash. Then I use Insight that connects to openocd via a network-interface to debug.

FWIW

Koenraad.

One can use MSEide for that purpose. I do it daily to develop systems with Energy Micro controllers. There is a gdb-server from SEGGER which connects to the J-Link debug interface contained in a cheap Energy Micro starter kit, which is connected to the target chip by the SerialWire debug interface. The cross-binutils, gcc and gdb are the GPL-versions from Code Sourcery (no Eclipse necessary). I assume this setup should work for the Free Pascal compiler too.
I used a similar setup for development of Atmel AVR32 UC3 systems, although with the not so cheap AVRONE debug interface. ;-)

Martin

Why wouldn't it be legal? Codesourcery (or whatever they are now called) provide a free "light" set of cross compiling tools for anybody to download.

As we shared the opinion that cross-compiling without decent remote debugging does not make any sense on headless target devices, we gave up.

For straight cross-compiling I also use the binutils (haven't looked into compiling ARM gdb or gdbserver as my target platform has gdb) from Windows; I use the GNU Binutils 2.21 binutils kindly provided by the FPC team at
http://svn2.freepascal.org/svn/fpcbuild/binaries/i386-win32

Thanks,
Reinier