Some MCUs with integrated Ethernet MACs support checksum offloading, meaning that they autonomously compute checksums. In order to use that feature, the network stack must both disable that in firmware and enable it in the ethernet driver. Possibly your code disables it in the stack but doesn"t enable it correctly in the driver. Search the code base for offload to get a start…
My Ethernet controller does calculate the CRC of the Ethernet frame (and checks it on Rx) in hardware.
I should clarify that the checksum that is missing is in the ICMP packet - is that something that can also be optionally offloaded to hardware?
Ah! I think I have misinterpreted the ipconfigDRIVER_INCLUDED_TX_IP_CHECKSUM and ipconfigDRIVER_INCLUDED_RX_IP_CHECKSUM settings. The key is in “IP”. 
Seems I was assuming these also applied to the ethernet frame checksum, but something that is becoming more and more apparent to me is what bits are handled by the driver and what is handled by FreeRTOS - Im getting there. Setting them back to defaults (removing them) now has the checkum being calculated and pings being recognised!
Sorry for te noise! 
@tomstorey wrote:
My Ethernet controller does calculate the CRC of the Ethernet frame (and checks it on Rx) in hardware.
Yes, I think that all Ethernet controllers do this automatically.
When ipconfigDRIVER_INCLUDED_TX_IP_CHECKSUM is zero, the IP-stack will calculate both the IP and the protocol checksums. If it is non-zero, the stack assumes that either the driver or the hardware will calculate it.
When the protocol checksums are offloaded, normally there is no problem for TCP and UDP.
The ICMP checksum is often a bit problematic. I have seen 3 possibilities;
- ICMP is calculated (offloaded) automatically
- The EMAC expects that the ICMP CRC-field is cleared, containing 2 zeros.
- The ICMP checksums are not offloaded, only TCP/UDP.
I do not know how this works on your platform AMD LANCE Am79C90.
Hi Hein,
I think the LANCE is much too simple to do any IP checksum calculation itself, so this needs to be done in software. I believe it simply transmits the literal contents of the packet buffer that you give it, but it can do the ethernet checksums itself.
Ive just run a simple test after (I believe) fixing my crashing issue, and I was able to hammer it with 200pps, so working pretty well right now.
It crashed and burned at 500pps, but that may be related to my current lack of error handling, so I’ll see how I go once that has been beefed up some more.
Have decided to shelve this project for now.
Been looking into the crashing issues all week, and its looking more and more like the issue is with one of the proprietary Cisco chips on the board. It seems that it gets hung up and the bus completely stalls at that point because it does all of the arbitration. Theres probably another register that I need to find and program (since none of it is documented), but thats way more effort than I want to go to right now.
My port seems to work fine when the hardware is behaving, so Im going to have another go with another platform that has less proprietary stuff to get in the way. Maybe I’ll come back to this one at a later date.
Will take all of the knowledge I gathered from here and build a new port for a system with a Motorola 68360 instead - I want to have one fully functional!
Thanks for your help so far!