Lpc2000

Hi,

I'm currently on a project which uses the LPC2131 mp. The problem I'm 
trying to tackle at the moment is trying to get the IAP to 
successfully copy RAM data into flash. After browsing through the 
15,000+ messages on this board regarding the IAP, I could not get any 
of the solutions posted to work for me (unless I'm missing something 
very simple). This device runs with 1 FIQ process (PWM) and 4 other  
IRQs. Some of the solutions I've found from the other boards include

1) Make sure the jump to IAP location is 0x7FFFFFF1 using a BX 
instead of MOV or standard B.

2) Make sure the CCLK value is correct (In this case, 20 Mhz external 
clock PLL'ed to 60 Mhz)

3) Disable interrupts before jumping into the IAP address

4) Change MEMMAP to use RAM space instead of user flash since IAP 
disallows any access of flash memory while IAP is active

I've followed what I could from the above solutions. Here are the 
results when I try several different things with regards to IAP:

1) Turning interrupts off via MSR/MRS instruction, watchdog (1 second 
timeout) running - device goes into software reset.

2) Turning interrupts off via VIC, watchdog running - device goes 
into software reset.

3) Turning interrupts off, watchdog disabled - device locks up, 
requires power down/up to restart again.

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.

Anthony

Dear Anthony,

  On my version is make P0.14 an output and set it low before calling
the vector. This has worked perfectly.

regards,
Charles


--- In lpc2000@yahoogroups.com, "adelacruz01" <adelacruz01@...> wrote:

>
> Hi,
> 
> I'm currently on a project which uses the LPC2131 mp. The problem I'm 
> trying to tackle at the moment is trying to get the IAP to 
> successfully copy RAM data into flash. After browsing through the 
> 15,000+ messages on this board regarding the IAP, I could not get any 
> of the solutions posted to work for me (unless I'm missing something 
> very simple). This device runs with 1 FIQ process (PWM) and 4 other  
> IRQs. Some of the solutions I've found from the other boards include
> 
> 1) Make sure the jump to IAP location is 0x7FFFFFF1 using a BX 
> instead of MOV or standard B.
> 
> 2) Make sure the CCLK value is correct (In this case, 20 Mhz external 
> clock PLL'ed to 60 Mhz)
> 
> 3) Disable interrupts before jumping into the IAP address
> 
> 4) Change MEMMAP to use RAM space instead of user flash since IAP 
> disallows any access of flash memory while IAP is active
> 
> I've followed what I could from the above solutions. Here are the 
> results when I try several different things with regards to IAP:
> 
> 1) Turning interrupts off via MSR/MRS instruction, watchdog (1 second 
> timeout) running - device goes into software reset.
> 
> 2) Turning interrupts off via VIC, watchdog running - device goes 
> into software reset.
> 
> 3) Turning interrupts off, watchdog disabled - device locks up, 
> requires power down/up to restart again.
> 
> 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.
> 
> Anthony
>

Hi Charles,

I tried your solution, but the result is the same - lockup with 
watchdog disabled, software reset with watchdog enabled. I will keep 
trying different methods; thanks for your input!

Anthony

--- In lpc2000@yahoogroups.com, "charlesgrenz" <charles.grenz@...> 
wrote:
>
> Dear Anthony,
> 
>   On my version is make P0.14 an output and set it low before 
calling

> the vector. This has worked perfectly.
> 
> regards,
> Charles
> 
>

adelacruz01 wrote:

>4) Change MEMMAP to use RAM space instead of user flash since IAP 
>disallows any access of flash memory while IAP is active
>
>  
>
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..."
----------------------------------------------------

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

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]

Geoffrey Wang wrote:

>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?
>
>  
>
 From the LPC2138 manual, I have:
"20.4.12 RAM used by IAP command handler
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."

TomW



-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------

--- In lpc2000@yahoogroups.com, Tom Walsh <tom@...> wrote:

>  From the LPC2138 manual, I have:
> "20.4.12 RAM used by IAP command handler
> 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."
> 
> TomW

Also ISP uses the (I recall about 128 bytes) at the bottom of on-chip RAM.

The effect of this is that you cannot download and run programs that
have vectors mapped to on-chip RAM without resorting to contortions.

Jaya

--- In lpc2000@yahoogroups.com, "Geoffrey Wang" <geoffreyw@...> wrote:
>
> 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

The top 32 bytes are reserved for flash programming stub that is must
be executed from RAM.  The remainder of memory at the top, and the
memory at bottom is used as ISP stack and data segmemnts, respectively.

If you are not using ISP, it looks like you only need to set aside the
top 32 bytes.

However, if you are using WDT, then you need to set aside some memory
at (if I remember, at bottom of memory) which is trashed when the boot
loader sets up external bus interface.

Hope this helps.

Jaya