Flow control not working as I expect

markb · ‎2015-10-06

Posted on October 06, 2015 at 16:31

Next problem...

I have enabled flow control on the module and the MCU and now attempting to use a bit rate of 460800.

Both ends are using the right bit rate but only the MCU appears to be controlling an RTS signal. The RTS output

on pin 10 of the module goes low on module initialisation and stays low even when I send a lot of data to the

module. The module is in data mode. Not exactly sure what data is getting lost but the comms protocol between

the MCU and the client (via a websocket) is failing. Using exactly the same hardware and software but a lower

bit rate (115200) works absolutely fine.

Is there anything else I need to do apart from setting console1_hwfc to 1 and turning on RTS/CTS flow control

on the MCU?

Cheers,

Mark

markb · ‎2015-10-19

Posted on October 19, 2015 at 22:28

Hi Jerry,

Thanks for responding.

Yes, I have followed that other thread. I am seeing overrun but it is understandable because the module is never driving RTS high to stop the MCU from sending.

I have two prototype boards, both boards contain WiFi modules that are flashed with the current firmware release. Both boards behave the same. The RTS signal

from the module is tri-state when the module is in reset and when it comes out of reset the RTS signal goes low and stay low.

Baud rate is 921600, console1_hwfc is set to 1. If I send lots of data to the module, overrun occurs.

Either both modules are somehow broken or I'm doing something incredibly dumb!

Cheers,

Mark

Gerardo GALLUCCI · ‎2015-10-19

Posted on October 19, 2015 at 22:41

I dont know how to help you.

checklist:

- SPWF module: variable set

- external MCU: USART_HardwareFlowControl_RTS_CTS set

- wires: RTS to CTS, and CTS to RTS

that's all!

Have you got a Discovery/Nucleo board to test flow control? I can try to reproduce your environment.

markb · ‎2015-10-20

Posted on October 20, 2015 at 12:28

Hi Jerry,

Yes, please share your test project source, maybe there is something in there that will help me find what's wrong.

Cheers,

Mark

Gerardo GALLUCCI · ‎2015-10-20

Posted on October 20, 2015 at 21:42

In attach.

I used USART2 on PA1 (RTS), PA2 (Tx), PA3 (Rx)and PD3 (CTS)GPIOs

j

________________

Attachments :

Test_WiFi.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I1Mu&d=%2Fa%2F0X0000000bmv%2F3YYrnmwyW5_GBf1JZ7g_UbNMrrK8hWxYSHjuSYFUjTw&asPdf=false

markb · ‎2015-10-21

Posted on October 21, 2015 at 09:58

Hi Jerry,

Thanks for the example code.

I noticed that you are using the DMA routine to transmit to the UART and I have just been using the very slow HAL_UART_Transmit() so I wondered what would happen if I sent the data to the UART as quick as possible. So instead of calling HAL_UART_Transmit(), I directly tested the UART TXE flag and wrote

the data directly to the DR register. Did it make a difference? Yes, it now crashes the WiFi module when I send lots of data! Not the change I hoped to see.

I think I will wait until the new firmware arrives that fixes the overrun issue someone else reported and see if it makes any difference.

BTW, your example code does not show any of the AT commands that you use to set up the module, how are you doing that?

Cheers,

Mark

Gerardo GALLUCCI · ‎2015-10-21

Posted on October 21, 2015 at 10:24

I use that application only to stress socket server DataMode (step #2).

I set AT-commands before (step #1), through an home-made Y-cable :)

PC<->SPWF<->STM32F4.

Obviously I need to ''cut'' push-pull lines (RTS and TX) before switching first step into the second one...

j