Ok, maybe I'm missing something...

I can compile and get a binary for an STM32F103RE. However, if I attempt for the STELLARIS target, I get an error. I see where the error is coming from in t_embed.pas. It looks like the t_embed.pas file is missing linking information for the Stellaris. Can someone confirm this is the case before I go on a wild chase changing things ?

Thanks,

John Clymer

John Clymer wrote

Ok, maybe I'm missing something... I can compile and get a binary for an STM32F103RE. However, if I attempt for the STELLARIS target, I get an error. I see where the error is coming from in t_embed.pas. It looks like the t_embed.pas file is missing linking information for the Stellaris. Can someone confirm this is the case before I go on a wild chase changing things ?

Yes, it should have the part specific memory map there.

Geoffrey

Yes. arm embedded devices are only supported as far as somebody contributed the compiler and rtl support. Problem is: we don't have any chance to test it, so only users of these devices can contribute the support.

Can someone confirm this is the case before I go on a wild chase changing things ?

Ok. Give me a week or so (very hectic schedule right now...) And I will see if I can't patch it up some. New to this - what is procedure to generate and submit patch set ?

Thanks !

________________________________

John Clymer wrote

Ok. Give me a week or so (very hectic schedule right now...) And I will see if I can't patch it up some.

To save you some time perhaps, the following was for lm3s9b92 and rtl/embedded/arm/stellaris.pas; I only tested with that device:-

1 in cpuinfo.pas, tcontrollertype should include, ct_lm3s9b92 rather than stellaris 2 also 'stellaris' in controllerunitstr should be 'lm3s9b92

3 in compiler/systems/t_embed.pas add:-

ct_lm3s9b92:
      with linkres do
        begin
          Add('ENTRY(_START)');
          Add('MEMORY');
          Add('{');
          Add('    flash : ORIGIN = 0x00000000, LENGTH = 256K');
          Add('    ram : ORIGIN = 0x20000000, LENGTH = 96K');
          Add('}');
          Add('_stack_top = 0x20017FFC;');
        end;

I also found I needed to comment out the controller types other than stellaris in rtl/embedded/makefile.fpc.

Then remake make,and make the compiler.

New to this - what is procedure to generate and submit patch set ?

+1

but Florian did offer to integrate any updates himself :)

Geoffrey

John Clymer wrote

New to this - what is procedure to generate and submit patch set ?

http://wiki.lazarus.freepascal.org/Creating_A_Patch

Kicking it around in the back of my head at work today...

I tried doing a compile to assembly language for the stellaris - and it choked giving the error from t_embed.pas. The error comes from the portion of the program trying to generate a linker script.

, it looks like every single flavor of ARM controller will require it's own subsection of the case() statement. This can easily get long and ugly. As the only thing that changes between most of the arm variants is the memory layout - why not provide a generic "stellaris" switch - with reads in a text file containing the memory map and stack top (the rest of the link file remains the same for all variants of ARM) ?

This way - switching to a new variant of stellaris only requires tweaking a memory map file - rather than a re-build and patch of t_embed.pas ? For that matter - entirely foreign Cortex M3 parts could be easily supported without requiring changes to the compiler.

Just pondering how to make it easier and more flexible ...

________________________________

yes, this could be applied to any of the M3 variants.

This way - switching to a new variant of stellaris only requires tweaking a memory map file - rather than a re-build and patch of t_embed.pas ? For that matter - entirely foreign Cortex M3 parts could be easily supported without requiring changes to the compiler. Just pondering how to make it easier and more flexible ...

absolutely, I did not go any further as I needed one particular controller at the time to prove I could use FPC on a commercial project, so just hacked what Jeppe had done. Really all the reg definitions can be separate too (and not in stellaris.pas). Even the interrupts can be handled separately as you can flip the NVIC into ram in your application, it just happened to be convenient to put uart0 in stellaris.pas as this port is configured for debugging by default on all the stellaris mcus.

Yes, this can be done. However, somebody who knows enough about a certain controller family must do this.

What in your view is the best way to separate link options such as these variations in memory maps between devices? I often have several projects at once and they can be using different parts within the same family; having to re-compile the compiler when switching between projects is not ideal.

_______________________________________________ fpc-devel maillist - http://lists.freepascal.org/mailman/listinfo/fpc-devel

for

at

once and they can be using different parts within the same family; having

to

re-compile the compiler when switching between projects is not ideal.

What about adding some command line options
similar to -WB:
-WB40000
sets the default load address of Windows PE executables to 0x40000. Its value is stored in global variable ImageBase.

If only four or five values need to be set, we could just implement option -WE option:
E for embedded,
with
-WEFlashOriginHexDecimalValue
-WEFlashLengthHexDecimalValue
-WERamOriginHexDecimalValue
-WERamLengthHexDecimalValue
-WEStackTopHexDecimalValue

Of course, this depends if the list of required values is limited or not. Another problem is if the script should include or not those lines.
But here also, we could create a list of args,
some would be tagged as having a default value, which would be used if no command line option is given, while other args would have no default, meaning that the linker line would only be inserted if the corresponding value are set at command line. If that case, it might be better to combine Origin and Length into a unique
argument
-WEFlashHexValueOfOrigin-HexValueOfLength
where HexValueOfOrigin and HexValueOfLength would both bereplaced by the valid values in order to avoid having only Origin and no Length for Flash (or Ram, or anything else that would be needed).

Maybe a special 'custom' controller type would be handy for this...

Pierre Muller

I was thinking more of a generic controller class, including a memory.def (or whatever one wants to name it) file. That would be easiest as it would only effect the t_embed.pas file (and cpuinfo.pas file to add the generic type.)

Haven't looked into possibly a compiler option (and may easily be more trouble
than a command line option):
{$ARM_FLASH_START xxxxxxxx}
{$ARM_FLASH_LENGTH xxxxxxxx}
{$ARM_SRAM_START xxxxxxxx}
{$ARM_SRAM_LENGTH xxxxxxxx}

But, I still think a static memory definition file would require the least amount of code changes. And would only effect only the ARM related files.

John

________________________________

The compiler option works well when you have conditional options for different target builds using ifdefs, which I do I lot. It makes it very easy to see if it is in the source file as it can be locked to other options and you only need to select it in one place.

A separate linker file starts to make FPC handle like any other compiler :( instead of the joy to use it is :)

Geoffrey

For what it's worth, IAR's C compiler for Cortex-M3 uses an ICF file to hold that information, so there is precedent for doing it that way.

It holds the following (edited slightly to remove fluff):

define symbol __ICFEDIT_intvec_start__ = 0x08000000;
define symbol __ICFEDIT_region_ROM_start__ = 0x080000EC;
define symbol __ICFEDIT_region_ROM_end__   = 0x0801EFFF;
define symbol __ICFEDIT_region_RAM_start__ = 0x20000000;
define symbol __ICFEDIT_region_RAM_end__   = 0x20004FFF;
define symbol __ICFEDIT_size_cstack__ = 0x400;
define symbol __ICFEDIT_size_heap__   = 0x4;
define memory mem with size = 4G;
define region ROM_region   = mem:[from __ICFEDIT_region_ROM_start__
to __ICFEDIT_region_ROM_end__];
define region RAM_region   = mem:[from __ICFEDIT_region_RAM_start__
to __ICFEDIT_region_RAM_end__];
define block CSTACK    with alignment = 8, size = __ICFEDIT_size_cstack__   { };
define block HEAP      with alignment = 8, size = __ICFEDIT_size_heap__     { };
initialize by copy { readwrite };
do not initialize  { section .noinit };
place at address mem:__ICFEDIT_intvec_start__ { readonly section .intvec };
place in ROM_region   { readonly };
place in RAM_region   { readwrite,
                        block CSTACK, block HEAP };

I agree. Keeping the configurations in code is easier to manage, compared to the spiderweb of magically named files of other embedded compilers

I think that maybe creating an abstract class hierachy of chip families, instead of the current solution of a single large case statement, would be a better solution in the long run

Geoffrey

Yes. I think as well that everything should stick in the compiler. FPC is open source, so no need for a convolution of compiler support and external files. Full support of all devices will lead to a huge number of interwinded include files in the rtl anyways.

Well, it can be done also by some sets like
controllers_stellaris128flash64ram. I don't think that a big full fledged class hierary is needed. Even the case statement might be sufficient.

For what it's worth, IAR's C compiler for Cortex-M3 uses an ICF file to hold that information, so there is precedent for doing it that way. It holds the following (edited slightly to remove fluff):

[...]

IMO these are all values required by the linker, not by the compiler itself. Both an internal or external linker should read these definitions from an ICF (or similar) file. The name of that file, or of the concrete device, can be passed to the linker as a commandline argument. Some tables (devices) can be added to the linker code, of course, in detail when the devices also require specific linker code (in subclasses). [dunno about concrete requirements]

DoDi

Did an analysis of the Stellaris current product lineup, there are over 180 current Stellaris products on TI's selection guide. Boiling through the FLASH and RAM availability, there are 31 unique configuratios of FLASH / SRAM between those 180 devices. So, the case() statements in t_embed.pas will have 31 more entries to completely support the entire line of Stellaris processors (and a few more with products slated for future release).

Currently, everything is in a handful of giant arrays. Just wondering if it would be better to switch to a record structure for the controller entries - rather than individual arrays. (Add in a variety of STM parts and the other manufacturers, and there could easily be over 100 memory configurations in the table.)

Looking at RTL support. Currently for each ARM variant, they have a contoller unit (the controllerunitstr entry). Inside the current controller units, registers are defined. These registers definitions "automatically" become part of the variable space of an application. Is the intent for ALL controller registers be provided inside the RTL ? I would think this would be better provided by outside files. (i.e. "uses LM3S8962" - brings in a file containing all the 8962 register definitions.)

Having an outside file (it would be akin to a C header file - interface only specifications for the registers, and that would be it) would be much clearer than hiding the details inside a "hidden" file. If the user wants to chase down exactly where the definition is coming from, using a non-RTL file saves the user from having to dig through the compiler source to determine where it was coming from. (Although for a newb, it may be preferable to have them automatigically available.)

My suggestion would be that the register definitions come in an UNIT file that only defines registers. The controller unit in the compiler source would only provide the bare minimum necessary to bring the system up and call PASCALMAIN. However, if it is deemed better to have the entire register set defined inside the RTL - that would be fine too.

John

________________________________

John Clymer wrote

Did an analysis of the Stellaris current product lineup, there are over 180 current Stellaris products on TI's selection guide. Boiling through the FLASH and RAM availability, there are 31 unique configuratios of FLASH / SRAM between those 180 devices. So, the case() statements in t_embed.pas will have 31 more entries to completely support the entire line of Stellaris processors (and a few more with products slated for future release).

could it not just be two numeric command line options which are used to write the relevant strings to 'linkres'? This would be future proof.

Currently, everything is in a handful of giant arrays. Just wondering if it would be better to switch to a record structure for the controller entries - rather than individual arrays. (Add in a variety of STM parts and the other manufacturers, and there could easily be over 100 memory configurations in the table.) Looking at RTL support. Currently for each ARM variant, they have a contoller unit (the controllerunitstr entry). Inside the current controller units, registers are defined. These registers definitions "automatically" become part of the variable space of an application. Is the intent for ALL controller registers be provided inside the RTL ? I would think this would be better provided by outside files. (i.e. "uses LM3S8962" - brings in a file containing all the 8962 register definitions.)

I agree. The ones I included in 'stellaris.pas' were enough to get the basic system working with a non-trival test and to give anybody who took it further some suggestions which I found worked ok eg. putting the registers in absolute records. Really they should all be in separate files for each peripheral, then you only need to include whichever ones are relevant to the device you are actually using.

Having an outside file (it would be akin to a C header file - interface only specifications for the registers, and that would be it) would be much clearer than hiding the details inside a "hidden" file. If the user wants to chase down exactly where the definition is coming from, using a non-RTL file saves the user from having to dig through the compiler source to determine where it was coming from. (Although for a newb, it may be preferable to have them automatigically available.)

In fact I have subsequently been using the C header files for bit definitions after conversion using h2pas. This saved a lot of time.

My suggestion would be that the register definitions come in an UNIT file that only defines registers. The controller unit in the compiler source would only provide the bare minimum necessary to bring the system up and call PASCALMAIN. However, if it is deemed better to have the entire register set defined inside the RTL - that would be fine too.

Units are convenient too; you can include access methods alongside the register definitions.

Geoffrey

Maybe it's indeed better to have an array of records, each record describing one controller.

Well, isn't it for a user easier just to pass the controller he uses on the command line and the compiler does the rest? Why bother with addional uses etc. if the compiler knows already anything?

because one is forever re-compiling the compiler when one switches to a device with a new peripheral, and if your main activity is not compiler development but product development one has to go back and find out how to do it each time. Better that the core stays the same.

Geoffrey

_______________________________________________ fpc-devel maillist - http://lists.freepascal.org/mailman/listinfo/fpc-devel

This is true, it makes things maybe easier for the first implementor, he hacks together some units and directives but it is harder for any latter user. He basically needs to do the same amount of work as the initial implementator: find out that he needs some directive, find the correct units etc.

exactly so, IMHO! (and in my own experience).

If all he needs to add are a few peripheral definitions and drivers and there have been provided some examples of structures which work well in practice for these, a new user can be doing useful work very quickly and contributing to the collective knowledge from day one.

G

_______________________________________________ fpc-devel maillist - http://lists.freepascal.org/mailman/listinfo/fpc-devel

What I mean is: if the first user of a controller does things properly (create startup and interface unit, extend t_embedded.pas), subsequent users of the same controller have much less work, they need only to pass the correct parameter to the compiler and not to fiddle with configuration files, directives etc. The compiler takes care of everything.

and I agree with you 100%.

as the 'first user' though I had other pressures on me, such as having to prove that using FPC on Stellaris was viable so that I could avoid being forced into writing in C. I therefore concentrated on the one device I had on the evm; maybe thats what everybody does. Then one looks for the time to tidy things up, or for someone else to come along wanting to go the same route and needing a jump-start.

So, consensus is to include the register definitions - then I will work on these. To get all the possible register structures for all possible peripherals will take some time. And naming conventions come into play as well.

I prefer having my device registers defined in structures. Other people prefer non-structured "flat" definitions for the registers.

i.e.

PortA -> DDR
PortA -> PIN

vs.

DDRA
PINA

The current stellaris has a start for structures, unless there are objections, I would continue with these.

The actual names of the registers will be best to match the datasheet (otherwise, non-compiler writing / source reading people will need a manual [and somewhat lengthy one at that] to provide the correcting naming of each peripheral and register.) BUT - there is no standard for what the peripheral structure instances should be named - so again, this would need to be documented if the target audience is people that won't be tearing the compiler apart. [And again, more work...]

John

________________________________

Afaik there is a standard for the Cortex platform how to do it, google for "ARM Cortex Microcontroller Software Interface Standard"

surely porta.ddr

yes, it would be best to take them from the C definitions in 'stellarisware'. I shortened and changed some of them as they were unnecessarily flowery or obscure.

there is a generic doc on the arm.com site and a stellaris specific one on the TI site.

the TI site.

Following the CMSIS would definitely make development easier, but it comes with a tradeoff. The generic nature of it makes it very wordy and somewhat inefficient (sometimes you have to make several function calls to do what a single assign could do). If possible, it might be best to have the compiler expose the raw registers, and add CMSIS as a unit that can be included in your application source.

Also, just peeked at current line up of STM32 controllers, there are 150 different controllers available, consisting of 33 possible combinations of FLASH memory and SRAM size.

I will try to get the controller specific parts boiled up into record structures this weekend, and get some added controllers installed into cpuinfo.pas. (And fix any compiler breakages from the change.) I have the SVN download - so generated diffs should be a bit easier (still learning SVN though...)

Also, I read through the ARM docs regarding the "standard" library - and can setup registers based on the each vendors published "C" library so they match the ARM/vendor docs. However, as each controller in the line-up has only certain peripherals, is it the intention that EACH controller gets it's own controller file with memory definitions for peripherals ? That's 300+ unit files between STM32 and TI's Stellaris line-ups.

OR - does one try to merge as many controllers into 1 memory definition as possible. i.e. ALL of stellaris could be defined for the maximal configuration of peripherals (as they have a standard mapping layout for peripherals i.e. ALL LM3 devices have UART0 at the exact same location - and all have the same register layout.) The caveat to this that one could compile code that won't actually run on a given device.

OR - we could leave the peripheral definitions to the user. (Which I'm assuming is not the preferred route.)

John

________________________________

Just jumping in here and maybe it was discussed but the cortex-m3 appears to have been designed so that if you match the arm abi you can put the address of handlers directly in the vector table and not have to trampoline off of a wrapper function. basically 8 well chosen register are put on the stack so you dont have to preserve them, so that the handler has the look and feel of a standard function and not the look and feel of an interrupt handler.

I would not mix all cortex-m3 based devices into one definition.

Perhaps lumping all the stellaris parts into one but that would still get huge. Maybe all the 800 series in one, all the 1000 series in another, and so on. That is the way the vendors tend to manage information for their parts, and it makes sense as a sub-set of a larger family is very closely related and easier to manage the subtle differences.

Is it your intention to get all of the stellaris parts into this project all at once? Or build some framework, add one or a few parts from each family and then over the course of time add a part or two here and there?

I would start with one family 800 series or 1000 series, one of the more simpler ones, and try to capture that series. If one series of parts is too bulky or complicated that is your answer, you may need to isolate each part by itself.

I would not try to cross vendors to the stm or lpc/nxp cortex-m3 or cortex-m0 parts etc. the memory maps and peripherals across vendors are too different. boot strategies, flash programming, etc. I suspect everyone using an arm7 in a controller now will be using one of the cortex-m cores before long if they are not already. Is it st or lpc that has both cortex-m3 and cortex-m0 based parts now? I would have to look up the difference but know I bought/saw both at some point.

David

I think that anybody using a device would have to have already assigned pin connections in the board design and should know well which peripherals they are using.

OR - we could leave the peripheral definitions to the user. (Which I'm assuming is not the preferred route.)

It is to me. People can contribute definitions and drivers as they use the parts and these can just go in 'uses'.

Geoffrey

The great strength of ARM is that the peripherals, even if in different locations in different manufacturers parts, are identical in hardware terms if they are all cortex m3; that is the IP which they license from ARM.com. So maybe that is another reason for keeping the peripheral offset definitions and peripheral drivers separate and out of the compiler.

Geoffrey

For the cortex-m3 parts, one standard run-time is sufficient for all cortex parts, as their core systems are defined enough to get into a main pascal routine with the same code.

I'm specifically looking at Stellaris right now, specifically the Fury line of controllers, which is the largest line thus far.

However, in reviewing the Stellaris lineup - ALL Stellaris parts have their peripherals mapped out at exactly the same locations. Which means that 1 peripheral / register definition file could be used for all Stellaris parts. The confusion on this would be that symbols would exist for peripherals that might not exist for a specifically chosen part. I'm just peeking around at other vendor's product lines to see how much work would be involved - and also trying to make things as generic as possible for re-use.

There are 180+ Stellaris parts currently active, of which 79 are Fury class parts. Of the Fury class parts, there are 8 possible combinations of FLASH and SRAM amounts. I'm looking to put all 79 parts into the table of controllers, HOWEVER, each part will reference a unit specific the same controller unit file. I'm looking to change cpuinfo.pas to a structure, and part of that structure will be the FLASH and SRAM configurations, so that t_embed.pas won't even need a gazillion case() statements to generate the link info.

Once done with Fury class, I would move on to STM32 - as I have those available for ready use as well.

When STM32 and part of Stellaris have been created, a good framework should be in place to more easily add more vendors and/or parts.

________________________________

Not sure what you are saying here, almost none of the peripherals are the same from vendor to vendor. With the cortex-m3 the systick timer and the VNIC for example are from ARM, sure, but the majority of the items you are going to use timers, dma, pwm, gpio, clocks and enables, etc are vendor specific and vastly different from vendor to vendor. Within a vendor they are very similar if not the same but from ti to st most of the items are not compatible, likewise from ti to lpc/nxp or ti to atmel, etc.

Normally these are libraries and not buried in the compiler proper, I agree with that. Perhaps that is what you were saying and I misunderstood.

And as with libraries you can take them or leave them, that would want to be the case here (without having to dig into the compiler proper). Would need to roll your own target to avoid/modify a library. Ideally with the compiler you want to specify the arm core to take advantages of instructions each newer core supports. Not use them to tie to boards or systems.

I was hoping for thumb support but I now see that the choices are limited to arm and thumb+thumb2 (without any separation between thumb and thumb2). Actually thumb2 wasnt working for me, I got an arm+thumb2 mix, so I will ride this along for a while and see what comes up, otherwise limit my use to ARM targets, or start working on a thumb backend. Adding backends as well as arm embedded are of interest to me so I may work on a little of both.

So far it seems to be very straight forward to add a platform/device to fpc arm embedded, so if the stock support is too bulky or confusing individuals can cherry pick items they want and make their own simpler target.

Actually what we definitely need here in the near term is an arm generic target and a thumb2 generic target that does not have any of the vendor specific items in it, perhaps not even core specific peripherals.

I understand this is a work in progress and sorting everything out will take some time.

David

Why thumb support? The choices are indeed currently only either ARM or Thumb2(which is Thumb+32 bit extensions). Thumb2 is a variable length instruction set that looks like an arm+thumb mix, so I guarantee you that it works :)

The thumb2 is meant to support Cortex M3 devices (STM32, Stellaris, etc.) AFAIK
- the mixing of modes is not currently an option.

________________________________

I'm not sure how FPC should handle the peripherals, but I don't think it should be at the compiler level. Even if the part I'm using has, for instance, an ADC, if I'm not using it I do not want support for it built in to my app. With what I use currently (IAR C) I uncomment a #define for each peripheral I want to add support for. I'm sure something similar can be done for FPC at the unit level.

right, when I build for stellaris or stm32f103re I get the cortex-m like vector table that uses arm 32 bit instruction startup code that branches to a pascalmain that is thumb2. something that wont execute on hardware. Had it been a thumb target with a traditional exeception table that would have been good and in fact desirable for some platforms (nintendo gba for example). but the arm/thumb2 combination doesnt mix very well.

Maybe I need to re-try everything from scratch to see if I skipped a step or left out something and specified the wrong target or cpu.

Note you are giving up a stack location by using addresses in the form 0x10007FFC instead of 0x10008000. Minor point but it stands out in the binary.

This is all clearly a work in progress, I understand that...

David

I am rapidly seeing the problem, the linker script is hardcoded both by family (ARM as a whole) and by target. So for example if you wanted a ram-only ARM generic target, you are in trouble, or if you wanted a flash/ram target arm generic target you are in trouble. You have to override the compiled in maps. Once you get target specific compiled in memory maps then the compiled in register addresses make sense. At that point do the libraries, pll init, timers, etc make sense?

David

thumb2 is an extension to thumb not arm, you can mix thumb and arm in T variants like the v4T v5T and anything after that v6 on up, except for the cortex-m variants which are thumb+thumb2 only and cannot execute ARM 32 bit instructions (yes thumb2 32 bit thumb extensions but nothing from the ARM instruction set).

Here is an example of the problem I am seeing:

took a clean copy from svn

svn co http://svn.freepascal.org/svn/fpc/trunk fpc

cd fpc

make clean buildbase installbase CROSSINSTALL=1 OS_TARGET=embedded CPU_TARGET=arm INSTALL_PREFIX=/fpcarm

---- test.pp ----
procedure Wait(d : dword);
   begin
   while d0 do
     dec(d);
end;
begin
   while true do
     begin
         Wait($20000);
     end;
end.
---- test.pp ----

./compiler/ppcrossarm -Parm -Tembedded -Wpstm32f103re -Cpcortexm3 test.pp Free Pascal Compiler version 2.7.1 [2011/08/20] for arm Copyright (c) 1993-2011 by Florian Klaempfl and others Target OS: Embedded
Compiling test.pp
Assembling program
Linking test
/opt/embarm/arm-embedded-ld: warning: library search path "/usr/local/lib/fpc/2.7.1/units/arm-embedded/rtl/" is unsafe for cross-compilation
14 lines compiled, 0.0 sec

then dumped the binary:

08000000 <_START-0x158>:
8000000: 2000fffc strdcs pc, [r0], -ip
8000004: 08000405 stmdaeq r0, {r0, r2, sl}
8000008: 08000405 stmdaeq r0, {r0, r2, sl}
800000c: 08000405 stmdaeq r0, {r0, r2, sl}
8000010: 08000405 stmdaeq r0, {r0, r2, sl}
8000014: 08000405 stmdaeq r0, {r0, r2, sl}
8000018: 08000405 stmdaeq r0, {r0, r2, sl}
...
08000194 <PASCALMAIN>:
8000194: 46ec mov ip, sp
8000196: e92d 4800 stmdb sp!, {fp, lr}
800019a: f1ac 0b04 sub.w fp, ip, #4
800019e: b08a sub sp, #40 ; 0x28
80001a0: f000 f844 bl 800022c <FPC_INITIALIZEUNITS> 80001a4: e004 b.n 80001b0 <PASCALMAIN+0x1c>
80001a6: bf00 nop
80001a8: f44f 3000 mov.w r0, #131072 ; 0x20000
80001ac: f7ff ffd8 bl 8000160 <P$PROGRAM_WAIT$LONGWORD> 80001b0: e7fa b.n 80001a8 <PASCALMAIN+0x14>
80001b2: f000 f8ff bl 80003b4 <FPC_DO_EXIT>
80001b6: 46dd mov sp, fp
80001b8: b001 add sp, #4
80001ba: e91d 8800 ldmdb sp, {fp, pc}
80001be: bf00 nop
...
08000404 <STM32F103__FPC_START>:
8000404: e59f103c ldr r1, [pc, #60] ; 8000448 <STM32F103__FPC_START+0x44> 8000408: e59f203c ldr r2, [pc, #60] ; 800044c <STM32F103__FPC_START+0x48> 800040c: e59f303c ldr r3, [pc, #60] ; 8000450 <STM32F103__FPC_START+0x4c> 8000410: e1520003 cmp r2, r3
8000414: 94910004 ldrls r0, [r1], #4

First off 0x08000405 implies a thumb target but it is not thumb code, it is arm code so 0x08000404 would be correct but that is still wrong because cores with that vector table (cortex-m) cannot execute arm instructions.

Looking at that first instruction in the reset handler

08000404 <STM32F103__FPC_START>:
8000404: e59f103c ldr r1, [pc, #60] ; 8000448 <STM32F103__FPC_START+0x44>

IPUBWL
1110 01011001 r15, r1, 0x03C

And that was properly decoded by objdump, immediate offset rn+offset12, load, word sized, etc.
PC is 0x800040C at that time so load address is 0x800040C+0x03C = 0x8000448

You can tell both by 32 bit numbers in the dump but the dominance of an 0xE as the first nibble also implies these are arm instructions not thumb (need to see a long chunk of code to see the pattern). Had they been thumb instructions but decoded wrong by the disassembler then the first and fourth nibbles would have been dominated by like 6's and 7's or at least would stand out compared to the other
nibbles.

if we decode this as thumb/thumb2

0xE59F

//B(2) unconditional branch
     if((inst&0xF800)==0xE000)
     {
         rb=(inst>>0)&0x7FF;
         if(rb&(1<<10)) rb|=(~0)<<11;
         rb<<=1;
         rb+=pc;
         rb+=2;
         write_register(15,rb);
         return(0);
     }

1110010110011111

11100 10110011111

...11111110110011111
...111111101100111110
...11 1111 1011 0011 1110

pc = 0x405+4 = 0x409
pc + 0x...FFB3E =
0x409 - (0x4C1 + 1) = 0x7FFFF47

Unconditional branch to 0x07FFFF47 so it is a valid instruction, but doesnt make much sense

This does though, the start code from stm32f103.pp

.globl _start
.text
_start:

	// Copy initialized data to ram
	ldr r1,.L_etext
	ldr r2,.L_data
	ldr r3,.L_edata

.Lcopyloop:
cmp r2,r3
ittt ls
ldrls r0,[r1],#4
strls r0,[r2],#4
bls .Lcopyloop

The instructions the assembler was able to encode it did:

8000404: e59f103c ldr r1, [pc, #60]
8000408: e59f203c ldr r2, [pc, #60]
800040c: e59f303c ldr r3, [pc, #60]
8000410: e1520003 cmp r2, r3
8000414: 94910004 ldrls r0, [r1], #4
....
8000448: 08000468 stmdaeq r0, {r3, r5, r6, sl}
800044c: 20000000 andcs r0, r0, r0
8000450: 20000048 andcs r0, r0, r8, asr

0x08000468 is the word aligned address for the end of the text segment and 0x20000000 the beginning of text for this example so that is correct as well.

and interestingly the ittt ls instruction is discarded.

The code from stm32f103.pp

ldr r1,.L_etext
ldr r2,.L_data
ldr r3,.L_edata
.Lcopyloop:
cmp r2,r3
ittt ls
ldrls r0,[r1],#4
strls r0,[r2],#4
bls .Lcopyloop

when assembled should look like this

00000000 <.text>:
0: 4904 ldr r1, [pc, #16] ; (14 <.text+0x14>) 2: 4a05 ldr r2, [pc, #20] ; (18 <.text+0x18>) 4: 4b05 ldr r3, [pc, #20] ; (1c <.text+0x1c>) 6: 429a cmp r2, r3
8: bf9e ittt ls
a: f851 0b04 ldrls.w r0, [r1], #4
e: f842 0b04 strls.w r0, [r2], #4
12: e7f8 bls.n 6 <.text+0x6>
14: 00000001 andeq r0, r0, r1
18: 00000002 andeq r0, r0, r2
1c: 00000003 andeq r0, r0, r3

with different addresses of course...when assembled for thumb.

So it doesnt look like that is happening

Pascal main is definitely thumb+thumb2.

08000194 <PASCALMAIN>:
8000194: 46ec mov ip, sp
8000196: e92d 4800 stmdb sp!, {fp, lr}
800019a: f1ac 0b04 sub.w fp, ip, #4
800019e: b08a sub sp, #40 ; 0x28

More info about my setup:

svn info

URL: http://svn.freepascal.org/svn/fpc/trunk
Repository Root: http://svn.freepascal.org/svn/fpc Repository UUID: 3ad0048d-3df7-0310-abae-a5850022a9f2 Revision: 18278
Node Kind: directory
Schedule: normal
Last Changed Author: florian
Last Changed Rev: 18278
Last Changed Date: 2011-08-19 18:06:52 -0400 (Fri, 19 Aug 2011)

Ubuntu 10.4 or something like that 64 bit host.
Linux dwelch-desktop 2.6.32-33-generic #72-Ubuntu SMP Fri Jul 29 21:07:13 UTC 2011 x86_64 GNU/Linux

fpc is what you apt-get so probably a little behind but stable in the eyes of ubuntu or debian.

fpc
Free Pascal Compiler version 2.4.0-2ubuntu1.10.04 [2011/06/17] for x86_64 Copyright (c) 1993-2009 by Florian Klaempfl
/usr/lib/fpc/2.4.0/ppcx64 [options] <inputfile> [options] Put + after a boolean switch option to enable it, - to di

GNU assembler (Sourcery G++ Lite 2011.03-42) 2.20.51.20100809 Copyright 2010 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or later. This program has absolutely no warranty.
This assembler was configured for a target of `arm-none-eabi'.

So what did I do wrong? and what is the unsafe thing about?

Thanks,
David

It implies thumb mode, which is the only valid mode on Cortex-M3

The problem is that you are using an RTL built for ARM. That's what the warning is about. You installed the compiler in /fpcarm, but it's using units from /usr/local/lib/fpc/2.7.1/units/arm-embedded/rtl/

A correctly compiled unit would look like this:
00000000 <STM32F103__FPC_START>:
0: f8df 1034 ldr.w r1, [pc, #52] ; 38
<STM32F103__FPC_START+0x38>
4: 4a0d ldr r2, [pc, #52] ; (3c <STM32F103__FPC_START+0x3c>)
6: 4b0e ldr r3, [pc, #56] ; (40 <STM32F103__FPC_START+0x40>)
8: 429a cmp r2, r3
a: bf9e ittt ls

Ahhhh! that makes sense. I assume that is either leftover from a prior build? And how do I get a new/fresh build to look in the right place?

If I remove the offending fpc/2.7.1 directory and rebuild. (without trying to change the prefix) it puts the same stuff back in that directory:

/opt/embarm/arm-embedded-ld: warning: library search path "/usr/local/lib/fpc/2.7.1/units/arm-embedded/rtl/" is unsafe for cross-compilation

Am I doing this wrong?

make clean buildbase installbase CROSSINSTALL=1 OS_TARGET=embedded CPU_TARGET=arm

If I change it to this?

make clean buildbase installbase CROSSINSTALL=1 OS_TARGET=embedded CPU_TARGET=cortexm3

and provide the necessary cortexm3-embedded-* tools.

make: -iVSPTPSOTO: Command not found
make: -iSP: Command not found
make: -iTP: Command not found
make: -iSO: Command not found
make: -iTO: Command not found
Makefile:203: *** The Makefile doesn't support target cortexm3-embedded, please run fpcmake first. Stop.

Thanks,
David

> "/usr/local/lib/fpc/2.7.1/units/arm-embedded/rtl/" is unsafe for > cross-compilation

Ok, not a full answer yet, but ...

Also have a fresh svn tree, built and got similar results.

Redirected build output to a text file, copied and pasted the line compiling unitstr file to batch file. ADDED -Cpcortexm3 and rebuilt.

Disassembled the resulting object file and got:

stm32f103.o: file format elf32-littlearm

Disassembly of section .text.n_stm32f103__fpc_haltproc:

00000000 <STM32F103__FPC_HALTPROC>:
0: e7fe b.n 0 <STM32F103__FPC_HALTPROC> 2: 46f7 mov pc, lr

Disassembly of section .text.n_stm32f103__fpc_start:

00000000 <STM32F103__FPC_START>:
0: f8df 1034 ldr.w r1, [pc, #52] ; 38 <STM32F103__FPC_START+0x38>
4: 4a0d ldr r2, [pc, #52] ; (3c
<STM32F103__FPC_START+0x3c>)
6: 4b0e ldr r3, [pc, #56] ; (40
<STM32F103__FPC_START+0x40>)
8: 429a cmp r2, r3
a: bf9e ittt ls
c: f851 0b04 ldrls.w r0, [r1], #4
10: f842 0b04 strls.w r0, [r2], #4
14: e7f8 bls.n 8 <STM32F103__FPC_START+0x8> 16: 4906 ldr r1, [pc, #24] ; (30 <STM32F103__FPC_START+0x30>)
18: 4a06 ldr r2, [pc, #24] ; (34 <STM32F103__FPC_START+0x34>)
1a: f04f 0000 mov.w r0, #0
1e: 4291 cmp r1, r2
20: bf9c itt ls
22: f841 0b04 strls.w r0, [r1], #4
26: e7fa bls.n fffffff8 <PASCALMAIN+0xfffffff8> 28: f7ff bffe b.w 0 <PASCALMAIN>
2c: f7ff bffe b.w 0 <STM32F103__FPC_START> ...
44: 00000048 .word 0x00000048
48: 46f7 mov pc, lr
4a: 46f7 mov pc, lr

This looks more like what I would expect for Thumb mode, so it's a build problem where the cpu is not getting set to Thumb2 mode when it builds the Thumb2 RTL files.

John

________________________________

David Welch wrote

Ahhhh! that makes sense. I assume that is either leftover from a prior build? And how do I get a new/fresh build to look in the right place?

It's installed in /fpcarm. This directory should contain a bin and units directory. You simply need to change your main fpc.cfg file to match those settings. I don't know precisely how that would be done on a unix system.

Maybe it would even install directly to your current install directory, if you just run this?
make buildbase OS_TARGET=embedded CPU_TARGET=arm CROSSOPT="-Cpcortexm3" CROSSINSTALL=1
sudo make installbase OS_TARGET=embedded CPU_TARGET=arm CROSSOPT="-Cpcortexm3" CROSSINSTALL=1

On a side note, I find it strange that it even accepts your old leftover files. I thought the linker normally would complain about interwork stuff

You are right, of course. I have not looked at the data for other than Stellaris devices, I just generalised from the ARM TRM.

Normally these are libraries and not buried in the compiler proper, I agree with that. Perhaps that is what you were saying and I misunderstood.

not quite, but it is my aspiration :-)

The approach used in coide is quite interesting. Have a look on coocox.org. They have it down to box ticking.

Actually what we definitely need here in the near term is an arm generic target and a thumb2 generic target that does not have any of the vendor specific items in it, perhaps not even core specific peripherals.

I agree.

I understand this is a work in progress and sorting everything out will take some time.

Unfortunately the discussion is rather torn between the basic simplicity camp and the portmanteau camp. I rather think the latter is more suitable for a commercial company which can afford the maintenance, otherwise it is always out-of-date. Keeping up with new ARM cores is perhaps enough to do already.

Geoffrey.

As interesting is that it will assemble thumb2 code as arm code and not fail/stop during that step in the build.

Thanks for the help, will try that.

David

As part of my table-ization of cpuinfo.pas, I am including a generic part for each (no code published for this yet.) The caveat to this is that FLASH size and SRAM sizes are just set to extremely large (1 MB each for now). Which means if the code size exceeds the space of the device - the compiler/linker will not catch the overflow of the available resource. (Running objsize on the ELF file will display the sizes - so I just run that after every successful compile.)

Also, still testing, but I have the "interrupt" reserved word working (more or less, more testing needed.) This takes the interrupt codeword with an integer. The integer is the offset into the vectors table. If no interrupt is provided for the given address, it defaults to DefaultHandler in the startup file - which is just a continual loop - so one can breakpoint on it. (This can be enabled / disabled via a define in the source.) This is should only be enabled for the embedded target - but I need to double check to ensure that is the case.

Fortunately, I have a few days off before the school semester starts - so I will be working on this quite heavily over the next few days.

John

________________________________

In our previous episode, John Clymer said:

I don't use embedded arm, but on other microcontrollers, bootloaders are often also at the end of the flash. The main reason for this is to avoid having to modify the linker file for normal programs (to switch between bootloadable and not). For that, you need to have the exact amount of flash in your CPU profile.

John Clymer wrote

As part of my table-ization of cpuinfo.pas, I am including a generic part for each (no code published for this yet.) The caveat to this is that FLASH size and SRAM sizes are just set to extremely large (1 MB each for now). Which means if the code size exceeds the space of the device - the compiler/linker will not catch the overflow of the available resource. (Running objsize on the ELF file will display the sizes - so I just run that after every successful compile.)

As I pointed out, this will always fail because the stacktop is set beyond the available ram. It will cause an exception I think. How do you propose to be able to set the actual ram top for the generic part, or am I missing something?

Also, still testing, but I have the "interrupt" reserved word working (more or less, more testing needed.) This takes the interrupt codeword with an integer. The integer is the offset into the vectors table. If no interrupt is provided for the given address, it defaults to DefaultHandler in the startup file - which is just a continual loop - so one can breakpoint on it. (This can be enabled / disabled via a define in the source.) This is should only be enabled for the embedded target - but I need to double check to ensure that is the case.

This is a useful development; ideally the integer would be backed by an enumeration as it is a big table. One thing which I did find missing was the interrupt enable and disable assembler codes, so I patched them with data bytes hidden in functions. The keil C compiler does not like these if you link to units doing this (throws a data/code wobbly). See the file attached to bug tracker ID0017365 for how I hacked interrupts.

Fortunately, I have a few days off before the school semester starts - so I will be working on this quite heavily over the next few days.

all power to your elbow...

Geoffrey

The CPS* instruction with the correct operand syntax was added in #18334

SVN trunk already has experimental support for the interrupt keyword. It's enabled with FPC_HAS_SYSTEMS_INTERRUPT_TABLE in fpcdefs.inc. I discovered a small bug with the current implementation which is fixed with the attached patch(which also includes some other stuff... the bugfix is in ncgutil. It didn't search the program file for interrupt handlers before)

I found FPC_HAS_SYSTEMS_INTERRUPT_TABL, enabled it - but it was still broken for Thumb2 (stellaris, stm32).

For Thumb2, it was broken in the following ways:

1) Stack_top should be placed at vector 0.
2) Each address should have the LSB set - to "force" Thumb mode when the PC gets loaded with that value.

I defined FPC_HAS_SYSTEMS_INTERRUPT_TABLE a little further down - so that was only enabled on ARM and AVR (trying not to break other things...)

I also have some added logic in ncgutil - for M3 devices - to place the stack_top into vector 0, then place handlers for vectors 1 to TOP. The WriteVector routine for Thumb also adds an offset of 1 to each vector - so as to force Thumb mode upon load to PC.

John

________________________________

I disagree, but I guess that's a question of interpretation. I don't think it's really a vector. So currently vector 0 is for the reset vector at address 0x80000004, and _stack_top is placed in front of the table

2) Each address should have the LSB set - to "force" Thumb mode when the PC gets loaded with that value.

That's the linkers job. And it is handled correctly currently as long as the labels where they are pointing to are marked with the .thumb_func directive(as they are when using -Cpcortexm3)

You shouldn't add anything to get thumb vectors, as I explained further up.

John

Ramtop for a generic part defined as having 1 MB of SRAM

In the generic startup file, place an 8 KB array, inside a chunk of assembly, set stack_top = top of the array. So long as the program doesn't exceed the SRAM space AND the program doesn't exceed the array size - no problem. (The actual size will have to be debated a bit, I think 8KB should suffice - but this would preclude small devices from being used this way.)

________________________________