You are not logged in.
Pages: 1
I met a problem when I try to send the big mass data through UDP protocol from the PC to Warp board. Firstly I call the UDP socket write packet method once a time for a whole bunch of data and these data are sent through the IP fragmentation to the WARP. However, the emac_handler ceased to process correctly, because it, except the first IP packet, can not receive the following fragments. And then I split the whole data to small pieces and send them via multiple independent UDP packet without fragmentation invovled. Then emac_handler works well.
I don't know why?
Offline
My thinking is that the IP fragementation is non-related to the ethernet core drivers, and the IP software can handle the reassembly. But the emac_handler can not work well even it works on the MAC level. It totally confuses me.
Offline
It depends entirely on what your C code is doing. By default, the WARPMAC EMAC handler doesn't care about IP; it filters only on ethertype, looking for WARPnet packets. If it's not a WARPnet packet, it calls the user emac handler. I'd suggest adding some printfs to the various emac functions to see how far the suspect IP packets make it into the C code.
Offline
yes, i also think that the WARPMAC EMAC handler doesn't care about IP. However, when I use the printf in the emac_handler, it always print unrecognized junk characters to my serial port after receiving the second IP fragmentation and then stops. I checked the memory and seem that the rest of the rest of the IP fragmentation did not arrive the xil_fifo at all. If I change the data source to independent UDP packets instead of using the IP fragementation mechnism, the whole software works well and the printf also works well.
Offline
Corrupt UART output and a hung processor usually indicate some kind of memory corruption. Have you changed any of the Ethernet handling code- are packets still being copied via DMA to the PHY packet buffers?
Offline
Pages: 1