Re: [lwip-users] LWIP Raw API receive issue

[M S ARUL]

Hello Sergio,

    Thanks for your time.

    //You are _SENDING_ 512 but you are receiving "upto" 200, what does that mean ??? //

That means p->tot_len is 512 or the exact no of bytes I have transmitted. 

//They might be chained, you can't memcpy(somewhere, p, p->tot_len), you need to go pbuf by pbuf copying p->len and checking p->next until you extract tot_len bytes; or just use the pbuf handling functions like pbuf_copy_partial()// 

This could be the reason, I need to check this. As I'm on vacation I'll check and follow up with this thread on Wednesday.

//Being that you are running on bare metal, and you didn't say if you are respecting the threading rules// 

I have registered callback functions for tcp_recv, tcp_sent etc. 

//Unless you have DMA which you did not say//

Yes DMA is used. I'm using SAMA5D35 processor. I have created buffers and the locations of the buffer is stored in buffer descriptor and the location of that descriptor is stored in the DMA Queue pointer.

Thanks & Regards,

ARUL PRAKASH M

On 12-Jan-2018 11:27 PM, "Sergio R. Caprile" <address@hidden> wrote:

>> Did youcheck your driver and port are OK
> Yes I have checked that, I am able to receive and transmit without any
> problem if the size is less (approximately less than 100 bytes, could
> be upto 200). As for the driver is concerned I have run the http
> server using this driver, it is able to send upto 512 bytes to the
> client without any problem.

That is not a proof.
You are _SENDING_ 512 but you are receiving "upto" 200, what does that mean ??? You have to receive everything you send to the device, be it in one or several pbufs, being each pbuf one contiguous block of memory, or many (chained).

Are you correctly "traveling" your received pbufs ? They might be chained, you can't memcpy(somewhere, p, p->tot_len), you need to go pbuf by pbuf copying p->len and checking p->next until you extract tot_len bytes; or just use the pbuf handling functions like pbuf_copy_partial()

AFAIK, it is either that or your driver/port is broken.

Being that you are running on bare metal, and you didn't say if you are respecting the threading rules, you should have a means for the Ethernet controller to say there are frames available, that will a) be remembered or b)trigger the extraction of the frame to be put "somewhere" (e.g.: a queue).
in the main loop:
In case a) you will call the input which will call the driver and extract the frame and give it to lwIP.
In case b) you will extract those frames from "somewhere" and call the input to deliver to lwIP.
NO CALLING lwIP LOW-LEVEL FUNCTIONS FROM DIFFERENT CONTEXTS, either all main or all interrupt.
Check the wiki and the docs if in doubt.

Being that you are running on bare metal, use your debugger and put a breakpoint in those places to see whether you are trashing your data before entering lwIP or you need to check your app again.

Unless you have DMA which you did not say, and I cant help you there.

_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users