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

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.
Maybe this is not something to worry about and I can return to the
Philips flash programming tool.  Thoughts?

Thanks again for your time and efforts,

Jeff McGough
Computer Science
South Dakota School of Mines and Technology

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.

I'm glad to read that my projects are useful for you.

> 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.
> Maybe this is not something to worry about and I can return to the
> 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