TCP packet filled with 'U' 1392 bytes long

I have added this files to one Group:

.\main.c    (code above)
.\LPC2300.s (uVision added this file)
C:\Keil\ARM\RL\TCPnet\Drivers\LPC23_EMAC.c
C:\Keil\ARM\RV31\LIB\TCP_ARM_L.lib
C:\Keil\ARM\RL\TCPnet\SRC\Net_Config.c

And I used the default compiler options.
Check output create Hex, and use that Hex to flash with flashmagic.

I have added this files to one Group:

.\main.c    (code above)
.\LPC2300.s (uVision added this file)
C:\Keil\ARM\RL\TCPnet\Drivers\LPC23_EMAC.c
C:\Keil\ARM\RV31\LIB\TCP_ARM_L.lib
C:\Keil\ARM\RL\TCPnet\SRC\Net_Config.c

And I used the default compiler options.
Check output create Hex, and use that Hex to flash with flashmagic.

Add heap memory - at least 0x400 bytes.

I have set:
Heap_Size EQU 0x00000400
also:
Heap_Size EQU 0x00000800

Still the same.

I don't think TCPnet requires any heap (as specified in the startup) for 'basic' operation. The Keil example that I originally ran had it set for zero (and the current version of that demo still does).

It does, however, require a memory pool to operate. This is specified in Net_Config.C, which will be included in your project. You should check it's value.

In Net_Config.c
That should be the default 8K ->
#define MEM_SIZE 2000 ( * 4 = the default setting -> 8000 bytes )

I think you are right! I mixed up FlashFS with TCPNet. Ouch.

In Net_Config.c
That should be the default 8K ->
#define MEM_SIZE 2000 ( * 4 = the default setting -> 8000 bytes )

Sorry, my bad - I now see you mentioned that before.

"When the controller goes online, it send one packet (ARP notify) and it is filled with 'U' (55) the whole frame/packet, 1392 bytes long."

I'm confused about that one though. Are you saying that the packet is being sent from your board is completely filled with 'U'? or does it have the ARP message but is padded with 'U'? or something else?

Completly (the whole packet/frame) filled with 'U' (0x55)
from the first byte to the last byte.

A buffer overrun somewhere? Far fetched, but worth a try...

"Completly (the whole packet/frame) filled with 'U' (0x55)..."

As a first step, I would say you need to determine whether it is a bad packet that is being generated/corrupted or the MAC that is sending rubbish.

So ... put a breakpoint in the transmit routine of LPC3200.c and see what is being passed to that.

Tomorrow I will try to printf to the terminal COM console (don't have a debugger)

LPC23_EMAC.c -> void send_frame (OS_FRAME *frame)
I suppose this is located in Tx_Desc[idx].Packet ?
something like:

for( i ; i<30 ; i++)
{
 printf("%d " , Tx_Desc[idx].Packet[i]);
}

Should that do it ?

thank you all for the input.

"I suppose this is located in Tx_Desc[idx].Packet ?"

That would be the destination for the data. You might want to check it.

Firstly, you need to look at the parameter 'frame' - It contains the packet length (frame->length) and actual data (frame->data).

It's defined in Net_Config.H

because an arp request should be around 60bytes...
ok thank you.
Will keep you posted... tomorrow evening.

Hello All,

I tried the debugging but I wasn't going anywhere with it.

I have tried the example in 'C:\Keil\ARM\Boards\Keil\MCB2300\RL\TCPnet\LEDClient'
And that worked. (after deleting LCD stuff )

I created a new project.
then add all the files that the example uses. (same path, didn't copy them..)
didn't work either...

aperently LPC23_EMAC.c has specified options...
Memory Assignment:
Code <Default>
Zero Init Data: IRAM2
Other DATA: IRAM2

After setting those, everything worked.

Why is that ?
How did I suppused to know this ?

In case the ethernet code is making use of DMA, then the buffer memory must be in the RAM region supported by the DMA controller. Note that the processor have multiple memory controllers, to allow concurrent access to different RAM regions - so a DMA transfer can happen without being affected by the processor core reading/writing normal variables.