Lpc2000

This brings up an interesting question...App Note "Initialization Code/Hints for the LPC2000 family" dated 1 nov 2005 says
in section 5.1.2  "In-Application Programming uses the top 128 bytes of theon-chip SRAM.  The application stack should not
overlap this area".  Elsewhere, I've read it uses 32 bytes.  Anyone know the truth?

Geoffrey
  ----- Original Message ----- 
  From: adelacruz01 
  To: lpc2000@yahoogroups.com 
  Sent: Thursday, April 20, 2006 2:14 PM
  Subject: [lpc2000] Re: IAP problems (LPC2131)


  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..."
  > ----------------------------------------------------
  >






  SPONSORED LINKS Microcontrollers  Microprocessor  Intel microprocessors  


------------------------------------------------------------------------------
  YAHOO! GROUPS LINKS 

    a..  Visit your group "lpc2000" on the web.
      
    b..  To unsubscribe from this group, send an email to:
     lpc2000-unsubscribe@yahoogroups.com
      
    c..  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. 


------------------------------------------------------------------------------



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