Reply by Shahzeb Ihsan August 9, 20072007-08-09
Hi,

I'm using ADSv1.2 and I've set the RW region (read/write region) to
start from 0x40000040. But that wasn't the problem. When you get time
take a look at the reply I posted in this thread about the observation
regarding the PLL:

http://tech.groups.yahoo.com/group/lpc2000/message/26519

I'm not seeing the strange behavior anymore, after I stopped using the
breakpoint at "main()" before PLL setup, I stopped having debugger
problems.

Thanks for the help, I'd love to hear your opinions regarding the
above mentioned post.
Regards,
Shahzeb

--- In l..., Alexandre Kremer wrote:
>
>
> Hi
>
> Its a really strange behavior. Are you using the
> same linker configuration file for both tests (running
> from flash and debugging)?
> I could understand that this problem happens only
> when the first interrupt happens, so the micro
> controller cant stablish the right vector position.
> So, the question is, can you check to wich address the
> cpu is redirected when this interrupt happens? If you
> are using a IRQ, it should be 0x40000018, or if you
> are using FIQ it should be 0x4000001C. Try to put a
> breakpoint on those memory positions and check if the
> cpu goes to the right address.
> Also, the only thing i can think of now that makes
> sense to me is that your interrupt vector in ram is
> being overwritten by the variable initialization
> routine. This routine is placed automatically by the
> compiler when you develop C code. Right after you do a
> jump to main, this routine is called and is
> responsible for filling with zeroes the DATA_Z memory
> defined by the linker file and initialize the DATA_I
> memory with the variables values. (DATA_Z and DATA_I
> are sections of memory defined in the IAR linker file,
> wich is the compiler use).
> So, while debugging, try to put a breakpoint right on
> the first main line and check the RAM position to see
> if the vectors you transfered before calling main are
> still there. If you cant reach the first main line,
> try to not re-enable the interrupts, so you certainly
> will reach this line, and youll be able to check the
> RAM for this issue.
>
> Regards
>
> --- Shahzeb Ihsan escreveu:
>
> > Hi,
> >
> > Yes, the interrupts were disabled, this is what I
> > do, that causes
> > problems with debugging when I enable interrupts
> > (this exact same code
> > works perfectly fine when executed without
> > debugging):
> >
> > 1.) On reset, I jump to a sub-routine for copying
> > interrupt vectors
> > 2.) In this sub-routine I disable interrupts, copy
> > vectors into SRAM,
> > give the remap command (MEMMAP = 0x02) and branch to
> > 0x40000000 (SRAM
> > base, new location of the reset vector)
> > 3.) The reset handler initializes stacks, disable
> > interrupts for all
> > processor modes and jumps to "__main" (heap, stack,
> > RW region
> > initialization performed by ADS library function),
> > which then calls
> > "main()".
> > 4.) Initialize hardware and enable interrupts.
> > 5.) Memory read/write error on the first interrupt.
> > Sometimes I get
> > another error
> >
> > The interesting thing is, if on reset I jump
> > directly to the reset
> > handler and then eventually to "main()" and do the
> > interrupt copying
> > procedure over there, everything works fine.
> >
> > Do you think there can be any issues with remapping
> > right after a
> > reset? Or might there be an issue of the processor
> > registers/state not
> > being properly reset by the JTAG reset. I know
> > HJTAG's reset doesn't
> > reset the peripheral registers etc. to their default
> > reset values.
> >
> > Any help is appreciated.
> >
> > Regards,
> > Shahzeb
> >
> > --- In l..., Alexandre Kremer
> > wrote:
> > >
> > > Did you disabled interrupts before execute this
> > > routine? Did you re-enabled them after executing
> > this
> > > routine?
> > > You need something like:
> > >
> > > disable_ints
> > > MRS r7,CPSR
> > > ORR r7,r7,#0xC0
> > > MSR CPSR_c,r7
> > > ...
> > > your routine
> > > ...
> > >
> > > enable_ints
> > > MRS r7,CPSR
> > > BIC r7,r7,#0xC0
> > > MSR CPSR_c,r7
> > >
> > > --- Shahzeb Ihsan escreveu:
> > >
> > > > So, I tried this, works great when I just
> > download
> > > > code into flash.
> > > > But causes problems with debugging (I use HJTAG
> > +
> > > > AXD + ADSv1.2). On
> > > > reset I jump to a sub-routine which copies
> > > > interrupt vectors from a
> > > > location in the flash to the SRAM, I'm copying
> > the
> > > > code below, maybe
> > > > some one can point out if there is something
> > wrong
> > > > with this approach.
> > > > Thanks for all your help.
> > > >
> > > > P.S.: I tried to do this within the main()
> > function
> > > > in C code and that
> > > > worked fine even in debug mode, I don't know why
> > the
> > > > other approach is
> > > > failing...
> > > >
> > > >
> > >
> >
> //-----------------------//
> > > > ;// Load "R0" with the address of the
> > interrupt
> > > > vector table
> > > > ;// in the flash
> > > > LDR R0, =InterruptVectors
> > > >
> > > > ;// Store the number of bytes to be copied
> > in
> > > > "R1" ("0x40")
> > > > MOV R1, #0x40
> > > >
> > > > ;// Load SRAM base address in "R2"
> > > > LDR R2, =SRAM_BASE_ADDR
> > > >
> > > > ;// "R4" stores the count of bytes copied,
> > > > initialize it to "0x00"
> > > > MOV R4, #0x00
> > > >
> > > > ;// Copy interrupt vectors to the SRAM
> > > > VectCopyLoop
> > > > LDR R3, [R0, R4] ;// Read one
> > > > instruction from the
> > > > vector table into "R3"
> > > > STR R3, [R2, R4] ;// Copy the
> > > > instruction from "R3"
> > > > into the SRAM
> > > > ADD R4, R4, #4 ;// Increment
> > > > byte count
> > > > CMP R4, R1 ;// Check if
> > all
> > > > 64 bytes of the
> > > > vector table have been copied
> > > > BNE VectCopyLoop
> > > >
> > > > ;// Issue remap command (set
> > "LPC_MEMMAP_REG"
> > > > to "0x02")
> > > > LDR R0, =LPC_MEMMAP_REG
> > > > MOV R1, #0x02
> > > > STR R1, [R0]
> > > >
> > > > ;// Reset processor, this is just a jump to
> > the
> > > > new reset vector
> > > > ;// in the SRAM
> > > > LDR R0, =SRAM_BASE_ADDR
> > > > BX R0
> > > >
> > >
> >
> //-----------------------//
> > > >
> > > > Regards,
> > > > Shahzeb
> > > >
> > > >
> > > > --- In l..., Wojciech Kromer
> > > >
> > > > wrote:
> > > > >
> > > > > It works fine, but you have do it in this
> > order:
> > > > >
> > > > > - disable interrupts
> > > > > - enable MEMMAP=2
> > > > > - copy 64bytes
> > > > > - enable interrupts
> > > > >
> > > > > Remember to compile into correct memory
> > location.
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Yahoo! Groups Links
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > > Alertas do Yahoo! Mail em seu celular. Saiba
> > mais em
> > http://br.mobile.yahoo.com/mailalertas/
> > >
> >
> >
> >
> >
> >
> > Yahoo! Groups Links
> >
> === message truncated ==>
> Flickr agora em portugu. Vocclica, todo mundo v
> http://www.flickr.com.br/
>

An Engineer's Guide to the LPC2100 Series

Reply by Alexandre Kremer August 9, 20072007-08-09
Hi

Its a really strange behavior. Are you using the
same linker configuration file for both tests (running
from flash and debugging)?
I could understand that this problem happens only
when the first interrupt happens, so the micro
controller cant stablish the right vector position.
So, the question is, can you check to wich address the
cpu is redirected when this interrupt happens? If you
are using a IRQ, it should be 0x40000018, or if you
are using FIQ it should be 0x4000001C. Try to put a
breakpoint on those memory positions and check if the
cpu goes to the right address.
Also, the only thing i can think of now that makes
sense to me is that your interrupt vector in ram is
being overwritten by the variable initialization
routine. This routine is placed automatically by the
compiler when you develop C code. Right after you do a
jump to main, this routine is called and is
responsible for filling with zeroes the DATA_Z memory
defined by the linker file and initialize the DATA_I
memory with the variables values. (DATA_Z and DATA_I
are sections of memory defined in the IAR linker file,
wich is the compiler use).
So, while debugging, try to put a breakpoint right on
the first main line and check the RAM position to see
if the vectors you transfered before calling main are
still there. If you cant reach the first main line,
try to not re-enable the interrupts, so you certainly
will reach this line, and youll be able to check the
RAM for this issue.

Regards

--- Shahzeb Ihsan escreveu:

> Hi,
>
> Yes, the interrupts were disabled, this is what I
> do, that causes
> problems with debugging when I enable interrupts
> (this exact same code
> works perfectly fine when executed without
> debugging):
>
> 1.) On reset, I jump to a sub-routine for copying
> interrupt vectors
> 2.) In this sub-routine I disable interrupts, copy
> vectors into SRAM,
> give the remap command (MEMMAP = 0x02) and branch to
> 0x40000000 (SRAM
> base, new location of the reset vector)
> 3.) The reset handler initializes stacks, disable
> interrupts for all
> processor modes and jumps to "__main" (heap, stack,
> RW region
> initialization performed by ADS library function),
> which then calls
> "main()".
> 4.) Initialize hardware and enable interrupts.
> 5.) Memory read/write error on the first interrupt.
> Sometimes I get
> another error
>
> The interesting thing is, if on reset I jump
> directly to the reset
> handler and then eventually to "main()" and do the
> interrupt copying
> procedure over there, everything works fine.
>
> Do you think there can be any issues with remapping
> right after a
> reset? Or might there be an issue of the processor
> registers/state not
> being properly reset by the JTAG reset. I know
> HJTAG's reset doesn't
> reset the peripheral registers etc. to their default
> reset values.
>
> Any help is appreciated.
>
> Regards,
> Shahzeb
>
> --- In l..., Alexandre Kremer
> wrote:
> >
> > Did you disabled interrupts before execute this
> > routine? Did you re-enabled them after executing
> this
> > routine?
> > You need something like:
> >
> > disable_ints
> > MRS r7,CPSR
> > ORR r7,r7,#0xC0
> > MSR CPSR_c,r7
> > ...
> > your routine
> > ...
> >
> > enable_ints
> > MRS r7,CPSR
> > BIC r7,r7,#0xC0
> > MSR CPSR_c,r7
> >
> > --- Shahzeb Ihsan escreveu:
> >
> > > So, I tried this, works great when I just
> download
> > > code into flash.
> > > But causes problems with debugging (I use HJTAG
> +
> > > AXD + ADSv1.2). On
> > > reset I jump to a sub-routine which copies
> > > interrupt vectors from a
> > > location in the flash to the SRAM, I'm copying
> the
> > > code below, maybe
> > > some one can point out if there is something
> wrong
> > > with this approach.
> > > Thanks for all your help.
> > >
> > > P.S.: I tried to do this within the main()
> function
> > > in C code and that
> > > worked fine even in debug mode, I don't know why
> the
> > > other approach is
> > > failing...
> > >
> > >
> //-----------------------//
> > > ;// Load "R0" with the address of the
> interrupt
> > > vector table
> > > ;// in the flash
> > > LDR R0, =InterruptVectors
> > >
> > > ;// Store the number of bytes to be copied
> in
> > > "R1" ("0x40")
> > > MOV R1, #0x40
> > >
> > > ;// Load SRAM base address in "R2"
> > > LDR R2, =SRAM_BASE_ADDR
> > >
> > > ;// "R4" stores the count of bytes copied,
> > > initialize it to "0x00"
> > > MOV R4, #0x00
> > >
> > > ;// Copy interrupt vectors to the SRAM
> > > VectCopyLoop
> > > LDR R3, [R0, R4] ;// Read one
> > > instruction from the
> > > vector table into "R3"
> > > STR R3, [R2, R4] ;// Copy the
> > > instruction from "R3"
> > > into the SRAM
> > > ADD R4, R4, #4 ;// Increment
> > > byte count
> > > CMP R4, R1 ;// Check if
> all
> > > 64 bytes of the
> > > vector table have been copied
> > > BNE VectCopyLoop
> > >
> > > ;// Issue remap command (set
> "LPC_MEMMAP_REG"
> > > to "0x02")
> > > LDR R0, =LPC_MEMMAP_REG
> > > MOV R1, #0x02
> > > STR R1, [R0]
> > >
> > > ;// Reset processor, this is just a jump to
> the
> > > new reset vector
> > > ;// in the SRAM
> > > LDR R0, =SRAM_BASE_ADDR
> > > BX R0
> > >
> //-----------------------//
> > >
> > > Regards,
> > > Shahzeb
> > >
> > >
> > > --- In l..., Wojciech Kromer
> > >
> > > wrote:
> > > >
> > > > It works fine, but you have do it in this
> order:
> > > >
> > > > - disable interrupts
> > > > - enable MEMMAP=2
> > > > - copy 64bytes
> > > > - enable interrupts
> > > >
> > > > Remember to compile into correct memory
> location.
> > > >
> > >
> > >
> > >
> > >
> > >
> > > Yahoo! Groups Links
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> > Alertas do Yahoo! Mail em seu celular. Saiba
> mais em
> http://br.mobile.yahoo.com/mailalertas/
> >
>
> Yahoo! Groups Links
>
=== message truncated ==
Flickr agora em portugu. Vocclica, todo mundo v
http://www.flickr.com.br/
Reply by showerholes August 9, 20072007-08-09
--- In l..., "Shahzeb Ihsan" wrote:
>
> Actually no :D
>
> I setup the stack after the vector remapping sub-routine (in the reset
> handler). Should I have? The stack isn't used anywhere in this
> sub-routine...

You may correct me but my understanding is that right after reset
the program jumps to the subroutine ? If so then after return of this
subroutine the program will do something else except what you want
it to do. A clean jump to this function would be better.
In this function (better make it a block of statements) you should
initialise the other stacks to (exception, abort, etc) before
you do another (clean) jump to the main loop.



Armand ten Doesschate
Reply by Shahzeb Ihsan August 9, 20072007-08-09
Actually no :D

I setup the stack after the vector remapping sub-routine (in the reset
handler). Should I have? The stack isn't used anywhere in this
sub-routine...

Anyway, I have another observation, after some painstaking debugging,
I found out that the everything went to hell when I setup the PLL. The
PLL in the original work flow is being setup after memory remapping.
If I don't use the PLL, the debugger doesn't crash. So I had this
wacky idea that maybe the delay due to the default breakpoint at
"main()" was causing the problems since that was the main difference
in the debug mode. True enough, when I removed the breakpoint from
"main()" and then debugged the code with the PLL connected, no
problems at all!

I might be getting worked up over nothing here but is there a
possibility that the delay between vector remapping and PLL setup can
cause problems. The empirical data supports this theory atleast...

Thanks for all your help,
Regards,
Shahzeb

--- In l..., "showerholes" wrote:
>
> --- In l..., "Shahzeb Ihsan" wrote:
> >
> > So, I tried this, works great when I just download code into flash.
> > But causes problems with debugging (I use HJTAG + AXD + ADSv1.2). On
> > reset I jump to a sub-routine which copies interrupt vectors from a
>
> Maybe a stupid question : did you initialize the stack before you jump
> to this
> subroutine and initialize the stack again at the new starting point ?
>
> Armand ten Doesschate
>
Reply by showerholes August 9, 20072007-08-09
--- In l..., "Shahzeb Ihsan" wrote:
>
> So, I tried this, works great when I just download code into flash.
> But causes problems with debugging (I use HJTAG + AXD + ADSv1.2). On
> reset I jump to a sub-routine which copies interrupt vectors from a



Maybe a stupid question : did you initialize the stack before you jump
to this
subroutine and initialize the stack again at the new starting point ?

Armand ten Doesschate
Reply by Shahzeb Ihsan August 9, 20072007-08-09
Hi,

Yes, the interrupts were disabled, this is what I do, that causes
problems with debugging when I enable interrupts (this exact same code
works perfectly fine when executed without debugging):

1.) On reset, I jump to a sub-routine for copying interrupt vectors
2.) In this sub-routine I disable interrupts, copy vectors into SRAM,
give the remap command (MEMMAP = 0x02) and branch to 0x40000000 (SRAM
base, new location of the reset vector)
3.) The reset handler initializes stacks, disable interrupts for all
processor modes and jumps to "__main" (heap, stack, RW region
initialization performed by ADS library function), which then calls
"main()".
4.) Initialize hardware and enable interrupts.
5.) Memory read/write error on the first interrupt. Sometimes I get
another error

The interesting thing is, if on reset I jump directly to the reset
handler and then eventually to "main()" and do the interrupt copying
procedure over there, everything works fine.

Do you think there can be any issues with remapping right after a
reset? Or might there be an issue of the processor registers/state not
being properly reset by the JTAG reset. I know HJTAG's reset doesn't
reset the peripheral registers etc. to their default reset values.

Any help is appreciated.

Regards,
Shahzeb

--- In l..., Alexandre Kremer wrote:
>
> Did you disabled interrupts before execute this
> routine? Did you re-enabled them after executing this
> routine?
> You need something like:
>
> disable_ints
> MRS r7,CPSR
> ORR r7,r7,#0xC0
> MSR CPSR_c,r7
> ...
> your routine
> ...
>
> enable_ints
> MRS r7,CPSR
> BIC r7,r7,#0xC0
> MSR CPSR_c,r7
>
> --- Shahzeb Ihsan escreveu:
>
> > So, I tried this, works great when I just download
> > code into flash.
> > But causes problems with debugging (I use HJTAG +
> > AXD + ADSv1.2). On
> > reset I jump to a sub-routine which copies
> > interrupt vectors from a
> > location in the flash to the SRAM, I'm copying the
> > code below, maybe
> > some one can point out if there is something wrong
> > with this approach.
> > Thanks for all your help.
> >
> > P.S.: I tried to do this within the main() function
> > in C code and that
> > worked fine even in debug mode, I don't know why the
> > other approach is
> > failing...
> >
> >
> //-----------------------//
> > ;// Load "R0" with the address of the interrupt
> > vector table
> > ;// in the flash
> > LDR R0, =InterruptVectors
> >
> > ;// Store the number of bytes to be copied in
> > "R1" ("0x40")
> > MOV R1, #0x40
> >
> > ;// Load SRAM base address in "R2"
> > LDR R2, =SRAM_BASE_ADDR
> >
> > ;// "R4" stores the count of bytes copied,
> > initialize it to "0x00"
> > MOV R4, #0x00
> >
> > ;// Copy interrupt vectors to the SRAM
> > VectCopyLoop
> > LDR R3, [R0, R4] ;// Read one
> > instruction from the
> > vector table into "R3"
> > STR R3, [R2, R4] ;// Copy the
> > instruction from "R3"
> > into the SRAM
> > ADD R4, R4, #4 ;// Increment
> > byte count
> > CMP R4, R1 ;// Check if all
> > 64 bytes of the
> > vector table have been copied
> > BNE VectCopyLoop
> >
> > ;// Issue remap command (set "LPC_MEMMAP_REG"
> > to "0x02")
> > LDR R0, =LPC_MEMMAP_REG
> > MOV R1, #0x02
> > STR R1, [R0]
> >
> > ;// Reset processor, this is just a jump to the
> > new reset vector
> > ;// in the SRAM
> > LDR R0, =SRAM_BASE_ADDR
> > BX R0
> >
> //-----------------------//
> >
> > Regards,
> > Shahzeb
> >
> >
> > --- In l..., Wojciech Kromer
> >
> > wrote:
> > >
> > > It works fine, but you have do it in this order:
> > >
> > > - disable interrupts
> > > - enable MEMMAP=2
> > > - copy 64bytes
> > > - enable interrupts
> > >
> > > Remember to compile into correct memory location.
> > >
> >
> >
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> > Alertas do Yahoo! Mail em seu celular. Saiba mais em
http://br.mobile.yahoo.com/mailalertas/
>
Reply by Alexandre Kremer August 8, 20072007-08-08
Did you disabled interrupts before execute this
routine? Did you re-enabled them after executing this
routine?
You need something like:

disable_ints
MRS r7,CPSR
ORR r7,r7,#0xC0
MSR CPSR_c,r7
...
your routine
...

enable_ints
MRS r7,CPSR
BIC r7,r7,#0xC0
MSR CPSR_c,r7

--- Shahzeb Ihsan escreveu:

> So, I tried this, works great when I just download
> code into flash.
> But causes problems with debugging (I use HJTAG +
> AXD + ADSv1.2). On
> reset I jump to a sub-routine which copies
> interrupt vectors from a
> location in the flash to the SRAM, I'm copying the
> code below, maybe
> some one can point out if there is something wrong
> with this approach.
> Thanks for all your help.
>
> P.S.: I tried to do this within the main() function
> in C code and that
> worked fine even in debug mode, I don't know why the
> other approach is
> failing...
//-----------------------//
> ;// Load "R0" with the address of the interrupt
> vector table
> ;// in the flash
> LDR R0, =InterruptVectors
>
> ;// Store the number of bytes to be copied in
> "R1" ("0x40")
> MOV R1, #0x40
>
> ;// Load SRAM base address in "R2"
> LDR R2, =SRAM_BASE_ADDR
>
> ;// "R4" stores the count of bytes copied,
> initialize it to "0x00"
> MOV R4, #0x00
>
> ;// Copy interrupt vectors to the SRAM
> VectCopyLoop
> LDR R3, [R0, R4] ;// Read one
> instruction from the
> vector table into "R3"
> STR R3, [R2, R4] ;// Copy the
> instruction from "R3"
> into the SRAM
> ADD R4, R4, #4 ;// Increment
> byte count
> CMP R4, R1 ;// Check if all
> 64 bytes of the
> vector table have been copied
> BNE VectCopyLoop
>
> ;// Issue remap command (set "LPC_MEMMAP_REG"
> to "0x02")
> LDR R0, =LPC_MEMMAP_REG
> MOV R1, #0x02
> STR R1, [R0]
>
> ;// Reset processor, this is just a jump to the
> new reset vector
> ;// in the SRAM
> LDR R0, =SRAM_BASE_ADDR
> BX R0
>
//-----------------------//
>
> Regards,
> Shahzeb
> --- In l..., Wojciech Kromer
>
> wrote:
> >
> > It works fine, but you have do it in this order:
> >
> > - disable interrupts
> > - enable MEMMAP=2
> > - copy 64bytes
> > - enable interrupts
> >
> > Remember to compile into correct memory location.
> >
>
> Yahoo! Groups Links
>

Alertas do Yahoo! Mail em seu celular. Saiba mais em http://br.mobile.yahoo.com/mailalertas/
Reply by Shahzeb Ihsan August 8, 20072007-08-08
So, I tried this, works great when I just download code into flash.
But causes problems with debugging (I use HJTAG + AXD + ADSv1.2). On
reset I jump to a sub-routine which copies interrupt vectors from a
location in the flash to the SRAM, I'm copying the code below, maybe
some one can point out if there is something wrong with this approach.
Thanks for all your help.

P.S.: I tried to do this within the main() function in C code and that
worked fine even in debug mode, I don't know why the other approach is
failing...

//-----------------------//
;// Load "R0" with the address of the interrupt vector table
;// in the flash
LDR R0, =InterruptVectors

;// Store the number of bytes to be copied in "R1" ("0x40")
MOV R1, #0x40

;// Load SRAM base address in "R2"
LDR R2, =SRAM_BASE_ADDR

;// "R4" stores the count of bytes copied, initialize it to "0x00"
MOV R4, #0x00

;// Copy interrupt vectors to the SRAM
VectCopyLoop
LDR R3, [R0, R4] ;// Read one instruction from the
vector table into "R3"
STR R3, [R2, R4] ;// Copy the instruction from "R3"
into the SRAM
ADD R4, R4, #4 ;// Increment byte count
CMP R4, R1 ;// Check if all 64 bytes of the
vector table have been copied
BNE VectCopyLoop

;// Issue remap command (set "LPC_MEMMAP_REG" to "0x02")
LDR R0, =LPC_MEMMAP_REG
MOV R1, #0x02
STR R1, [R0]

;// Reset processor, this is just a jump to the new reset vector
;// in the SRAM
LDR R0, =SRAM_BASE_ADDR
BX R0
//-----------------------//

Regards,
Shahzeb
--- In l..., Wojciech Kromer
wrote:
>
> It works fine, but you have do it in this order:
>
> - disable interrupts
> - enable MEMMAP=2
> - copy 64bytes
> - enable interrupts
>
> Remember to compile into correct memory location.
>
Reply by mjames_doveridge August 7, 20072007-08-07
--- In l..., "Shahzeb Ihsan" wrote:
>
> OK, that's good to know, I actually am doing something related to two
> banks of code...
>
> Just one more thing, you wrote something about a startup reset, can
> you please clarify?
>

IIRC, after the boot code has remapped the vectors it just loads a
void function parameter with the contents of address 0 and calls it,
so transferring control to the selected bank.

Rgds,
Martin
Reply by Wojciech Kromer August 7, 20072007-08-07
It works fine, but you have do it in this order:

- disable interrupts
- enable MEMMAP=2
- copy 64bytes
- enable interrupts

Remember to compile into correct memory location.