Lpc2000

> I have found so far, that by making changes to linker file, RAM  is
> there available for RD/WR, but C-Spy will *not* show anything but
> zeros; it treats it as ROM, any overtyped value is ignored.
> I have downloaded JARM.DLL ver 3.14, replaced my 2.74c, with no
> difference in behavior. 
> Is anybody outhere able to see in C-Spy the USB_DMA RAM as RAM? 
> 
> I appreciate your feedback. 
> BTW, EWARM 4.31A is out, have not tested it, yet. 
> My observations were for ver. 4.30A.
> 
> Thanks!
> 
> Roger

Hi Roger,

Thanks for your input on this too.

For what it's worth, I'm using Keil / uVision 3 with the ARM 
development tools, and I only read back zeros as well.

I first noticed the problem with USB RAM when my code crashed in ISRs 
while running directly out of flash, no JTAG or debugger at all.

Turns out the writes to the IRQ stack (i.e. IRQ mode R13 set to point 
into USB RAM) went into the great bit bucket, so when popping the LR 
from the stack,  PC = 0x0000.0000 and off we go....

(One thing that is frustrating, I guess it was a design choice by the 
engineers at Keil -- if in the debugger I modify (for example) memory 
0x7FD0.1000 to a value of 0x55, it shows the change -- until I step 
the next instruction.  Then it changes the displayed value back to 
0x00.  Um, is there a reason the value isn't read back by the 
debugger immediately after it is written, so that what is displayed 
reflects what is *really* in the memory?  I'm willing to wait the 
extra few usec/msec for that benefit.  :-)  )

I was hoping to just "manually" carve/manage the 8K USB RAM block 
myself for things like task & interrupt stacks, ring buffers, etc...  
In other words I wanted to avoid scatter/gather linker files, and 
compile-time locating of structures.... at run time I'll just point 
into the USB RAM and carve it up.

I'm actually shocked that no one else has tried to use the USB RAM 
for something other than USB (at least no one has chimed in that 
effect).

I'll keep you posted on what I find.