• State Suggested Answer
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 73 subscribers
  • Views 4614 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 206611
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Couldn't use flow control on 52832

Alice

Hi,

I'm using nRF5 SDK v15.0 with S132 v6.0. I have two questions:

1. I use the ble_app_uart example. We want to use high UART baud rate, so I change it to 1M baud rate and  enable flow control(APP_UART_FLOW_CONTROL_DISABLED), it could work and output debug information on PCA10040 board. When I program it to our board, it could advertise, but it couldn't output debug information and the uart couldn't receive and send data any more. I use a USB to serial UART module(FT232RL) to connect our board and I have connect the RTS CTS TX RX GND conrecttly.

2.  I'm using ble_app_multilink_central on PCA10040 board. I add uart_init according to the ble_app_uart example, it could work and I could use print function to output debug information. But when I enable flow control(APP_UART_FLOW_CONTROL_DISABLED), the uart couldn't receive and send data any more.

Could anyone give me some advise? Thanks.

  • 0 in reply to Vidar Berg

    I have  enabled the HF crystal and  I also have tried 115200 baudrate, but I still get the 0x04 error. 

  • 0 in reply to Alice

    Have you tried 9600? Also, have you tried different PCs and terminal clients?  It sounds like the problem might be on the FT232RL/PC side. Think you need to use a scope to confirm that. 

  • 0 in reply to Vidar Berg

    Thank you for your help.

    I use our board to connect to the uart on the PCA10040 to work with flow control, it's OK now. Is there any USB to serial UART module that you could introduce to us? 

  • 0 in reply to Alice

    The FTDI chip is well known, and would not expect it to have this issue. Could it be that you have a counterfeit chip? Found this blog post which indicates that this might be a common problem: https://hackaday.com/2014/02/19/ft232rl-real-or-fake/  

  • 0

    I think that the flow control is incorrectly inverted in the hardware for use with an FTDI part connected to a PC. The complication starts with the meaning of "flow control", as there are at least two versions, the traditional modem CTS/RTS usage and the more modern CTS/RTS handshake. I added these comments to clarify this:

    /**@brief  Function for initializing the UART module.
 * Traditional Modem Flow Control
 * If flow control is enabled, a transmission will be automatically suspended when CTS is deactivated and
 * resumed when CTS is activated again.
 * A byte that is in transmission when CTS is deactivated will be fully transmitted before the transmission is
 * suspended.
 * nRF52 DTE Output pin to DCE - asserts to request transmit
 * nRF52 DTE Input pin from DCE - asserts to allow transmit
 *
 * Hardware Flow Control
 * "RTS/CTS handshaking" the DTE asserts RTS whenever it is ready to receive data from the DCE, and the DCE
 * asserts CTS whenever it is ready to receive data from the DTE. Unlike the original use of RTS and CTS with
 * half-duplex modems, these two signals operate independently from one another.
 * nRF52 DTE Output pin to DCE - asserts to allow DCE to transmit
 * nRF52 DTE Input pin from DCE - asserts to allow nRF52 DTE transmit
 */

    The nRF52 hardware supports the traditional modem usage, but the software is written for the more recent CTS/RTS handshake which requires an inverter for proper operation as the nRF52832 does not allow configuring active-high/low operation unless the lines are driven manually (the logic is inverted so does not work correctly)

Related
Terms of service