# Forum: ARM programming with GCC/GNU tools Run from RAM and reset on LPC2106

Rate this post
 0 ▲ useful ▼ not useful
I have a question about running from RAM on an LPC2106.

I am using the Olimex LPC2106 development board and the WinARM
distribution.  I would like to run from RAM instead of Flash.   I was
able to do this using some information from a few earlier posts.  I am
using lpc21isp to push the hex file out to the uC board and the code
runs just fine from RAM.  However, it does not execute after a reset.
So I don't think I have setup the interrupts correctly.   I am very much
a novice and would appreciate any insight or links to references that
you may have.   Included below is what I have tried.

Thanks

Jeff McGough

What I have done is:

1)  Edited the Makefile

## Create ROM-Image (final)
#RUN_MODE=ROM_RUN
## Create RAM-Image (debugging)
RUN_MODE=RAM_RUN

2) Edited the linker script lpc2106-RAM.ld

/* Memory Definitions */
MEMORY
{
ROM (rx) : ORIGIN = 0x00000000, LENGTH = 0x00020000
/*  RAM (rw) : ORIGIN = 0x40000000, LENGTH = 0x00010000 */
RAM (rw) : ORIGIN = 0x40000300, LENGTH = 0x0000fb00
}

3) Edited the startup assembly code crt0.S

added in _mainCRTStartup below #ifdef ROM_RUN section

#ifdef RAM_RUN
ldr   r1,=Vectors     // Copy source: vectors placed by linker
ldr   r2,=0x40000000  // Copy destination start: SRAM start address
ldr   r3,=0x40000040  // Copy destination end
vectorcopyloop:
cmp   r2,r3           // check if data to move
ldrne r0,[r1],#4      // copy it
strne r0,[r2],#4
bne   vectorcopyloop  // loop until done
#endif

4) Stared at the board for a long time .....

Rate this post
 0 ▲ useful ▼ not useful
Jeff McGough wrote:

>...
> I am
> using lpc21isp to push the hex file out to the uC board and the code
> runs just fine from RAM.  However, it does not execute after a reset.
>...

Why do you need this? Anyway: I have not used lpc21isp that often for
uploading into SRAM but as far as I remember it launches code through
the bootloaders G-command. I'm not sure if the controller preserves the
SRAM content during reset. In case it does you may place a very small
program in flash at address 0x00000000 which just "jumps" to the start
of your code in SRAM. Something like this:
ldr pc, MYPROG_IN_RAM_START
MYPROG_IN_RAM_START: .word 0x40000300

Rate this post
 0 ▲ useful ▼ not useful
Martin Thomas wrote:
> Jeff McGough wrote:
>
>>...
>> I am
>> using lpc21isp to push the hex file out to the uC board and the code
>> runs just fine from RAM.  However, it does not execute after a reset.
>>...
>
> Why do you need this? Anyway: I have not used lpc21isp that often for
> uploading into SRAM but as far as I remember it launches code through
> the bootloaders G-command. I'm not sure if the controller preserves the
> SRAM content during reset. In case it does you may place a very small
> program in flash at address 0x00000000 which just "jumps" to the start
> of your code in SRAM. Something like this:
> ldr pc, MYPROG_IN_RAM_START
> MYPROG_IN_RAM_START: .word 0x40000300

Thanks for the suggestion on this.  I also wanted to say thanks for your
ARM
Projects page.  It has really helped us on our current project.

As to your first question.  The Olimex boards are being used as
replacements for the Parallax controllers on 30 Parallax robots,
BOEBOTS.  The Olimex board has nearly the same footprint as the Parallax
board, and all of this was equipment that our EE Dept was using.  We use
these little robots in some of our introductory programming courses (as
it satisfies a multitude of constraints placed on me by the various Univ
depts).  We have had success in increasing student interest in
programming and developing skills with embedded systems, and, have had a
great time.  Since the students are learning how to code, we have many
many writes to flash over a semester.  I became worried about the
lifespan of the system.  So, I thought moving to RAM would extend the
years we will get out of the little bots.  I have not had the time to
look into getting an RTOS loaded which might also address some problems.
Philips flash programming tool.  Thoughts?

Thanks again for your time and efforts,

Jeff McGough
Computer Science
South Dakota School of Mines and Technology

Rate this post
 0 ▲ useful ▼ not useful
Jeff McGough wrote:
> Martin Thomas wrote:
>> Jeff McGough wrote:
>>
>>>...
>>> I am
>>> using lpc21isp to push the hex file out to the uC board and the code
>>> runs just fine from RAM.  However, it does not execute after a reset.
>>>...
>>
>> Why do you need this? Anyway: I have not used lpc21isp that often for
>> uploading into SRAM but as far as I remember it launches code through
>> the bootloaders G-command. I'm not sure if the controller preserves the
>> SRAM content during reset. In case it does you may place a very small
>> program in flash at address 0x00000000 which just "jumps" to the start
>> of your code in SRAM. Something like this:
>> ldr pc, MYPROG_IN_RAM_START
>> MYPROG_IN_RAM_START: .word 0x40000300
>
> Thanks for the suggestion on this.  I also wanted to say thanks for your
> ARM
> Projects page.  It has really helped us on our current project.

> As to your first question.  The Olimex boards are being used as
> replacements for the Parallax controllers on 30 Parallax robots,
> BOEBOTS.  The Olimex board has nearly the same footprint as the Parallax
> board, and all of this was equipment that our EE Dept was using.  We use
> these little robots in some of our introductory programming courses (as
> it satisfies a multitude of constraints placed on me by the various Univ
> depts).  We have had success in increasing student interest in
> programming and developing skills with embedded systems, and, have had a
> great time.  Since the students are learning how to code, we have many
> many writes to flash over a semester.  I became worried about the
> lifespan of the system.  So, I thought moving to RAM would extend the
> years we will get out of the little bots.  I have not had the time to
> look into getting an RTOS loaded which might also address some problems.
> Philips flash programming tool.  Thoughts?

I don't know how many erase/write cycles are guaranteed for LPC2000s but
it should be around 10.000 per page. I guess the real number is much
higher but of cause not guaranteed by the manufacturer. Working only in
RAM will of cause increase the life span of your hardware.

Maybe you can create a simulator for your hardware based on a
open-source ARM-core simulator (o.k. not that easy) The students can do
their first "LED-blink" projects with the real hardware to raise
interest (simulators are not that much fun as the "real thing") but
later most of the time they can use the simulator for tests before the
"nearly finished" firmware gets uploaded to the hardware for the final
debugging/testing/playing.

You may find the c't bot projects interesting (
http://www.heise.de/ct/projekte/ct-bot/ ) . It has been initiated by the
German magazine c't and I don't know if there is some information in
English available (yahoo babelfish will help a little bit). They use
AVRs and not LPC2000 but there is a complete simulation framework
available (c't-sim).

Another option is to use a JTAG-interface (cheap Wiggler(-Clone) or
FT2232-based devices) and OpenOCD. It should be rather easy to automate
uploading to and running from RAM with such a configuration. As a
"side-effect" you will have the interfaces to demonstrate and use
"on-chip-debugging" in the courses which will be also interesting for
the students.

Martin Thomas

• $formula (LaTeX syntax)$