Raw Ethernet: How can I remove the CRC upon receipt?

[PaulB_1]

Hello everyone, I have the following use case: I want to receive raw data via Ethernet, which works fine, but I have a problem: When I send 100 bytes, I only receive 14 bytes in my software on the MCU (STM32H7S3L8). I was able to fix this by setting
AutomaticPadCRCStrip to DISABLE. Now I receive 104 bytes, which is also not the desired behavior. After a little research, I found out that the 4 bytes are CRC, so I continued searching. After some searching, I found the CRCStripTypePacket property and set it to ENABLE, but unfortunately this property has no effect. What do I need to do to get my 100 bytes but not the CRC? Do I need to set something else? Is this a bug? Please help me, I'm stuck.

Thanks

stm32h7rsxx-hal-driver 1.2.1

Best regards,
Paul B

[Pavel A.]

This does not look good. Usually user doesn't ever need to disable auto-handling of CRC.

Do you have a custom board with custom PHY?

 

[PaulB_1]

Hello, thank you for your reply. The problem is not necessarily the automatic processing of CRC, but rather that I am not receiving the data I should be receiving. I have corrected my post above as it contained an error; it was 14 bytes, not 60.

Back to my problem: I send 100 bytes, index 0 has the value 240 and index 99 has the value 240, the data in between is all 0, only 14 bytes arrive at the MCU, which means I am losing data, but when I set AutomaticPadCRCStrip to DISABLE, I receive 104 bytes. I don't want to turn off Auto CRC, I want to receive all the raw data I send. How can I achieve this?

I have a NUCLEO_H7S3L8.

Thank you very much.

[Pavel A.]

So you have a Nucleo! Then can you build and test one of provided examples?

If they won't work, maybe your board or network gear (switch, cables) are problematic.

 

[LCE]

If this is using lwIP, are these 4 CRC bytes at the end of the "pbuf"?

What about reducing the length info of the packet by 4 ?

I have used raw ethernet only with the STM32 hardware PTP offload feature, with lwIP, and I was surprised that these raw packet buffers contained the complete TCP packet, including the ethernet and IPv4 header.

But I cannot remember that there were any CRC bytes. Using custom ETH driver, not HAL.

[PaulB_1]

No, I only use HAL, not LwIP. I receive the length and data via the callback.
void HAL_ETH_RxLinkCallback(void **pStart, void **pEnd, uint8_t *buff,
uint16_t Length)

I don't understand why there is a function called CRCStripTypePacket that is supposed to do this, but it doesn't happen. And as I said, when I send a legitimate Ethernet frame, it arrives correctly, but if it's not a legitimate packet, the data is truncated. I mean, what's the point of having MACFilter.PromiscuousMode = ENABLE
if not everything is received?

 

Thank

[SAHSTM]

Hello, 

This issue has been tracked internally.

An internal ticket (224306) has already been raised for follow-up.

 

With Regards,

[SAHSTM]

Hello,

Sorry for the delayed reply.

Based on our internal analysis, the reported behavior may be related to how the transmitted Ethernet frame is constructed and interpreted by the STM32H7RS Ethernet MAC.

When AutomaticPadCRCStrip is enabled, the MAC removes padding and the CRC/FCS for IEEE 802.3 length-based frames. The 104 bytes observed when this option is disabled correspond to the 14-byte Ethernet header, the 100 bytes following the header, and the 4-byte FCS.

Could you please provide the transmit buffer contents before transmission, especially:

• The complete 14-byte Ethernet header
• The values of bytes 12 and 13, indicating whether they contain a Length field or an EtherType
• The complete transmitted frame length
• Whether the 100 bytes represent the actual payload or padding

This information will help us determine whether the 14-byte result is expected MAC behavior or whether there is an issue in the frame construction or RX length handling.

With Regards,

[Jacob Michael]

It looks like the issue is related to how the MAC handles non-standard/invalid Ethernet frames rather than simply removing the 4-byte CRC. ST’s documentation shows that AutomaticPadCRCStrip and CRCStripTypePacket control different receive behaviors, and the default HAL configuration enables both.

Interestingly, this exact STM32H7S3L8 issue was later acknowledged by ST, with an internal ticket opened for follow-up. So if valid frames work but malformed/non-standard ones get truncated, it may be a driver/MAC limitation rather than a configuration mistake.