STM32 UART reliability with high baud rate

[jalooc]

Posted on December 08, 2015 at 17:32

Hello everybody,

I posted a

http://electronics.stackexchange.com/questions/204376/stm32-uart-reliability-with-high-baud-rate

 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.

[Tesla DeLorean]

Posted on December 08, 2015 at 18:57

I don't use the HAL, bit of a buggy festering mess for my tastes, so I'll give my general observations.

I've used USARTs on a continuous basis logging data at 115200, can't say I've observed issues with that. Lot of checksummed binary blocks, can't say I've seen packet loss or pattern sensitivity. I've done firmware updates on STM32 parts using 460800 and 926100 using X-MODEM type protocols, and haven't seen them get in to failure states, though they are designed to be self recovering. The tools I've used have error/failure stats, can't say I've seen them flag any anomalies. I've updated modems from STM32 parts at 2 or 3 Mbps, with files around 15MB, can't say I've had problems there. The one-and-done nature of these protocols means things would be failing all over the place, the packets are validated, and will abort rather than retry/continue. This use case most closely matches the one you present. I've had lots of issues on PC's with Prolific and recently FTDI drivers, the former sometimes have demonstrable data loss, and screwing things up over time, and drivers blue screening machines. And FTDI destroying a number of devices they deemed counterfeit. I won't buy or specify anything using FTDI parts again, so that should work out really well for reducing their product in the channels. Serial data framing can be problematic when symbols are tightly packed, I'd try 2 stop bits on transmissions. Higher baud rate generally have higher bit-timing error due to the granularity of the clock source. I could do some real thorough validation of the USART, but my gut tells me the issue is not with the STM32 peripheral. There's really no buffering there to manifest the kind of episodic behaviour you describe.

[stm322399]

Posted on December 09, 2015 at 09:48

I had no pb running STM32L151 UART @500Kb to exchange data with another MCU.

IMHO, an F4 shall run @1Mb without issues. I am not sure to understand what kind of test you performed ''crossing STM Tx andRx'', are you talking about an external loopback ? Loopback testing is good, because it can show that software is in order of work, and maybe highlight that your connexion to FTDI is poor, or the FTDI itself, or anything far away from the control of the STM32f4. On the other side, loosing a char after 8191 or 4095 transfers can not be coincidental. it smells like an internal buffer to be full. What if FTDI cannot send data to the USB link fast enough ? What is the driver on the other end ? windows usbser ? You probably need to make loopback tests on either ends of the serial link.

[jalooc]

Posted on December 10, 2015 at 12:05

@clive1 Unfortunately I can't implement any framing / checksum checking, because the module works in transparent transmission mode and whatever I send to it, it sends it to the browser. Due to that and the HTTP style of messages, there can't be any packets validating implemented. Btw. FTDI is used only on a side, all the test results I posted were taken from the STM32 <-> WiFi module communication.

@ FTDI is just addition for validation. I agree with your statements and also anticipated possible data lost on it's side. The main part, however, is communication with the WiFi232 D2 module and that fails too. And yes, by 

''crossing STM Tx andRx'' I meant external loopback, so the STM itself is ruled out from potential problem causes. Loosing characters every exactly 

8191 or 4095 bytes is due to, as I wrote, buffer overrun on WiFI module side and it happens only without hardware flow control - this is totally normal and predictable. What was strange though, was that after implementing rts/cts, I also noticed a pattern, although a tiny bit more fluid - contiguous correct characters were received in browser for around 

~45056 OR ~28672 bytes. It helped somewhat when I put a wait function after every 28000th byte, but still lost a pair of characters per whole message (230kB) - unfortunately in terms of a web page code this is unforgivable.

[Tesla DeLorean]

Posted on December 10, 2015 at 17:37

Yes, I understand that, but that doesn't preclude you from validating the connectivity, and software in the chain using those methods until you've figured out WHERE your problem is.

Someone's got some buffer/boundary issues, because the issue doesn't sound like one with the STM32 HW. If I where you, I'd implement a continuous link on the serial port using a pseudo-random sequence, with the SPL or at the register level, and test the snot out of it.