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