After reading the compilation manual I found the problem. The C-
library module that is responsible for copying the code according to
the scatter file is called __main.o . Therefore at the end of the
startup code this module has to be called. Instead of __main I was
calling main, that is why the code wasn't copied.
--- In l..., "Sait Izmit" wrote: >
> Paul,
>
> I understand that but as I told earlier I am using uVision with Keil > compiler and I am defining the startup.s file. Do you
or anyone else > knows how to do the copying with the keil compiler or
in the
> startup.s file?
>
> By the way, I am new to this memory re-mapping bussiness therefore
> please excuse me if i am asking some newbie questions:-)
>
> Thanks,
>
> Sait
> --- In l..., "Paul Curtis" wrote:
> >
> > Hi,
> >
> > > Thanks for the input so far!
> > >
> > > Herbert, I can not see much difference about the way we define the > > > scatter files.
> > >
> > > Jim and Paul, I tried to define the attribute however the code
> runs
> > > from FLASH. But Paul's reply made me curious if I am doing
> something
> > > wrong with my startup.s file. Because I just use an example
> startup.s
> > > file I never changed it. So my question is if startup.s is
> > > responsible for copying the code from flash to RAM? Because I
> believe
> > > that my scatter file is ok. Here is the startup.s file I have:
> >
> > Code copying is done by the CrossWorks startup code; sorry if
> Jim's/my
> > comments did not make the context clear.
> >
> > --
> > Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> > CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors >
I understand that but as I told earlier I am using uVision with Keil
compiler and I am defining the startup.s file. Do you or anyone else
knows how to do the copying with the keil compiler or in the
startup.s file?
By the way, I am new to this memory re-mapping bussiness therefore
please excuse me if i am asking some newbie questions:-)
Thanks,
Sait
--- In l..., "Paul Curtis" wrote: >
> Hi,
>
> > Thanks for the input so far!
> >
> > Herbert, I can not see much difference about the way we define the
> > scatter files.
> >
> > Jim and Paul, I tried to define the attribute however the code runs > > from FLASH. But Paul's reply made me curious
if I am doing something > > wrong with my startup.s file. Because I just use an
example startup.s > > file I never changed it. So my question is if
startup.s is
> > responsible for copying the code from flash to RAM? Because I believe > > that my scatter file is ok. Here is the startup.s
file I have:
>
> Code copying is done by the CrossWorks startup code; sorry if Jim's/my > comments did not make the context clear.
>
> --
> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors
>
Reply by Bogdan Marinescu●June 4, 20082008-06-04
Ah, OK, I understand now, the code can run _only_ from RAM. Thanks.
On Wed, Jun 4, 2008 at 11:59 AM, Paul Curtis wrote: > Hi,
>
>> I assume you mean "there is no PIC requirement in this particular
>> case", right? Because in general I assume that you need some sort of
>> PIC if you're moving code around.
>
> You only need PIC if you don't know, in advance, where the code will
> execute. In this case there is no PIC requirement because you know the code
> will run from a known place in RAM (the linker chooses it), it's just
a
> matter of getting the RAM filled with the right instructions--that's
what
> the startup code does for you.
>
> --
> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors
Reply by Paul Curtis●June 4, 20082008-06-04
Hi,
> I assume you mean "there is no PIC requirement in
this particular
> case", right? Because in general I assume that you need some sort of
> PIC if you're moving code around.
You only need PIC if you don't know, in advance, where the code will
execute. In this case there is no PIC requirement because you know the code
will run from a known place in RAM (the linker chooses it), it's just a
matter of getting the RAM filled with the right instructions--that's
what
the startup code does for you.
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors
Reply by Bogdan Marinescu●June 4, 20082008-06-04
Hi,
I assume you mean "there is no PIC requirement in this particular
case", right? Because in general I assume that you need some sort of
PIC if you're moving code around.
Thanks,
Bogdan
On Wed, Jun 4, 2008 at 11:54 AM, Paul Curtis wrote: > Hi,
>
>> What about PIC? Or this is enabled by default?
>
> There is no PIC requirement.
>
> --
> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors
Reply by Paul Curtis●June 4, 20082008-06-04
Hi,
> What about PIC? Or this is enabled by default?
There is no PIC requirement.
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors
Reply by Bogdan Marinescu●June 4, 20082008-06-04
What about PIC? Or this is enabled by default?
On Wed, Jun 4, 2008 at 11:51 AM, Paul Curtis wrote: > Hi,
>
>> Thanks for the input so far!
>>
>> Herbert, I can not see much difference about the way we define the
>> scatter files.
>>
>> Jim and Paul, I tried to define the attribute however the code runs
>> from FLASH. But Paul's reply made me curious if I am doing something
>> wrong with my startup.s file. Because I just use an example startup.s
>> file I never changed it. So my question is if startup.s is
>> responsible for copying the code from flash to RAM? Because I believe
>> that my scatter file is ok. Here is the startup.s file I have:
>
> Code copying is done by the CrossWorks startup code; sorry if Jim's/my
> comments did not make the context clear.
>
> --
> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors
Reply by Paul Curtis●June 4, 20082008-06-04
Hi,
> Thanks for the input so far!
>
> Herbert, I can not see much difference about the way we define the
> scatter files.
>
> Jim and Paul, I tried to define the attribute however the code runs
> from FLASH. But Paul's reply made me curious if I am doing something
> wrong with my startup.s file. Because I just use an example startup.s
> file I never changed it. So my question is if startup.s is
> responsible for copying the code from flash to RAM? Because I believe
> that my scatter file is ok. Here is the startup.s file I have:
Code copying is done by the CrossWorks startup code; sorry if Jim's/my
comments did not make the context clear.
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors
Reply by Sait Izmit●June 4, 20082008-06-04
Thanks for the input so far!
Herbert, I can not see much difference about the way we define the
scatter files.
Jim and Paul, I tried to define the attribute however the code runs
from FLASH. But Paul's reply made me curious if I am doing something
wrong with my startup.s file. Because I just use an example startup.s
file I never changed it. So my question is if startup.s is
responsible for copying the code from flash to RAM? Because I believe
that my scatter file is ok. Here is the startup.s file I have:
;*********************************************************************
*********
;
; File name: Startup.s
; ----------
;
;*********************************************************************
*********
;/* <<< Use Configuration Wizard in Context Menu >>> */ ; INCLUDE Regs.inc
IMPORT main
IMPORT FIQ_Handler_User_Init, WEAK ;from FIQHandler.s
IMPORT FIQ_Handler_User, WEAK ;from FIQHandler.s
;============================================================================;
; Definitions and Macros
;
;============================================================================
; Value of Mode Bits M[4..0] of CPSR
I_Bit EQU 0x80 ;IRQ disable bit
F_Bit EQU 0x40 ;FIQ disable bit
; - Flash Marker -----------------
----------
; Area Definition for Flash User Program Valid Marker
; UNCOMMENT FOR FLASH PROGRAMMING !!!
AREA |.ARM.__AT_0x104FF800|, CODE, READONLY
ARM
DCD 0xAA55AA55
;---------------------------------
---------
; Stack sizes, stack top addresses.
; USR/SYS stack size doesn't have to be defined, because it simply
uses
; the remaining memory between the other dedicated stack and the
heap.
;---------------------------------
---------
AREA STACK, NOINIT, READWRITE, ALIGN=3
Stack_Mem SPACE Stack_Size
Stack_Top EQU Stack_Mem + Stack_Size
;// Heap Configuration
;// Heap Size (in Bytes) <0x0-0xFFFFFFFF>
;//
Heap_Size EQU 0x00000200
AREA HEAP, NOINIT, READWRITE, ALIGN=3
Heap_Mem SPACE Heap_Size
;============================================================================;
; Start of executable code.
; This area 'Startup' must be linked as the very first module in
; the executable region 'ROM'.
;
;============================================================================
AREA RESET, CODE, READONLY
LDR PC,Reset_Handler_Address ;offset 0x00
LDR PC,Undefined_Handler_Address ;offset 0x04
LDR PC,SWI_Handler_Address ;offset 0x08
LDR PC,Prefetch_Handler_Address ;offset 0x0C
LDR PC,Abort_Handler_Address ;offset 0x10
NOP ;offset 0x14
LDR PC,IRQ_Handler_Address ;offset 0x18
; LDR PC,FIQ_Handler_Address ;offset 0x1C
LDR PC,=FIQ_Handler_User
;offset 0x1C
Reset_Handler_Address DCD Reset_Handler
Undefined_Handler_Address DCD Undefined_Handler
SWI_Handler_Address DCD SWI_Handler
Prefetch_Handler_Address DCD Prefetch_Handler
Abort_Handler_Address DCD Abort_Handler
IRQ_Handler_Address DCD IRQ_Handler
;FIQ_Handler_Address DCD FIQ_Handler
;FIQ_Handler b FIQ_Handler
;============================================================================;
This is were we are just after reset.
; The ARM is in SVC (Supervisor) mode.
;============================================================================Reset_Handler
; Setup Stack for each mode
LDR R0, =Stack_Top
; Enter Undefined Instruction Mode and set its Stack Pointer
MSR CPSR_c, #Mode_UND:OR:I_Bit:OR:F_Bit
MOV SP, R0
SUB R0, R0, #UND_Stack_Size
; Enter Abort Mode and set its Stack Pointer
MSR CPSR_c, #Mode_ABT:OR:I_Bit:OR:F_Bit
MOV SP, R0
SUB R0, R0, #ABT_Stack_Size
; Enter FIQ Mode and set its Stack Pointer
MSR CPSR_c, #Mode_FIQ:OR:I_Bit:OR:F_Bit
MOV SP, R0
SUB R0, R0, #FIQ_Stack_Size
; Enter IRQ Mode and set its Stack Pointer
MSR CPSR_c, #Mode_IRQ:OR:I_Bit:OR:F_Bit
MOV SP, R0
SUB R0, R0, #IRQ_Stack_Size
; Enter Supervisor Mode and set its Stack Pointer
MSR CPSR_c, #Mode_SVC:OR:I_Bit:OR:F_Bit
MOV SP, R0
SUB R0, R0, #SVC_Stack_Size
; Enter User Mode and set its Stack Pointer
MSR CPSR_c, #Mode_SYS
MOV SP, R0
SUB SL, SP, #USR_Stack_Size
;---------------------------------
---------
; Switch to FIQ mode and call the initialization function for the
; FIQ interrupt handler (if it exists)
;---------------------------------
---------
;Switch to FIQ mode (IRQ and FIQ still disabled)
;
MOV R0, #Mode_FIQ:OR:I_Bit:OR:F_Bit
MSR CPSR_c, R0
;============================================================================;
Switch to user mode and do a global interrupt enable in ARM CPU.
; Then jump to C main code.
;============================================================================
;Go to USR mode and enable IRQ and FIQ interrupts in ARM
;
MOV R1, #Mode_USR
MSR CPSR_c, R1
;Now jump to C main code.
;C_main in ARM mode.
;
LDR R0,=main
BX R0
SwitchToArm
;Should the main function ever return, we restart the CPU
;
B Reset_Handler
; User Initial Stack & Heap
AREA |.text|, CODE, READONLY
> Morning
> This is pretty interesting stuff, I am investigating the same issue
>
> What would be wrong with doing something like:
>
> #define ATTR_RUN_FROM_RAM __attribute__ ((section (".fast")))
>
> void runFasterer( void ) ATTR_RUN_FROM_RAM;
>
> Under Crossworks...In that Rowley have done it all for me ?
> Or have I once again completely missunderstood ?
As copying .fast to RAM is done in the common startup code, that is indeed
all you need to do.
