We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi,
I'm trying the RL-ARM tcp/ip stack on a arm7 LPC2368 from ETT (futurlec). I succeed setting up a TCP listen socket with the EasyWeb API. But when I try to use the TCP stack from RL-ARM 4.12 I don't succeed.
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.
If I try to setup a TCP connection from my controller to the PC. several packets as described above appear.
Any idea?
Kind Regards.
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.
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.