Hi

I am using LPC2378 chip.

I have a simple memory test routine that I run on Ethernet SRAM
(16K) - which works fine, e.g.
1) Passes 16K and not a byte more
2) Fails when accessing past 16K
3) RAM fails, as it should when Ethernet controller power is not
enabled via PCONP.30 (as per Phillips Errata Ethernet.2)

However, same routine on USB's 8K SRAM works as follows:
1) Works even if the USB power not enabled (bit 31 on PCONP) -
sounds illogical, but I can live with that.
2) Passes more than 8K, in fact up to 16K. In other words, there
seems to be some addressable memory at addresses 0x7FD02000-
0x7FD03FFF, which is not documented.

It may be writing to some other memory, like a region of the main
SRAM?

I have confirmed that writing to "extra" USB RAM it is not
overwriting 16K of Ethernet SRAM.

Test routine is a simple "write a pattern and then read it back"
test. Entire pattern is written into SRAM and then read back.

I know this sounds unlikely, so does anybody have any thoughts?

Cheers

Michael Melkonian Start a New Thread

Well, first of all try not to write everything with same pattern.
For better testing write for example negation of adress in each 4 bytes;

PS Sorry if this message is doubled Start a New Thread

Well, first of all try not to write everything with same pattern.
For better testing write for example negation of adress in each 4 bytes; Start a New Thread

--- In l..., Wojciech Kromer
wrote:
>
> Well, first of all try not to write everything with same pattern.
> For better testing write for example negation of adress in each 4
bytes;
>

Hi Wojciech

Thanks for your reply. I am not trying at this stage to do the "best
possible" memory test. It is a different pattern that will be
written in lower 8K and higher 8K. Even the simple test I am doing
should not have passed if the memory wasn't there.

Basic code is below:

#define USB_SRAM_BASE (0x7FD00000)
#define USB_SRAM_SIZE (0x4000)

BOOL PHEAP_Test(void)
{
U32 i;
U8 c = 0;

// write a simple pattern to USB SRAM
for (i = 0 ; i < USB_SRAM_SIZE; i++)
{
*((U8 *)(USB_SRAM_BASE + i)) = c;
if (c++ > 171)
c = 0;
}

c = 0;
// read back memory from USB SRAM
for (i = 0 ; i < USB_SRAM_SIZE; i++)
{
if (*((U8 *)(USB_SRAM_BASE + i)) != c)
{
return FALSE;
}
if (c++ > 171)
c = 0;
}

return TRUE;
}

You can set USB_SRAM_SIZE up to 0x4000 and it will pass, anything
more will fail (an exception occurs, same if you attempt to write
past the end of Ethernet SRAM).

So it really does look like 8K more SRAM!

Thank you

Michael Start a New Thread

--- In l..., "michael_melkonian"
wrote:
>
> Hi
>
> I am using LPC2378 chip.
>
> I have a simple memory test routine that I run on Ethernet SRAM
> (16K) - which works fine, e.g.
> 1) Passes 16K and not a byte more
> 2) Fails when accessing past 16K
> 3) RAM fails, as it should when Ethernet controller power is not
> enabled via PCONP.30 (as per Phillips Errata Ethernet.2)
>
> However, same routine on USB's 8K SRAM works as follows:
> 1) Works even if the USB power not enabled (bit 31 on PCONP) -
> sounds illogical, but I can live with that.
> 2) Passes more than 8K, in fact up to 16K. In other words, there
> seems to be some addressable memory at addresses 0x7FD02000-
> 0x7FD03FFF, which is not documented.
>
> It may be writing to some other memory, like a region of the main
> SRAM?
>
> I have confirmed that writing to "extra" USB RAM it is not
> overwriting 16K of Ethernet SRAM.
>
> Test routine is a simple "write a pattern and then read it back"
> test. Entire pattern is written into SRAM and then read back.
>
> I know this sounds unlikely, so does anybody have any thoughts?
>
> Cheers
>
> Michael Melkonian
>
Hi Michael,

looking at the memory map of the LPC2378, there seems to be a "void"
above the 8k SRAM.

As far as I know the LPC23xx and LPC24xx are software compatible. May
be you check whether there is anything located at the address in
question on the LPC2400?

Bob Start a New Thread

Hi Bob

Exactly what I am saying, it is void 8K, yet there is some memory mapped to this region. I don't think manufacturer stuck an extra 8K there and forgot to tell everybody (although stranger things have happened).

Cheers

Michael

lpc2100_fan wrote:
--- In l..., "michael_melkonian"
wrote:
>
> Hi
>
> I am using LPC2378 chip.
>
> I have a simple memory test routine that I run on Ethernet SRAM
> (16K) - which works fine, e.g.
> 1) Passes 16K and not a byte more
> 2) Fails when accessing past 16K
> 3) RAM fails, as it should when Ethernet controller power is not
> enabled via PCONP.30 (as per Phillips Errata Ethernet.2)
>
> However, same routine on USB's 8K SRAM works as follows:
> 1) Works even if the USB power not enabled (bit 31 on PCONP) -
> sounds illogical, but I can live with that.
> 2) Passes more than 8K, in fact up to 16K. In other words, there
> seems to be some addressable memory at addresses 0x7FD02000-
> 0x7FD03FFF, which is not documented.
>
> It may be writing to some other memory, like a region of the main
> SRAM?
>
> I have confirmed that writing to "extra" USB RAM it is not
> overwriting 16K of Ethernet SRAM.
>
> Test routine is a simple "write a pattern and then read it back"
> test. Entire pattern is written into SRAM and then read back.
>
> I know this sounds unlikely, so does anybody have any thoughts?
>
> Cheers
>
> Michael Melkonian
>
Hi Michael,

looking at the memory map of the LPC2378, there seems to be a "void"
above the 8k SRAM.

As far as I know the LPC23xx and LPC24xx are software compatible. May
be you check whether there is anything located at the address in
question on the LPC2400?

Bob Start a New Thread

> Hi Wojciech
>
> Thanks for your reply. I am not trying at this stage to do the "best
> possible" memory test. It is a different pattern that will be
> written in lower 8K and higher 8K. Even the simple test I am doing
> should not have passed if the memory wasn't there.
>
>
I do not have LPC2372, but on LPC2148 with disabled USB it works like this:
if you write a value to any location then you can read it back from any
other location inside USB RAM.

Just writing negation of addres (or address or some index ) into SDRAM
is as simple as your code.
But it can check following errors on external SDRAM (in any architecture)
- adress line shorts
- adress wrap (ine case of missconfiguration for example)
- it's also usefull to detect bad refresh configuration Start a New Thread

--- In l..., Michael Melkonian
wrote:
>
> Hi Bob
>
> Exactly what I am saying, it is void 8K, yet there is some memory
mapped to this region. I don't think manufacturer stuck an extra 8K
there and forgot to tell everybody (although stranger things have
happened).
>
> Cheers
>
> Michael

Michael,

One possibility is that he "extra" RAM is in fact a duplicate of
another block of RAM (i.e. same memory, different address). This can
be caused by incomplete decoding of address lines.

You're memory test won't necessarily detect this.

Have you tried changing the test, as suggested be a previous poster,
to include the full address (or some value derived from it, such as
negating it) in the data stored?

See the code below (completely unverified!) for example.

Brendan

int check_ram(void *start_address, int length)
{
unsigned int *int_p;
unsigned int data;
int count;

count = length / sizeof(unsigned int);
int_p = start_address;
while (count)
{
data = (unsigned int) int_p;
*int_p++ = ^data;
count--;
}

count = length / sizeof(unsigned int);
int_p = start_address;
while (count)
{
data = (unsigned int) int_p;
if (*int_p++ != ^data)
{
return 1;
}
count--;
}

return 0;
} Start a New Thread