Lpc2000

Perhaps I am asking a real simple question, but for the life of me I 
cannot find much information or example code on stack setup.  I'm 
trying to move my IAR code over to GNU, and of course the GNU syntax 
does not handle all of the ARM Asm coding.

In IAR they gave an example like this:

  mrs   r0,cpsr               /* Original PSR value  */
  bic   r0,r0,#MODE_BITS      /* Clear the mode bits */
  orr   r0,r0,#SVC_MODE       /* Set SVC mode bits   */
  msr   cpsr_c,r0             /* Change the mode     */
  ldr   sp,=SFE(SVC_STACK) & 0xFFFFFFF8  /* End of SVC_STACK */

The GNU compiler will take all of this - except for that last 
statement.  I have no idea what that "SFE" command is doing and 
neither does GNU apparently.  I can't even find anything on this in 
the ARM7 Instruction set manual.

What is this last statement doing, and what would be the correct 
equiv to use in GNU?

I've looked through the files here and I do not see many examples of 
detailed stack setup.  If anyone knows where there are more examples 
of "ld" scripts and init/boot/startup.s files it sure would be 
helpful.

Thanks,  Chris.

Hi Chris,

> Perhaps I am asking a real simple question, but for the life of me I 
> cannot find much information or example code on stack setup.  I'm 
> trying to move my IAR code over to GNU, and of course the GNU syntax 
> does not handle all of the ARM Asm coding.
> 
> In IAR they gave an example like this:
> 
>   mrs   r0,cpsr               /* Original PSR value  */
>   bic   r0,r0,#MODE_BITS      /* Clear the mode bits */
>   orr   r0,r0,#SVC_MODE       /* Set SVC mode bits   */
>   msr   cpsr_c,r0             /* Change the mode     */
>   ldr   sp,=SFE(SVC_STACK) & 0xFFFFFFF8  /* End of SVC_STACK */
> 
> The GNU compiler will take all of this - except for that last 
> statement.  I have no idea what that "SFE" command is doing and 
> neither does GNU apparently.  I can't even find anything on this in 
> the ARM7 Instruction set manual.
> 
> What is this last statement doing, and what would be the correct 
> equiv to use in GNU?

I'm doing a few quick tests on EWARM kickstart to see how the code/s[eed generation
really compares to GCC.
When I'm done shortly I'll have a look, I had changed the startup code anyway.

But I'd say off-the-cuff that SFE is an intrinsic (macro) to do something
with the lookup address of SVC_STACK.
Have a look around in your IAR docs under "intrinsics" or somesuch.

When I'm done with the tests, I'll have a look if you haven't figured it in the meantime.

-- Kris


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

Hi,

> In IAR they gave an example like this:
> 
>   mrs   r0,cpsr               /* Original PSR value  */
>   bic   r0,r0,#MODE_BITS      /* Clear the mode bits */
>   orr   r0,r0,#SVC_MODE       /* Set SVC mode bits   */
>   msr   cpsr_c,r0             /* Change the mode     */
>   ldr   sp,=SFE(SVC_STACK) & 0xFFFFFFF8  /* End of SVC_STACK */

> What is this last statement doing, and what would be the correct 
> equiv to use in GNU?

Can't  seem to find a reference to it, but I seem to recall that standard IAR syntax
is that SFE is something like :
Segment (Flash ?) End.

So, bascially ldr   sp, =SFE(SVC_STACK) & ....

loads the SP with the ABSOLUTE address of the END of SEGMENT SVC_STACK,
which is in RAM of course.

This would make sense, as you'd normally use a descending stack.
The & with 0xFFFFFFF8 is to align the stack address to an 8-byte
boundary. GNU has its own defines for that like .code x etc.

Else just ldr sp with the Start address of your (SVC Stack + The SVC Stack size).
(You'd want it to sit on top of RAM)

-- Kris


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

Thanks, I figured as much.  I found a couple of examples to download 
from ARM and they did it like this:

/* Setup the IRQ stack	*/
  mov  r0,#IRQ_MODE | I_Bit | F_Bit   /* IRQ_MODE, No Ints */
  msr  cpsr_c,r0                      /* Change the mode   */
  ldr  r13,=IRQ_STACK 	              /* End of IRQ_STACK  */

I assume that "r13" is the same as "sp" ?

They also have some RAM init code after stack setups.  I guess they 
are zeroing memory.  Do I need to zero RAM?  Does it really matter to 
anything?

Regarding IAR, I started out with that system and also MakeApp.  
After running into several bugs I am giving up and trying the GNU 
world.  It would spit out bad ELF files at times that my JTAG 
debugger could not load.  I ran into another bug where the compiler 
went into the weeds on a simple loop and then dropped every function 
call thereafter.  Bugs in MakeApp too.

They have a few nice extensions, such as the record structure into 
the bits of the regs. But all the bells, whistles, and optimizations 
in the world matter little when it keeps throwing bugs.  I could not 
trust it anymore.

Chris.

--- In lpc2000@yahoogroups.com, "sig5534" <sig5534@h...> wrote:

> I assume that "r13" is the same as "sp" ?

Yes.
 
> They also have some RAM init code after stack setups.  I guess they 
> are zeroing memory.  Do I need to zero RAM?  Does it really matter 
to 
> anything?

It zeroes the .bss section and copies initialization values for 
the .data section.  GCC assumes that the startup code does this for 
code like this:

int a;
int *pa;

which must be zero initialized according to the C standard.  GCC also 
places explicitly zero initialized variables in .bss:

int b = 0;
int *pb = NULL;

Variables explicitly initialized to other than zero are placed 
in .data:

int c = 1234;
int *pc = &c;

Your startup code should also have code to copy the initialization 
values for .data from flash to RAM.

If you write all the code of your program yourself, you may of course 
skip the startup initialization so that all globals/statics are 
indeterminate at startup.  But if you link in other code, such as 
standard C library functions, you better be absolutely sure that the 
indetermination of their statics/globals won't break anything.
 
If you are concerned with the speed of the startup initialization, 
you can speed it up by using LDM/STM to load/store e.g. 8 words at a 
time instead of the normal LDR/STR loop which only does 1 word at a 
time.  In the .ld file, you should then make the start and end of the 
sections 32-byte aligned instead of just 4-byte aligned.

If you have large arrays that you don't need or have time to zero 
initialize at startup, you can invent a special section name and put 
the variables into that section:

char buffer[10000] __attribute__ ((section ("my_noinit")));

and process the section appropriately in the .ld file.  In any case, 
prepare for a deep dive into the .ld file syntax...

And before deciding all this, first examine the linker map file to 
see the actual size of the sections.  

Karl Olsen

At 10:26 PM 12/28/04 +1100, you wrote:
> > What is this last statement doing, and what would be the correct
> > equiv to use in GNU?
>
>I'm doing a few quick tests on EWARM kickstart to see how the code/s[eed 
>generation
>really compares to GCC.
>When I'm done shortly I'll have a look, I had changed the startup code anyway.
>
>But I'd say off-the-cuff that SFE is an intrinsic (macro) to do something
>with the lookup address of SVC_STACK.
>Have a look around in your IAR docs under "intrinsics" or somesuch.

I suspect Kris is right, but I don't know the IAR syntax either.  There are 
startup examples in the files section.  Also the newlib-lpc has startup and 
ld examples ( http://www.aeolusdevelopment.com/  Just follow the download 
link).

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III

Karl, much thanks for your detailed info.

> Your startup code should also have code to copy the initialization 
> values for .data from flash to RAM.

Ok, how do I do that for GCC?  Got any examples?  Can you point me 
towards the doc?

> If you write all the code of your program yourself, you may of 
course 
> skip the startup initialization so that all globals/statics are 
> indeterminate at startup.  But if you link in other code, such as 
> standard C library functions, you better be absolutely sure that 
the 
> indetermination of their statics/globals won't break anything.

Does GCC spit out its own C init code?  If so where is the doc on 
this or the examples so I can see how to link this in?
 
> If you are concerned with the speed of the startup initialization,

No I'm not.  I just want something that works!  All of the examples I 
find involve somebody else's syntax like IAR or ARM which will not 
work for GCC.  I'm trying to figure out what I need for GCC to work!

There is so much doc to wade through for this GNU stuff, and so few 
examples, this is a slow painful learning curve.  Some decent 
examples would be a big help.  I expected that there would be some 
with the GNUARM files, but I sure cannot find many.

More info from an expert like yourself would be greatly appreciated!

Thanks,  Chris.

The UT040803A.zip in the File section has a wonderful example for
startup with GCC.

--- In lpc2000@yahoogroups.com, "sig5534" <sig5534@h...> wrote:

> 
> Karl, much thanks for your detailed info.
> 
> > Your startup code should also have code to copy the initialization 
> > values for .data from flash to RAM.
> 
> Ok, how do I do that for GCC?  Got any examples?  Can you point me 
> towards the doc?
> 
> > If you write all the code of your program yourself, you may of 
> course 
> > skip the startup initialization so that all globals/statics are 
> > indeterminate at startup.  But if you link in other code, such as 
> > standard C library functions, you better be absolutely sure that 
> the 
> > indetermination of their statics/globals won't break anything.
> 
> Does GCC spit out its own C init code?  If so where is the doc on 
> this or the examples so I can see how to link this in?
>  
> > If you are concerned with the speed of the startup initialization,
> 
> No I'm not.  I just want something that works!  All of the examples I 
> find involve somebody else's syntax like IAR or ARM which will not 
> work for GCC.  I'm trying to figure out what I need for GCC to work!
> 
> There is so much doc to wade through for this GNU stuff, and so few 
> examples, this is a slow painful learning curve.  Some decent 
> examples would be a big help.  I expected that there would be some 
> with the GNUARM files, but I sure cannot find many.
> 
> More info from an expert like yourself would be greatly appreciated!
> 
> Thanks,  Chris.

> The UT040803A.zip in the File section has a wonderful example for
> startup with GCC.

FINALLY!  Thank you very much.  This is exactly what I was looking 
for.  Even has a decent makefile.  I wish you guys would rename this 
something obvious like "Full Featured GNU ARM Example".  That would 
have saved me a lot of searching, downloading, and hunting work.

Thanks,  Chris.

Chris,

Try the uCOS-II port & example codes for LPC... It has
startup & basic infrastructure code (which build with
GCC or ARM tools (SDT or ADS)) & supports ARM,
ARM-THUMB & THUMB mode images.

http://www.geocities.com/michaelanburaj/downloads/arm_ucos_1.14.zip

Cheers,
-Mike.

--- sig5534 <sig5534@...> wrote:

> 
> > The UT040803A.zip in the File section has a
> wonderful example for
> > startup with GCC.
> 
> FINALLY!  Thank you very much.  This is exactly what
> I was looking 
> for.  Even has a decent makefile.  I wish you guys
> would rename this 
> something obvious like "Full Featured GNU ARM
> Example".  That would 
> have saved me a lot of searching, downloading, and
> hunting work.
> 
> Thanks,  Chris.
> 
> 
> 
> 



	
		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - You care about security. So do we. 
http://promotions.yahoo.com/new_mail

Could you send the arm_ucos_1.14.zip to me? ( I could not download from there).
 
I am using LPC2210. I 
 
Thanks.

Michael Anburaj <embeddedeng@yahoo.com> wrote:
Chris,

Try the uCOS-II port & example codes for LPC... It has
startup & basic infrastructure code (which build with
GCC or ARM tools (SDT or ADS)) & supports ARM,
ARM-THUMB & THUMB mode images.

http://www.geocities.com/michaelanburaj/downloads/arm_ucos_1.14.zip

Cheers,
-Mike.

--- sig5534 <sig5534@...> wrote:

> 
> > The UT040803A.zip in the File section has a
> wonderful example for
> > startup with GCC.
> 
> FINALLY!  Thank you very much.  This is exactly what
> I was looking 
> for.  Even has a decent makefile.  I wish you guys
> would rename this 
> something obvious like "Full Featured GNU ARM
> Example".  That would 
> have saved me a lot of searching, downloading, and
> hunting work.
> 
> Thanks,  Chris.
> 
> 
> 
> 



      
            
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - You care about security. So do we. 
http://promotions.yahoo.com/new_mail

Yahoo! Groups SponsorADVERTISEMENT


---------------------------------
Yahoo! Groups Links

   To visit your group on the web, go to:
http://groups.yahoo.com/group/lpc2000/
  
   To unsubscribe from this group, send an email to:
lpc2000-unsubscribe@yahoogroups.com
  
   Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. 




---------------------------------
Do You Yahoo!?
注册世界一流品质的雅虎免费电邮

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