Lpc2000

Hi,

Do I need to do anything special to use the 8K block of RAM on the 2148 
located from 0x7FD0.0000-0x7FD0.1FFF?  (The one earmarked for USB DMA 
transfers).

I won't be using the USB functionality & figured that gives me another 
8K of RAM.  However, writes to this 8K region seem to have no effect 
(read back 0), at least through the debugger.

Perhaps there is some register that needs to be told "enable the USB 
DMA RAM for general purpose use by the CPU"?

Thanks!

--- In lpc2000@yahoogroups.com, "shergtu" <shergtu@...> wrote:
>
> Hi,
> 
> Do I need to do anything special to use the 8K block of RAM on the 2148 
> located from 0x7FD0.0000-0x7FD0.1FFF?  (The one earmarked for USB DMA 
> transfers).
> 
> I won't be using the USB functionality & figured that gives me another 
> 8K of RAM.  However, writes to this 8K region seem to have no effect 
> (read back 0), at least through the debugger.
> 
> Perhaps there is some register that needs to be told "enable the USB 
> DMA RAM for general purpose use by the CPU"?
> 
> Thanks!
>

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

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

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

shergtu,
I saw this happening, too; in C-Spy - *all* registers=0x0. But not always.
After an incident like this, it is better to reboot the JTAG and start
again.
 
> (One thing that is frustrating, I guess it was a design choice by the 

Yes, frustrating, but since you see it also in KEIL uV/uLink, I wonder
if it has to do with 2148 only, rather then toolset vendor.

> 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 am about to test whether it is JTAG comm speed sensitive, last straw
that I am grasping....
 
> 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).

Yes, that puzzles me too. So many USB design comments around, yet no
one said anything about this USB RAM "invisibility". 
Hm.
 
> I'll keep you posted on what I find.
>

Please do. I promise the same.

Thanks for your comments.

Take care

Roger

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

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

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.

--- In lpc2000@yahoogroups.com, Peter Jakacki <peterjak@...> wrote:
>
> 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*

Peter,

2 cents or 10 cents, it's your money.... 

But as long as we're tossing smilies around: if you could come off 
your throne( :) ) long enough to enlighten us as to exactly *where* 
in the manual it is stated that the 8K SRAM is only enabled when PCONP
[31] is set, boy would it be helpful.

After all, you did say (OK, you implied -- "RT*M") that it was in the 
manual, correct?

Note that I'm asking where the information is stated, not what you 
inferred from what you read.

P.S.  I only had to set one bit - PCONP[31] - to use the USB RAM 
properly.  What other bits are you setting to enable it?  (You did 
say you the "appropriate bits", eh? :) <--- that pesky smiley again!)

Sorry if I came off a bit offensive :( , just meant to say that I 
thought your question was a debugger issue. I can't recall where I found 
out about the USB RAM but it was necessary to enable the USB peripheral 
before it would work. I don't use jtag debug as I develop and debug in 
Forth and it was a very easy exercise to find out what was going on when 
I couldn't access the RAM just as it is also in checking out the rest of 
the hardware.

The truth is, it's been a while since I did all that and if I remember 
the USB block diagrams show the RAM as part of the USB peripheral off 
the AHB rather than the normal RAM hanging off the local bus. So I guess 
it seems logical to assume that if the USB is powered-off then the RAM 
is also. So it's more a matter of looking at the diagrams than reading 
the text in this case (I consider myself more of a hardware than 
software guy).

Contrary to what I may have implied (I was very tired), there is only 
the PUSB bit to set to access the RAM.

Once again, my apologies,
*Peter*

P.S. The smilies are a compensation for lack of face-to-face in case I 
do unintentionally manage to offend.

shergtu wrote:

> 2 cents or 10 cents, it's your money.... 
>
> But as long as we're tossing smilies around: if you could come off 
> your throne( :) ) long enough to enlighten us as to exactly *where* 
> in the manual it is stated that the 8K SRAM is only enabled when PCONP
> [31] is set, boy would it be helpful.
>
> After all, you did say (OK, you implied -- "RT*M") that it was in the 
> manual, correct?
>
> Note that I'm asking where the information is stated, not what you 
> inferred from what you read.
>
> P.S.  I only had to set one bit - PCONP[31] - to use the USB RAM 
> properly.  What other bits are you setting to enable it?  (You did 
> say you the "appropriate bits", eh? :) <--- that pesky smiley again!)