Lpc2000

Hi Tom,

Thanks for the reply. The top of stack address was actually set for 
the highest value of RAM (0x40001FFF for 2131, 8K max). I've gone 
ahead and reserved the upper 32-bytes of RAM for the IAP. Disabling 
interrupts via CPSR_C should be sufficient to disable all interrupts, 
should it not? The result is still the same, software reset with 
watchdog active and device lockup with watchdog disabled. I'm 
probably missing something simple, yet I've tried several different 
tests with the same results. IAP simply fails to complete (or return 
from IAP) while the main code is running, but does fine in the 
startup sequence (before interrupts are enabled/stack space is 
defined). Again, I am using pure assembly to program this, no C code 
here. I'm almost willing to bet that it's returning to a trashed 
address, but shouldn't reserving the 32 bytes fix that?

Thanks,
Anthony

--- In lpc2000@yahoogroups.com, Tom Walsh <tom@...> wrote:
> That has nothing to do with disallowing RAM access.  MEMMAP set 
to "User 
> RAM Mode. Interrupt vectors are re-mapped to Static RAM."  means 
exactly 
> that.  The first 32 bytes (the VECTOR TABLE) is mapped as the first 
32 
> bytes of the RAM.  This allows you to override the VECTORS in the 
Flash 
> memory and replace them with values in the RAM.
> 
> MEMMAP does not prevent you from doing a COPY TO RAM IAP operation.
> 
> >Now, this IAP routine is supposed to execute when it receives a 
> >proper frame via the serial bus (UART0), and it does so (I've 
> >verified this). Now, if I attempt to do the copy RAM to flash IAP 
> >process in the startup sequence (IE. interrupts & watchdog not yet 
> >enabled), I can see that the RAM -> flash process was successful 
by 
> >viewing the bytes on the destination sector. Yet, it doesn't seem 
to 
> >work while everything else is running. Possible interrupt problem? 
If 
> >you have any thoughts to share on this, it would be very much 
> >appreciated. Thanks for your time.
> >
> >  
> >
> Yes, it probably is.  There are two things to remember:
> 
> 1. the Flash memory is unavailable while the Flash is being 
programmed.  
> Thus, you cannot have anything running (interrupts) while the Flash 
is 
> being programmed via IAP.  It simply is not there until the IAP is 
done 
> with it.
> 
> 2. There is a small portion of RAM being used during the IAP call.  
From 
> the LPC2138 manual: "Flash programming commands use the top 32 
bytes of 
> on-chip RAM. The maximum stack usage in the user allocated stack 
space 
> is 128 bytes and it grows downwards."
> 
> You have to make sure that your stack is set below that point!  
> Otherwise, you may have a return address on the stack that got 
trashed 
> during the ISP call.  Usually just reduce the RAM lenght in the 
linder 
> script file:
> 
> ================= begin LPC2138ROM.ld ===============
> /* Memory Definitions */
> MEMORY
> {
>   ROM (rx) : ORIGIN = 0x00000000, LENGTH = 0x00080000
>   RAM (rw) : ORIGIN = 0x40000000, LENGTH = 0x00007fe0
> }
> 
> /* Section Definitions */
> SECTIONS
> {
>   /* first section is .text which is used for code */
>   .text :
>   {
>     *crt0.o (.text)            /* Startup code */
>     *(.text)                   /* remaining code */
>     *(.rodata)                 /* read-only data (constants) */
> ===================== snip ======================
> 
> Note the "0x00007fe0" ?
> 
> 
> There is more, but that'll get you going.
> 
> TomW
> 
> 
> -- 
> Tom Walsh - WN3L - Embedded Systems Consultant
> http://openhardware.net, http://cyberiansoftware.com
> "Windows? No thanks, I have work to do..."
> ----------------------------------------------------
>