cancel
Showing results for 
Search instead for 
Did you mean: 

Flow control not working as I expect

markb
Associate II
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
25 REPLIES 25
Posted on October 07, 2015 at 09:53

Hi Mark,

var config is enough to enable flow control. save and reboot.

This is how module's RTS/CTS lines works:

- CTS stops module's UART TX line. Used when external host is not ready to accept data on its own UART RX line;

- RTS signals to external host that it must stop sending datas to module. When DataMode is enabled, and a continuous stream is incoming, RTS switchs state when internal buffers are full (NOT after every byte, as default behaviour on some MCUs), and socket server must output that bytes over the air to empty buffers. When in CommandMode, RTS should never switch since buffer are bigger than ATcmd length (be sure to always expect/wait OK/ERROR).

If you think flow control is not working, I suggest an higher baudrate (921600), and an oscilloscope on RTS line.

What's your use case? Socket server, payload size, sending rate, etc?

Ciao

j

markb
Associate II
Posted on October 07, 2015 at 10:21

Hi Jerry,

Thanks for the explanation of how the flow control operates. That's useful info that should be in UM1695!

I am continuing investigation, almost certainly I have done something dumb.

Cheers,

Mark

markb
Associate II
Posted on October 07, 2015 at 10:53

Jerry, do you know how much buffer space is available in data mode because I am not seeing any activity on the RTS line. Now using 9621600 baud.

It is currently failing when I send just over 10KB but somewhat lesser amounts are getting through OK. RTS line from the module

stays low all the time. I have a external pull up on that line and when I reset the module it goes

high and then low again so I know the module is capable of driving that signal.

I have a wireshark capture that shows the point at which the Websocket protocol goes wrong which I can send to you but I think I need to investigate

it first.

Cheers,

Mark

markb
Associate II
Posted on October 07, 2015 at 12:06

Jerry,

Using:

#  console1_speed = 921600

#  console1_hwfc = 1

What I am seeing is this: I am writing data to the module (in data mode) as a series of chunks.

Each chunk consists of a 4 byte header and up to 1024 bytes of data.

If I write the chunks with no delay between them, I get corruption. If I insert a 50 mS delay between each chunk (still using the

same baud rate), then everything works OK but, of course, the throughput is poor. At no time does the module's RTS line change state.

Cheers,

Mark

Posted on October 07, 2015 at 13:19

Mark,

did you already take a look at hands-on pdf? Just to be sure that we are aligned.

There are some constraints in using socket server: buffer size, timeouts, and so on.

There is also a config variable to reduce default timeout value (250ms, huge, to allow customers to play with the module and hyperterminal).

Let me know if hands-on is not covering your current experience.

Ciao

j

markb
Associate II
Posted on October 07, 2015 at 13:29

Hi Gerry,

I have the hands on pdf for FW 3.3 and it does mention the socket server but I can't find any info on buffer size, timeouts, etc.

It does say look at the “Socket Server Application Notes� but I haven't found those yet. Please provide a URL for that document.

Please also provide a description of ip_sockd_timeout as UM1695 doesn't really tell you what it does (one can guess!!)

Thanks for all your help, I really appreciate.

Cheers,

Mark

Posted on October 07, 2015 at 13:53

In attach hands-on for FW3.4.

Let me explain ip_sockd_timeout variable, and socket server too.

There are some tips to help socket usage.

Concerning Buffer usage, it is sent out when

Timeout expires (none byte is received over UART for ''ip_sockd_timeout''milliseconds)

Buffer is full (Note that buffer is 1Kb in size)

Concerning timings:

Every byte is placed in the Buffer while no Timeout is found. When Timeout occurs, Buffer is sent to Client

Every Escape Sequence

must

be followed by a Timeout. If Escape is followed by further bytes, the whole “

Escape+bytes

�? sequence is sent to Client;

In order to free the buffer for next operation, a Timeout should go before every Escape Sequence. In this case, bytes before Escape Sequence are sent, the buffer is freed, and so the Escape Sequence is correctly received and understood. Otherwise, if the Escape Sequence is sent at the end of buffer, around 1Kb size limit threshold, the whole “

bytes+Escape

�? sequence is sent to client in 2 different packets.

Hope it helps

j

________________

Attachments :

wifi_Training_-_Hands_On_-_FW3.4.pdf : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I12v&d=%2Fa%2F0X0000000bmw%2FvQOrvIv_nJ33p_vKM9q87yGHhBVn4lHxTr79hl_nhIw&asPdf=false
markb
Associate II
Posted on October 07, 2015 at 14:51

Gerry,

Thanks for the updated hands on.

I have reduced ip_sockd_timeout down to 10mS and my comms protocol is much snappier!

However, I am still not seeing any RTS activity by the module and wonder if I am not actually filling the

module's buffer space enough to trigger the flow control. How much data can be sent to the UART before

the buffer fills and RTS goes high?

Is the flow control definitely enabled in data mode? I have no way of telling.

It remains a mystery why my data stream is getting corrupted but, right now, it's not critical to use the

higher baud rate so I can fall back to using a lower baud rate or use the 50 mS delay between chunks if

a solution isn't found.

Cheers,

Mark

Posted on October 07, 2015 at 19:38

How much data can be sent to the UART before the buffer fills and RTS goes high?

Since there is more than one buffer, and since buffers emptying depends also on protocol used (TCP/UDP) and network traffic, I cannot say what's the limit. What I can say for sure, is that RTS works fine, and data loss is avoided using flow control.

Is the flow control definitely enabled in data mode?

Yes. When config var is set, both CommandMode and DataMode are using flow control. RTS switches if/when needed.

It remains a mystery why my data stream is getting corrupted

Let me know if you find any module issue!

Thanks for all of your feedbacks! They will be used for sure!

j