Lpc2000

Roger - way to go buddy!

Thanks a lot for discovering how to unlock the 8K USB RAM. I was 
starting to hunt for areas to trim in my code because I was about to 
bang into the end of the main 32K region.

It's funny -- before I posted the original question, I:

a) tried enabling the USB PLL just in case that was undocumented but 
necessary to use the RAM (seemed unlikely but you never know...)

b) hunted in the *USB section* of the manual for a "RAM enable" 
or "peripheral enable" bit....

But I didn't enable the peripheral itself  (bangs head into wall 
repeatedly...)

Anyway, I'm sure many will benefit from your findings.  Nice work.

(Now go out & enjoy your weekend!)

-dan


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