3
\$\begingroup\$

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.


EDIT: Some more observations:

  • With RST/CST flow control I can see a pattern in transmission (@230kbps): contiguous ~45056 OR ~28672 characters are sent correctly, then I loose a couple of characters, and then again - ~45056 OR ~28672, then loose couple of chars etc. Note, that the number of contiguous correct characters is always one of the two mentioned (+/- a couple).
  • Without flow control I (as anticipated) get the following pattern: transmit EXACTLY 8191@115kbps or 4095@230kbps contiguous correct characters and then loose around 90@115kbps or 110@230kbps characters. What is strange though, is that I don't loose characters in any other spot...

In accordance to those observations, I prefer to use no hwfc and simply add some delay at the well-known spots (after every 8191st or 4095th char, depending on the baud rate). However this is very hackish, I hate this solution and I hope there still is some better way to solve that problem.

\$\endgroup\$
  • 1
    \$\begingroup\$ Check out table 133 of the reference manual and try a UART baudrate that has a low percentage of error. Also, did you check if the UART module on the uC is entering any error conditions like an overrun or framing error? \$\endgroup\$ – Adam Dec 4 '15 at 19:15
  • \$\begingroup\$ An UART requires that sender and receiver use matching clocks. At higher baud rates, the clocks become less accurate because the relative error is higher. What clock source are you using? \$\endgroup\$ – CL. Dec 4 '15 at 20:10
  • \$\begingroup\$ Haven't tried it with the F401 I use currently, but the F051 was running fine with up to 512kbps (haven't tried more as it was fast enough). Though the UART differs a bit, I'd say it should be totally possible to achieve high baudrates reliably. \$\endgroup\$ – Arsenal Dec 4 '15 at 22:29
  • \$\begingroup\$ Adam the higher the baud rate, the bigger the percentage, so picking the lower relative error fights with my initial goal of raising bps :) As to ORE and FE, they don't really happen in tx, do they. @CL. I'm testing it on the Discovery board, so it's external 8MHz with PLL raising it to 168. Arsenal UART on the uC side works fine - as I wrote, I tested it by crosing Tx with Rx. It's the WiFi module what looses characters. \$\endgroup\$ – jalooc Dec 5 '15 at 12:26
3
\$\begingroup\$

Sounds like a flow control issue to me. A Wifi module requires this at higher baud rates, because it can't send out packets at full speed - the internal buffers run full. If your MCU supports it you should use an UART with hardware flow control signals (usually called RTS and CTS).

\$\endgroup\$
  • \$\begingroup\$ I mentioned in my post that unfortunately I cannot do that (because the pins on the board are taken). \$\endgroup\$ – jalooc Dec 5 '15 at 11:33
  • 3
    \$\begingroup\$ RTS/CTS flow control can be implemented using GPIO interrupts. If you don't have any pins free you need to redesign your board. \$\endgroup\$ – Turbo J Dec 5 '15 at 11:50
  • \$\begingroup\$ I'm afraid that redesigning is necessity in this case, although it's a costly maneuver.. This GPIO hfc implementation is an interesting idea though, didn't think of it myself. Thanks for that! \$\endgroup\$ – jalooc Dec 5 '15 at 12:08
  • \$\begingroup\$ I'm using the built-in to STM32F4 hw flow control, but after many experiments, the reliability rose just a tiny bit (I can now send in 115200bps but even then I have some char lost every ~5th message). Shouldn't RTS/CTS virtually rule out any characters loses? I'm really confused right now... I have huart3.Init.HwFlowCtl = UART_HWCONTROL_RTS_CTS set, I check TC & TXE flags before every transmission start, I always wait in a loop when HAL_BUSY, I don't get any errors during transmission and the receiving module is supposed to work even with 460800... Should there be something else done? \$\endgroup\$ – jalooc Dec 6 '15 at 18:30
  • \$\begingroup\$ Did you remember to configure the Wifi module to use RTS/CTS flow control too? This is usually not the default config. \$\endgroup\$ – Turbo J Dec 6 '15 at 18:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.