Lpc2000

Just my2cents now... I had noticed this thread and thought it was about 
the debugger (which I don't use), not thinking it was something as 
mundane as the USB enable. I have been using the USB RAM since day one 
and have never had a problem with it. Of course, I had RT*M and set the 
appropriate bits to enable it :)

10centslater,
*Peter*

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
>
> --- 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.