nRTS / nCTS behavior is NOT expectation

[ejlien]

Posted on August 09, 2017 at 03:49

Dear SIR,

Issue : nRTS / nCTS behavior is NOT expectation,

description:

while(1){} empty loop is running on MCU, data is not taken from USART->RDR.

The expectation is nRTS is set to high until the data is read from USART->RDR

but the real case is the nRTS is asserted(tied low) after 500ms.

Is there any missing?

Block diagream is as follows,

Set UART to hardware control flow mode on PC side and STM32F030C6T6 side both

    PC                 USB-Serial bridge

+--------+          +--------+ PC_TX     MCU_RX   +--------+

|        |          |        | -----------------> |        |

|        |          |        | PC_RX     MCU_TX   |        |

|        | USB I/F  |        | <----------------- |        |

|        |<-------->|        | PC_nRTS   MCU_nCTS |  MCU   |

|        |          |        | -----------------> |        |

|        |          |        | PC_nCTS   MCT_nRTS |        |

|        |          |        |<-----------------  |        |

+--------+          +--------+                    +--------+

Fig.1 Block diagram between PC and STM32F030CT6

   ---+ start +------------------------+------+------+ start +------------------------

RX    | bit   |        Data 1          | stop   idle | bit   |        

Data 2

      +-------+------------------------+             +-------+------------------------+

                                           +------+

nRTS                                       |      |

    ---------------------------------------+      +------------------------------

                                           ^      ^

                                           |      |

                      RXNE from low to high       Data 1 read,

                                                  Data 2 can now be transmitted

Fig.2

nRTS is de-asserted, indicating that the transmission is expected to stop at current frame.

USART setting

/* USART1 init function */

static void MX_USART1_UART_Init(void){

huart1.Instance = USART1;

huart1.Init.BaudRate = 115200; huart1.Init.WordLength = UART_WORDLENGTH_8B; huart1.Init.StopBits = UART_STOPBITS_1; huart1.Init.Parity = UART_PARITY_NONE; huart1.Init.Mode = UART_MODE_TX_RX; huart1.Init.HwFlowCtl = UART_HWCONTROL_RTS_CTS; huart1.Init.OverSampling = UART_OVERSAMPLING_16; huart1.Init.OneBitSampling = UART_ONE_BIT_SAMPLE_DISABLE; huart1.AdvancedInit.AdvFeatureInit = UART_ADVFEATURE_NO_INIT; if (HAL_UART_Init(&huart1) != HAL_OK) { _Error_Handler(__FILE__, __LINE__); }

}

Thanks and regards,

E-John

[Vangelis Fortounas]

Posted on August 09, 2017 at 07:57

Hello!!

Do you nean that after initialisation RTS kept High for  0.5 sec,  and after asserted? 

[ejlien]

Posted on August 10, 2017 at 04:05

Dear Vangelis,

Yes, the nRTS is kept high about 500ms, then goes low even data is NOT read from USART->RDR.

There is a bit in USART status register, RXNE, which indicates Read data register not empty,

There are two ways to clear this bit,

(1) read USART->RDR

(2) write bit '1' to USART->RQR

I don't do any read from USART->RDR, the RXNE not be clear and the nRTS(Control by STM32F030C6T6) should be kept high until the data is read out from USART->RDR.

But the real case is that the nRTS goes low after 500ms even data is NOT read out from USART->RDR.

Is there anything missing in my setting?

Thanks and regards,

E-John

[Danish1]

Posted on August 10, 2017 at 10:47

You haven't said very much about your development environment (e.g. if there is a debugger attached while you are doing your tests).

If you do have a debugger attached and the debugger is set to show you the state of the USART at a breakpoint then it is possible that the debugger is reading the USART periodically - even while the code is running. And anyone or anything reading the RDR will re-assert RTS.

Hope this helps,

Danish

[Vangelis Fortounas]

Posted on August 10, 2017 at 09:51

Hello again!

In your posted settings everyting is ok.

Problems are usually created by a combination of some or many factors, which in your case are unknown in the community to try to reproduce the problem.

RXNE  flag is normaly at LO state after initialization.

If something received, turns HI

>>'I don't do any read from USART->RDR'.  You do not,  but there are functions that could do this automaticaly, like HAL_ReceiveIT, HAL_ReceiveDMA if called before your loop.

Solutions.

Try to isolate the problem by remove any extra code irrelevant with

just initialisation

.

No interrupts , no call  HAL_ReceiveIT, no initialize other devices, no delays in your initialisation code, just initialise the UART and with the help of your debuger try to understand the exact sequence of caused problem.

Other solution is to post more code  to the comunity  like your  .IOC file and main.c file.

[ejlien]

Posted on August 16, 2017 at 08:41

Dear Danish,

Yes, It is correct, I didn't read the USART1->RDR, but I open the

View->System Viewer-> USART->USART 1 window

that update the USART1->RDR which make a read operation on USART1->RDR and it changes the RXNE to low.

thanks for your helps,

Test 1 and Test 2 are illustration for the impact of USART1 viewer window.

Thanks and regards,

E-John

Test1. View->System Viewer-> USART->USART 1 is NOT open in Keil debugger tool, USART1->RDR is not read in code.

Test 1 Result:

after sending a ASCII character on RealTerm application, the nRTS goes high which told PC it is NOT available to receive data because data is NOT read from USART1->RDR.

Test2. View->System Viewer-> USART->USART 1 is open in Keil debugger tool, USART1->RDR is not read in code.

Test 2 Result:

after sending a ASCII character on RealTerm application, the nRTS goes high then back to low because data is read from USART1->RDR by 

View->System Viewer-> USART->USART 1