AnsweredAssumed Answered

STM32 UART reliability with high baud rate

Question asked by jalooc on Dec 8, 2015
Latest reply on Dec 10, 2015 by Clive One
Hello everybody,

I posted a question recently on stackexchange, but didn't get satisfying answer. It's related to reliability in STM32F3 UART communication at higher baud rates and the problem of loosing bytes in spite of applying numerous technics. I'd be grateful If anybody landed hand in that matter. Below I post the question:

I am using STM32F4 (bare metal with HAL library) as an HTTP Server. I don't implement TCP layer, because that is done for me by the WiFi232 D2 module - all I receive in the uC through UART is a string with pure HTML request (and all I send is a string with pure HTML response). The requirement of the application is to send one large response with SPA web page (almost 300k characters) and several tiny responses as AJAX (~200 chars). With 57600bps all works fine, but the big response takes 50s to load on the client, so obviously I have to raise the baud rate.

That was the scenery introduction, now the main play, where the problem begins: with everything above 57600bps, I loose message characters on the way to the browser. I loose them randomly - it's usually a row of contiguous characters; sometimes several, sometimes above hundred of them. Initially I played with blocking UART transceiving. When I noticed the problem, I changed for DMA and it made absolutely no change. I tested both cases sending through UART to FTDA -> USB -> Termite terminal instead of the WiFi module, and saw the same symptoms. Since every single simulation lead to the aftermath of lost data, I went to the extent of even crossing STM Tx with Rx and checking if everything works okay on the shortest of possible circuits and... it of course worked perfectly :) So the uC is excluded from the suspects.

So is it even possible to achieve reliable UART transmission? Do you have any clue for how to send HTTP msgs by UART at high baud rates? I feel that I exhausted all the possibilities, but it seems unprobable that 115kbps is to much, not even mentioning Mbps... Maybe I'm missing something simple? Applying hardware flow control corrects the transmission only a tiny bit, I still get errors on 115kbps (although less frequently then without it).

*Note, that I keep talking about HTTP msgs, because of their particular nature - I can't implement any framing nor software flow control algorithm, because I don't have power on the browser side of this communication chain.

Outcomes