Skip to main content
markb
markb
Associate III
October 6, 2015
Question

Flow control not working as I expect

  • October 6, 2015
  • 25 replies
  • 3777 views
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
    This topic has been closed for replies.

    25 replies

    Show previous replies
    Gerardo GALLUCCI
    Gerardo GALLUCCI
    ST Employee
    October 19, 2015
    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
    markbAuthor
    Associate III
    October 20, 2015
    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
    Gerardo GALLUCCI
    ST Employee
    October 20, 2015
    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
    markbAuthor
    Associate III
    October 21, 2015
    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
    Gerardo GALLUCCI
    ST Employee
    October 21, 2015
    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

    Terms & ConditionsAccessibility statement