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

Hello, 

This issue has been tracked internally.

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

 

With Regards,