AnsweredAssumed Answered

Checksum of each IP Header is not calculated after some point (STM32F4, CubeMX, LwIP)

Question asked by Michael Steinecke on Sep 23, 2014
Latest reply on Nov 17, 2014 by schillstrom.hans
Hello Folks,

its me again. I've discovered another strange behavior with a STM32F429ZG custom board in conjunction with LwIP 1.4.1 (and FreeRTOS). Everything goes smoothly for some time, several transfers and so on. But from one point on, the checksum calculation for all outgoing packets fails or is not executed entirely.
In the attached pcap file, I've transferred the same file (~10 MB) from SD-Card several times. Beginning with packet 68320 every outgoing IP Header has a checksum of zero. Eventually every packet gets discarded by PC. Then with packet 68341, the PC sends another command. The MCU tries to ACK it, but still no checksum. Conclusion: checksum on receive either works or ist not checked by MCU.
After the RST from PC, the MCU falls back in auto discovery state. For that, TCP data port 55557 gets closed and a new accept() socket with the same port is initiated.
Now we can see a lot of UDP 55555 and DHCP discovery broadcasts. Each of them with the same problem.
After a reset of the device, everything is working smoothly again.

Checksum calculation is done by HW (SW calculation in LwIP turned off), therefore I would expect another STM bug. Is there something known? Some ideas how to track down this?

PC: 192.168.111.63
MCU: 192.168.111.200

Turn on checksum calculation in Wireshark. (UDP/TCP settings)

http://lwip.100.n7.nabble.com/file/n23334/IP-Header_CRC_not_calculated_one_transfer.pcap

Edit:
The CRC module itself is not activated/used (stm32f4xx_hal_crc.c)

Edit 2:
- Turning on software generated checksums by LwIP eliminates the error. Therefore it is most likely a driver or hardware issue.
- Replaced ambiguous CRC by checksum.

Outcomes