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.

[PaulB_1]

Hello, unfortunately, the examples do not show how to receive raw packets, but when I modify the example to receive raw packets, I get the same behavior. It cannot be a wiring error, as legitimate Ethernet frames are arriving, but I want to use my own protocol. There must be a way to receive raw packets. We are talking about embedded software here.

[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

[Pavel A.]

>  but when I modify the example to receive raw packets, I get the same behavior.

So, if you start from one of these ready examples, can you get them working well?

a. Does ping of various packet sizes work well (confirmed with sniffer)?

b. Does UDP or TCP of various payload sizes work well (no loss, retransmissions)?

If so you can bypass LwIP and use only low_level_input & low_level_output for raw packets (after configuring the descriptors, unicast/multicast filtering etc.). When this works well, continue tweaking the ETH as you want.

[SAHSTM]

Hello, 

This issue has been tracked internally.

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

With Regards,