gmgrpl wrote on Saturday, March 21, 2015:
I finally got around to being able to spend some more time troubleshooting this problem. I captured the ARP request output buffer before transmission in code composer studio and displayed it in unsigned byte style so that it is easier to verify. Here is what I grabbed:
FF FF FF FF FF FF 00 08 EE 03 A6 6C 08 06 00 01
08 00 06 04 00 01 00 08 EE 03 A6 6C C0 A8 01 8B
00 00 00 00 00 00 C0 A8 01 B7
The source (FreeRTOS) MAC is: 00 08 EE 03 A6 6C
The source (FreeRTOS) IP is: C0 A8 01 8B (192.168.1.139 assigned successfully using DHCP)
The destination (desktop PC) IP is: C0 A8 01 B7 (192.168.1.183)
The packet is 42 bytes long and looks correct to me - without any padding or CRC. I’m careful to delay the task transmitting UDP datagrams until a delay long enough for an IP to be assigned by DHCP). The hardware won’t transmit the ARP request packet. I didn’t see anything happen while sniffing with Wireshark so I can’t post a PCAP. I’m using 255.255.255.0 for my netmask everywhere.
The packet is in a buffer created by the call to pxNetworkBufferGet() at physical address 0x0800A1B8 - a 32 bit address boundary. I assume the hardware requires that boundary for the DMA to work properly (some DMA engines require a 32 byte boundary address).
As I traced through the packet creation up to transmission, I noticed the pointer to the buffer containing the packet is simply passed to the hardware for DMA transfer.
I found no definition for ipconfigPACKET_FILLER_SIZE in the FreeRTOS+UDP source code anywhere. Do you think the RFC requires padding for ARP packet? I’m going to attempt to research that.
I create a socket and transmit 5 floating point numbers (total of 20 bytes of payload) and I can receive them at the host once I ping the FreeRTOS target to get the host’s MAC address in the target’s ARP table. Would you like a PCAP of a standard UDP datagram transmitted from the FreeRTOS target?
Thank you for all your help.