Hi *.*,

we use an ARM based SOM for a device developed by us, the software is developed using Lazarus. Now we are testing a new version of the SOM and can't get our software to work.

Old SOM:
Samsung S5PV210
one Cortex-A8 (?) core
Windows CE 6.0 R3 kernel

New SOM:
Freescale Vybrid dual core CPU
one Cortex-A5 core
one Cortex-M4 core
Windows CE 6.0 R3 / Windows Compact 7

In order to gather some more information (even wince-stub isn't running on the device so we can't use GDB) we used a fresh install of FPC 2.6.4.

A empty FPC program worked without any problems, even using the Windows function MessageBox() worked flawless. But if we included the unit SysUtils we got access violations right after the start - the same behaviour as our Lazarus application.

By modifying the original source of SysUtils by some MessageBox() calls we tracked the first access violation down to the procedure GetFormatSettings, to be more precise to the first call of GetLocaleStr. If we removed the call to GetFormatSettings, the empty FPC program worked flawless.

FPC was used with the following command line:
fpc -Twince -Parm -FiC:\FPC\2.6.4\units\arm-wince\rtl\inc -O- test.pas

Any ideas what goes wrong? Did we miss a compiler switch, perhaps?

Greetings

Since nobody else has suggested anything: is the new hardware susceptible to alignment errors in a way that the old hardware wasn't?

Have you tried a later compiler? My recollection is that there were issues on SPARC that might have included alignment problems, and on that architecture I had to abandon 2.6.4 promptly and move onto trunk. I'm currently testing Lazarus trunk at about 47318 is OK with FPC 2.7.1 29398 on various CPUs running Linux, can't speak for CE.

Mark Morgan Lloyd wrote

Since nobody else has suggested anything: is the new hardware susceptible to alignment errors in a way that the old hardware wasn't?

The question is: how can we know? The ARM documentation says only "The processor supports unaligned accesses."

Have you tried a later compiler?

The problem is that we need the ppcarm.exe for Windows and there are no prebuilded snapshots available. Seems to me that we must offer some time to build it by ourself - never done before.

Which is obviously a good start.

I've done it for Linux and found it painless, but I know so little about CE that my opinion shouldn't be trusted.

In our previous episode, Bj?rn Schreiber said:

First narrow it down to the exact line that causes the problem. E.g. copy relevant parts of sysutils into a program that only uses system, and then start testing, till you know which line provokes the problem.

Marco van de Voort wrote

First narrow it down to the exact line that causes the problem. E.g. copy relevant parts of sysutils into a program that only uses system, and then start testing, till you know which line provokes the problem.

What I can say at this time is that the first access violation happens at the line

   Result:=s;

in the function SysUtils.GetLocalStr in an empty FPC program only including the unit SysUtils. But I suppose the problem lies elsewhere.

at the line

Result:=s; in the function SysUtils.GetLocalStr in an empty FPC program only

including the unit SysUtils. But I suppose the problem lies elsewhere.

As said by Marco: please try to reproduce it by copying parts of SysUtils (e.g. GetLocaleStr) into an empty program (and using that code of course ^^) to find an example code that shows the problem.

Regards,
Sven

Sven Barth wrote

As said by Marco: please try to reproduce it by copying parts of SysUtils (e.g. GetLocaleStr) into an empty program (and using that code of course ^^) to find an example code that shows the problem.

I narrowed it down to the following minimal program:

--- Schnipp On ---
program test;
var
   AString: String;
function AFunction: String;
var
   S: WideString;
begin
   S := 'Test';
   AFunction := S;
end;
begin
   AString := AFunction;
end.
--- Schnipp Off ---

Compiled with a fresh install of FPC 2.6.4 with the command line

fpc -Twince -Parm test.pas

runs without any problem on the old hardware (Cortex-A8) but produces a runtime error 216 on the new hardware (Cortex-A5). This code follows SysUtils.GetLocalStr, called by
SysUtils.GetFormatSettings. The error doesn't occur if S is defined as String instead WideString or if I do it without the function call.

Regards,
Björn

runtime error 216 on the new hardware (Cortex-A5).

This code follows SysUtils.GetLocalStr, called by

SysUtils.GetFormatSettings. The error doesn't occur if S is defined as String instead WideString or if I do it without the function call.

Could be a bug in the conversion routines from WideString to AnsiString. Since we are currently preparing release 3.0.0 it might be best to test with that as well (cause string handling was changed in 2.7.1). It shouldn't be hard to compile for WinCE either, just download the source (e.g. by using SVN) and do the following:

First build a native 3.0.0 and install it:

make clean all install INSTALL_PREFIX=c:\wherever\you\want

For example I myself usually install to D:\fpc\3.0.0

make clean all CPU_TARGET=arm OS_TARGET=wince BINUTILSPREFIX=arm-wince- CROSSBINDIR=c:\whereever\arm-wince-as\is

You can also pass additional option like CPU type and FPU type using OPT="xyz" with the same parameters as for the compiler.

Afterwards you can install the newly compiled compiler and RTL:

make crossinstall CPU_TARGET=arm OS_TARGET=wince
INSTALL_PREFIX=c:\wherever\you\want

Now you merely need a fpc.cfg. For this you can copy your 2.6.4's fpc.cfg, copy it to c:\wherever\you\want\bin\i386-win32 (or x86_64-win64 if you built a 64-bit native compiler) and adjust its paths. Note: the path c:\wherever\you\want is the one you specified for INSTALL_PREFIX.

If you have any problems, feel free to ask.

Regards,
Sven

Thanks for the instruction, very helpful. Unfortunately I have to prioritise other stuff first so this must wait. But I come back when I continue testing.

Regards,
Björn Schreiber

Some new information: the manufacturer of the SOM did a analysis of the compiled program. We were told that the program makes use of the SWP instruction which is deprecated since ARMv6 and was deactivated in the kernel we used. They build a new kernel with the deprecated instruction activated which is running the test program without any error. Now we can use this new kernel for further tests.

Is there any compiler switch to control the generated code and therefore the chance to avoid this deprecated instruction?

Greetings,
Björn

The swp instruction is in the RTL. It will not be included if you compile the RTL for an architecture that does not support this instruction. The Cortex-A5 is an ARMv7 class cpu, so adding -Cparmv7 to your cross-options when building the RTL should work.

Jonas

Small correction: -Cparmv7a

------ Oprindelig besked------Fra: Jonas MaebeDato: ons., 11. feb. 2015 13:36Til: FPC-Pascal users discussions;Emne:Re: [fpc-pascal] access violations on new ARM hardware On 11 Feb 2015, at 12:48, Björn Schreiber wrote:> Some new information: the manufacturer of the SOM did a analysis of > the compiled program. We were told that the program makes use of the > SWP instruction which is deprecated since ARMv6 and was deactivated > in the kernel we used. They build a new kernel with the deprecated > instruction activated which is running the test program without any > error.> Now we can use this new kernel for further tests.>> Is there any compiler switch to control the generated code and > therefore the chance to avoid this deprecated instruction?The swp instruction is in the RTL. It will not be included if you compile the RTL for an architecture that does not support this instruction. The Cortex-A5 is an ARMv7 class cpu, so adding -Cparmv7 to your cross-options when building the RTL should work.Jonas_______________________________________________fpc-pascal maillist -

Jonas Maebe wrote

instruction. The Cortex-A5 is an ARMv7 class cpu, so adding -Cparmv7 to your cross-options when building the RTL should work.

Thanks for the info, I will give it a try.

Greetings,
Björn