receive unknown length frames with UART

[Adam98]

Hello everyone,

I’m working on an embedded project where I need to receive a variable-length stream of bytes via UART on an MCU  STM32H750. The key points are:

• All bytes are payload, no start or stop bytes, no protocol framing.

• The number of bytes is undefined and variable.

• The byte stream starts when the MCU is ready.

• I need to calculate CRC (Ethernet CRC32) over all received bytes.

• After receiving all data, I must output the CRC via UART.

• The UART baud rate is very high (greater than 900,000 baud).

My current approach:

• I use UART interrupts to receive bytes one by one.

• I update the CRC continuously with every received byte inside the interrupt handler.

• This works fine for small data, and CRC calculation seems correct.

• However, when I try to receive a large file or big data stream, the CRC isnt correct, the crc will be outputed before the whole data recieved.

I suspect the problem is related to handling the continuous stream without any start/stop or length information, and possibly buffer management or interrupt handling at such a high baud rate.

My questions:

1. How can I reliably receive an undefined-length UART stream without framing or start/stop bytes?

2. What techniques can I use to detect the end of transmission if there is no protocol?

3. Are there best practices for handling UART reception and CRC calculation in an interrupt-driven system at very high baud rates?

4. How can I avoid losing bytes or corruption when the incoming data size is large?

5. Any example code snippets or references for a similar use case would be great!

6. I try to use dma (ping pong buffer and update crc but it dosent work because i cant find the best time and place to calculate crc...)

Thanks a lot for your help!

[Karl Yamashita]

Depending on your clock speed, setting for 921600 doesn't mean it's exactly 921600. If you play with the clock especially with a high baud rate, sometimes CubeMX/STM32CubeIDE will give a warning that there is an error greater than some %.

There could still be a slight % error, but CubeMX may not give a warning if it's under a threshold? I'm just assuming about the threshold, so take that with a grain of salt. 

Since you're using TeraTerm, i assume you're using some USB-Serial adapter. That adapter too, could have a % error.  

Maybe check with a scope to see if indeed both devices are exactly 921600?

[Pavel A.]

> There could still be a slight % error, but CubeMX may not give a warning if it's under a threshold? I'm just assuming about the threshold,

Why CubeMX should be concerned? 1Mbit/s is not a terribly high rate for UART (maybe 2.5 Mbit/s is marginal) but can work with proper connections. CubeMX is not responsible for this. For higher bitrates better ways exist, based on LVDS and similar.  Reasonable data corruptions can be worked around by software. (sorry, can't give any ready code to copy-paste).

[Karl Yamashita]

I must be getting too much caffeine and not seeing straight.

[Karl Yamashita]

I have a H750 to work with. Can you upload your IOC file so I can start off with your configuration?

[Adam98]

i have uploaded now

[Tesla DeLorean]

The higher the rate, the less well it will divide into the Peripheral Clock, but it's not a cumulative error, on the Rx side it should be resyncing/framing based on the bit centers.

I would not however be sending megabyte, or multi-megabyte, packets across a async serial connection. Protocols like XMODEM-1K were developed to allow for flow-control and integrity in file transfers. Certainly what I'd use to push firmware updates, and allow for write to FLASH internal or external, or eMMC / SDCard

[Adam98]

I didnt get an % error considering my configuration, i think the problem that the my Programm dosent handle the data properly while the communication baudrate is too fast and the data is big