Forums

Interrupt vectors in SRAM, code in Flash

Started by Shahzeb Ihsan August 7, 2007
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
>

An Engineer's Guide to the LPC2100 Series

--- 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
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/
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/
>