Lpc2000

USB RAM "uncloaked".

Yes, it is LPC 2148 issue, not a toolset's.

Obviously, if one uses USB peripheral, it has to be powered up.
That is done by PCONP=0x8000 0000;
or at the end of startup by this:

ldr r0, =PCONP
mov r1, #0x80000000
str r1, [r0]

The (side) effect is that it *also enables* the 8kb of USB RAM
(at 0x7FD00 0000). No wonder no one else noticed it before!

As soon as the RAM comes online it is filled with random values.
It might need to be cleared/init.

Now, this tidbit explains those crashes if one places stack(s) there
(in a linker file) without powering up USB.
The RAM is unavailable, you can "write" to it (not getting data
abort), but when you read it you get zeros.
Not good for stack operation.

It would be nice to have have this RAM segment initialized to zero
by segment_init, but I did not have time to mess with this.
Maybe someone else might have an idea.

There are no secrets, only mysteries. Now, cross this one out, please.
Next! :-;

Roger

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