Lpc2000

I'm using LPC2106 in my application with gcc 4.0.0. I've compiled all my sources in ARM mode and it works fine, but for IAP routine call I had to use -mthumb-interwork flag for gcc. After this, my application will crash in few sec (not on IAP call, but inside IRQ function). The problem is in IRQ routine. When I'll make call of function inside ISR, gcc will generate wrong code without returning address. If i'll not use -mthumb-interwork flag, the code is compiled correctly.

        Michal


[Non-text portions of this message have been removed]

On Mon, 18 Jul 2005 16:22:11 +0200, Michal Krestan wrote:

>I'm using LPC2106 in my application with gcc 4.0.0. I've compiled all
>my sources in ARM mode and it works fine, but for IAP routine call I
>had to use -mthumb-interwork flag for gcc. After this, my application
>will crash in few sec (not on IAP call, but inside IRQ function). The
>problem is in IRQ routine. When I'll make call of function inside ISR,
>gcc will generate wrong code without returning address. If i'll not
>use -mthumb-interwork flag, the code is compiled correctly.
>Michal


Check the IAP programming examples (LPC-FlashRoutines-18Feb05.zip)in the
files section of this mailing list on Yahoo.  The routines can be compiled
and run in ARM mode.


Regards
-Bill Knight
R O SoftWare &
http://www.theARMPatch.com

Michal Krestan <krestan@...> schrieb am Mon, 18 Jul 2005 16:22:11 +0200:

>
> I'm using LPC2106 in my application with gcc 4.0.0. I've compiled all my 
> sources in ARM mode and it works fine, but for IAP routine call I had to 
> use -mthumb-interwork flag for gcc. After this, my application will 
> crash in few sec (not on IAP call, but inside IRQ function). The problem 
> is in IRQ routine. When I'll make call of function inside ISR, gcc will 
> generate wrong code without returning address. If i'll not use 
> -mthumb-interwork flag, the code is compiled correctly.

0) Why do you use ARM mode ? (IMHO it has no benefit despite some rare
situations)
1) Do you use this flag for all stages (i.e. compile,assemble,link) ?
2) Do you have the .glue7 and .glue7t sections in your linker script ?


-- 
42Bastian Schick

Hi,

just a brief comment about ARM mode and THUMB mode. Depending on the
memory architecture and access time ARM mode can be good (faster) or
very bad (larger and slower).

If you have a 16-bit memory interface or worse a 16-bit Flash
interface, use Thumb mode under all circumstances! It is faster and
smaller code. 

If you have a 32-bit interface and any kind of waitstates associated
with it, Thumb is probably still faster and always smaller. A 32-bit
RAM with zero watistates though will give you up to 30% higher
performance in ARM mode compared to Thumb with the up to 30% code size
penalty. 

Using busses like the LPC2106 has them (128-bit to the Flash), ARM
mode will definitely be faster. The same applies as for the RAM above.
Using ARM mode for a complete program would be waste of code memory
space, using ARM mode in interrupt service routines (that are entered
in ARM mode anyhow) is a smart idea with the Philips devices. 

Be aware though that most other embedded Flashs will not work faster
in ARM mode from Flash because of limited bus width (e.g. Atmel, Oki)

Hope this clarifies why ARM mode is benefitial

Cheers, Bob

--- In lpc2000@yahoogroups.com, 42Bastian Schick <bastian42@m...> wrote:
> Michal Krestan <krestan@h...> schrieb am Mon, 18 Jul 2005 16:22:11
+0200:
> 
> >
> > I'm using LPC2106 in my application with gcc 4.0.0. I've compiled
all my 
> > sources in ARM mode and it works fine, but for IAP routine call I
had to 
> > use -mthumb-interwork flag for gcc. After this, my application will 
> > crash in few sec (not on IAP call, but inside IRQ function). The
problem 
> > is in IRQ routine. When I'll make call of function inside ISR, gcc
will 

> > generate wrong code without returning address. If i'll not use 
> > -mthumb-interwork flag, the code is compiled correctly.
> 
> 0) Why do you use ARM mode ? (IMHO it has no benefit despite some rare
> situations)
> 1) Do you use this flag for all stages (i.e. compile,assemble,link) ?
> 2) Do you have the .glue7 and .glue7t sections in your linker script ?
> 
> 
> -- 
> 42Bastian Schick

----- Original Message ----- 
From: "42Bastian Schick" <bastian42@...>
To: <lpc2000@yahoogroups.com>
Sent: Monday, July 18, 2005 5:08 PM
Subject: Re: [lpc2000] gcc problem


> Michal Krestan <krestan@...> schrieb am Mon, 18 Jul 2005 16:22:11 +0200:
>
>>
>> I'm using LPC2106 in my application with gcc 4.0.0. I've compiled all my
>> sources in ARM mode and it works fine, but for IAP routine call I had to
>> use -mthumb-interwork flag for gcc. After this, my application will
>> crash in few sec (not on IAP call, but inside IRQ function). The problem
>> is in IRQ routine. When I'll make call of function inside ISR, gcc will
>> generate wrong code without returning address. If i'll not use
>> -mthumb-interwork flag, the code is compiled correctly.
>
> 0) Why do you use ARM mode ? (IMHO it has no benefit despite some rare
> situations)
I've started my project in ARM mode by modification of example code for 
LPC2106 and it still remains in my project:-)

> 1) Do you use this flag for all stages (i.e. compile,assemble,link) ?
yes

> 2) Do you have the .glue7 and .glue7t sections in your linker script ?
yes, I'm using default ld and makefile from examples included in WinARM gcc. 
I've only removed comment character before mthumb-interwork in makefile and 
after this modification my code will crash.

        Michal

>
>
> -- 
> 42Bastian Schick
>
>

In the processors supporting both ARM and Thumb
(T-variants), all exceptions (interrupts, aborts) 
must be handled in ARM mode.

--- lpc2100_fan <lpc2100_fan@...> wrote:

> just a brief comment about ARM mode and THUMB mode.


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

Almost,
they will be entered in ARM mode but you can switch within the
interrupt service routine to Thumb and it makes even sense to do this
with a 16-bit bus system

Bob

--- In lpc2000@yahoogroups.com, Mike Nelson <m1k3n3ls0n@y...> wrote:

> In the processors supporting both ARM and Thumb
> (T-variants), all exceptions (interrupts, aborts) 
> must be handled in ARM mode.
> 
> --- lpc2100_fan <lpc2100_fan@y...> wrote:
> 
> > just a brief comment about ARM mode and THUMB mode.
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com

There is a very valid reason why you might want to do this.

If all your ARM and interworking stuff is in assembler files then you 
can often write all your C code in straight Thumb and use Thumb 
libraries. That makes for a pure Thumb solution (except for a few 
lines of assembler) and means you have no interworking in thc 
libraries and C code. Result: potentially faster and smaller code.


 --- In lpc2000@yahoogroups.com, "lpc2100_fan" <lpc2100_fan@y...> 
wrote:
> Almost,
> they will be entered in ARM mode but you can switch within the
> interrupt service routine to Thumb and it makes even sense to do 
this

> with a 16-bit bus system
> 
> Bob
> 
> --- In lpc2000@yahoogroups.com, Mike Nelson <m1k3n3ls0n@y...> wrote:
> > In the processors supporting both ARM and Thumb
> > (T-variants), all exceptions (interrupts, aborts) 
> > must be handled in ARM mode.
> > 
> > --- lpc2100_fan <lpc2100_fan@y...> wrote:
> > 
> > > just a brief comment about ARM mode and THUMB mode.
> > 
> > 
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam?  Yahoo! Mail has the best spam protection around 
> > http://mail.yahoo.com

--- In lpc2000@yahoogroups.com, "Michal Krestan" <krestan@h...> wrote:
> 
> I'm using LPC2106 in my application with gcc 4.0.0. I've compiled
all my sources in ARM mode and it works fine, but for IAP routine call
I had to use -mthumb-interwork flag for gcc. After this, my
application will crash in few sec (not on IAP call, but inside IRQ
function). The problem is in IRQ routine. When I'll make call of
function inside ISR, gcc will generate wrong code without returning
address. If i'll not use -mthumb-interwork flag, the code is compiled
correctly.
> 
>         Michal
> 
> 
> [Non-text portions of this message have been removed]

Hello,

  I have used the IAP routines, and my application is ARM code entirely.
  Points to note: (page references to the document below)

    You have allowed space in the top of ram for IAP functions
(32bytes). page 231
    Once you start programming the flash, unless you have remapped the
 vectors to RAM, you must disable interrupts. Also, if you do not
disable interrupts, you must have your handler code in ram as well.
Remember the flash is not accessible while programming.

  When I am erasing/programming the flash, I disable the PLL, and the
MAM and also interrupts. After the operation these are all re-enabled.
  I have never had a problem, except that on the 2132, where the top
32k is a single sector. This meant I needed to use a sector near the
start of flash, in fact the second sector. The first is for startup,
vectors and any assembler functions, the second for a 4k configuration
area, and the third sector on is the rest of the code. This then meant
 making a hole in the linker file, which meant using named sections
for the startup and assembler routines.


UM10120
Volume 1: LPC213x User Manual
Rev. 01 â€" 24 June 2005 User manual


Dave

Dave <dgsomerton@...> schrieb am Tue, 19 Jul 2005 04:09:18 
-0000:

> --- In lpc2000@yahoogroups.com, "Michal Krestan" <krestan@h...> wrote:
>>
>> I'm using LPC2106 in my application with gcc 4.0.0. I've compiled
> all my sources in ARM mode and it works fine, but for IAP routine call
> I had to use -mthumb-interwork flag for gcc. After this, my
> application will crash in few sec (not on IAP call, but inside IRQ
> function). The problem is in IRQ routine. When I'll make call of
> function inside ISR, gcc will generate wrong code without returning
> address. If i'll not use -mthumb-interwork flag, the code is compiled
> correctly.

Please show us an example and cross verify it with gcc 3.4.x

-- 
42Bastian Schick

lpc2100_fan <lpc2100_fan@...> schrieb am Mon, 18 Jul 2005 16:03:08 
-0000:

> If you have a 16-bit memory interface or worse a 16-bit Flash
> interface, use Thumb mode under all circumstances! It is faster and
> smaller code.

Agree.

> If you have a 32-bit interface and any kind of waitstates associated
> with it, Thumb is probably still faster and always smaller. A 32-bit
> RAM with zero watistates though will give you up to 30% higher
> performance in ARM mode compared to Thumb with the up to 30% code size
> penalty.

Don't agree. At least not fully. If the CPU has a small cache (4 bytes),
then it fetches 2 thumb insns with one bus access.

I looked a lot into generated assembly code to check if I should use
Thumb or ARM, and in 99% of the cases there is no real benefit of the
ARM mode.
I even tried to re-write parts of the RTOS - I write for living - in ARM
mode and found that there is only in very small cases a benefit (and there
of course I use it).

> Using busses like the LPC2106 has them (128-bit to the Flash), ARM
> mode will definitely be faster. The same applies as for the RAM above.
> Using ARM mode for a complete program would be waste of code memory
> space, using ARM mode in interrupt service routines (that are entered
> in ARM mode anyhow) is a smart idea with the Philips devices.

In thumb-mode you can fetch up to 8 insns from flash instead of 4 ARM 
insns.
Giving the 30% you mentioned above, 8 thumb insns == 5.7 ARM insns.


-- 
42Bastian Schick

lpc2100_fan <lpc2100_fan@...> schrieb am Mon, 18 Jul 2005 16:03:08 
-0000:

> just a brief comment about ARM mode and THUMB mode. Depending on the
> memory architecture and access time ARM mode can be good (faster) or
> very bad (larger and slower).

2nd reply, just to make my opinion clearer:

My rule of thumb :-) is, smaller code results in faster code.
Therefor I use Thumb mode and compile with -Os.
But as every rule, there are exceptions like the following, which gives
nice code in ARM mode (though larger):

int f[100];
int v[100];
int a (void)
{
	int i;
	int sum = 0;
	for(i = 0; i < 100; ++i){
		sum += f [i]*v[i];
	}
	return sum;
}


-- 
42Bastian Schick

Hi Bastian,

may be there is one parameter missing in the equations we looked at 
so far. That parameter is "how many instructions are needed to 
perform a certain function?"

ARM mode provides instructions (conditional ones) that are not 
availble in Thumb mode. In the average you need approx. 7 ARM 
instructions to execute the same functionality as with 10 Thumb 
instructions. The bottleneck is not the fetch any more if you have a 
wide bus or 0 wait states, it is the number of instructions you need 
to execute. Executing an ARM instruction does not take longer than 
executing a Thumb instruction, so executing 7 ARM instructions is 
faster than executing 10 Thumb instructions but 10 Thumb instructions 
need less space in the Flash!

The other bottleneck, fetching the instructions so that CPU does not 
have to wait is only true when you execute from a Flash that can not 
keep up with the CPU execution cycles. If you can fetch the 
instructions no matter whether ARM or Thumb ten time faster than 
executing them, you will have to wait for the CPU.  It is the 
combination of zero waitstates for 32-bit accesses and the CPU speed 
in MHz (given the same ARM7 CPU) that determine the overall 
performance.

To verify your or my approach, I would recommend to execute some code 
from an internal RAM one time optimized for speed in ARM mode and one 
time optimized for size in Thumb mode. 

Running the same code with the same optimization rules on a LPC2106 
from Flash will give you almost identical results as running from 
RAM. If you do the same thing on devices with narrower busses, e.g. 
OKI and Atmel, the benefit for ARM evapurates, it will probably even 
turn into a speed loss.

The ARM mode is faster as long as the bus is not the bottleneck. 
Comparing the top speed from a LPC21xx running from Flash in ARM mode 
to a SAM7S also running from Flash in ARM mode will give you a 
significant difference. 

Bob.


--- In lpc2000@yahoogroups.com, 42Bastian Schick <bastian42@m...> 
wrote:
> lpc2100_fan <lpc2100_fan@y...> schrieb am Mon, 18 Jul 2005 16:03:08 
> -0000:
> 
> > If you have a 16-bit memory interface or worse a 16-bit Flash
> > interface, use Thumb mode under all circumstances! It is faster 
and
> > smaller code.
> 
> Agree.
> 
> > If you have a 32-bit interface and any kind of waitstates 
associated
> > with it, Thumb is probably still faster and always smaller. A 32-
bit
> > RAM with zero watistates though will give you up to 30% higher
> > performance in ARM mode compared to Thumb with the up to 30% code 
size
> > penalty.
> 
> Don't agree. At least not fully. If the CPU has a small cache (4 
bytes),
> then it fetches 2 thumb insns with one bus access.
> 
> I looked a lot into generated assembly code to check if I should use
> Thumb or ARM, and in 99% of the cases there is no real benefit of 
the
> ARM mode.
> I even tried to re-write parts of the RTOS - I write for living - 
in ARM
> mode and found that there is only in very small cases a benefit 
(and there
> of course I use it).
> 
> > Using busses like the LPC2106 has them (128-bit to the Flash), ARM
> > mode will definitely be faster. The same applies as for the RAM 
above.
> > Using ARM mode for a complete program would be waste of code 
memory
> > space, using ARM mode in interrupt service routines (that are 
entered
> > in ARM mode anyhow) is a smart idea with the Philips devices.
> 
> In thumb-mode you can fetch up to 8 insns from flash instead of 4 
ARM 

> insns.
> Giving the 30% you mentioned above, 8 thumb insns == 5.7 ARM insns.
> 
> 
> -- 
> 42Bastian Schick

lp fan's comments are pretty much in agreement with what I have 
observed, but I can't help stir the pot some:

> may be there is one parameter missing in the equations we looked at 
> so far. That parameter is "how many instructions are needed to 
> perform a certain function?"
> 
> ARM mode provides instructions (conditional ones) that are not 
> availble in Thumb mode. In the average you need approx. 7 ARM 
> instructions to execute the same functionality as with 10 Thumb 
> instructions. The bottleneck is not the fetch any more if you have a 
> wide bus or 0 wait states, it is the number of instructions you need 
> to execute. Executing an ARM instruction does not take longer than 
> executing a Thumb instruction, so executing 7 ARM instructions is 
> faster than executing 10 Thumb instructions but 10 Thumb 
instructions 
> need less space in the Flash!

Thumb instructions are actually an encoding of ARM instructions so 
every Thumb instruction is essentially mapped to an equivalent ARM 
instruction for execution.

There are a few operations that you cannot do in Thumb (eg msr etc), 
but for most code the biggest difference is that the ARM instructions 
have the condition field on all instructions while the Thumb 
instuctions only have these on branching.

As a general rule of thumb, Thumb code takes 65% the space of ARM 
code. That means that the Thumb needs 65%/50% = 1.3x the amount of 
instructions as ARM code and will need to execute them.


As with all such general rules of thumb, they can only be applied in 
very broad-brush terms and there are some corner cases:

* Sometimes the ARM mode conditional fileds are not used and this 
provides no advantage.
* Sometimes the ARM code can execute many times faster than Thumb. For 
example using the condition fields often mean that the CPU can 
continue execution with no branching. This saves a lot because 
branching breaks the pipeline.


> 
> The other bottleneck, fetching the instructions so that CPU does not 
> have to wait is only true when you execute from a Flash that can not 
> keep up with the CPU execution cycles. If you can fetch the 
> instructions no matter whether ARM or Thumb ten time faster than 
> executing them, you will have to wait for the CPU.  It is the 
> combination of zero waitstates for 32-bit accesses and the CPU speed 
> in MHz (given the same ARM7 CPU) that determine the overall 
> performance.
> 
> To verify your or my approach, I would recommend to execute some 
code 
> from an internal RAM one time optimized for speed in ARM mode and 
one 
> time optimized for size in Thumb mode. 
> 
> Running the same code with the same optimization rules on a LPC2106 
> from Flash will give you almost identical results as running from 
> RAM. If you do the same thing on devices with narrower busses, e.g. 
> OKI and Atmel, the benefit for ARM evapurates, it will probably even 
> turn into a speed loss.

Yes it does. Thumb tends to be faster on 16-bit buses.

As always, read the docs. The SAM7, for example, is pretty much 
optimised for Thumb.

> 
> lp fan's comments are pretty much in agreement with what I have 
> observed, but I can't help stir the pot some:
> 

Ditto on the pot-stirring, I do agree with the memory-width benefits 
of Thumb code that have been raised, but I wanted to mention that 
there is another factor to consider.

Thumb instructions have very limited access to registers outside the 
R0-R7 range, so for larger functions with lots of local variables 
you may find that ARM code causes fewer spills out to the stack - 
memory reads/writes are 2 and 3 times slower on ARM than data-
processing instructions even from zero waitstate memory, and the 
condition flags are not set by a load, potentially adding an extra 
instruction for testing the value loaded.

The quality of the compiler will make a huge difference in the 
relative merits of ARM and Thumb in this respect. I noticed that the 
allocation of variables to registers, and register reuse can be 
truly appalling in the gnu compiler, compared to the ARM compiler, 
but I will qualify that by saying that I'm sure gnu has improved 
over the past 18 months.

Peter.