USart not receiving data after awhile

[Vu.Andy]

Posted on January 04, 2018 at 20:38

I am using STM32F051 device.  For some reason, after the host sending data for awhile, Rx stops receiving data.

If I use the debugger and stop the code, and try to send something back to the host, then the Rx begins receiving again.

So I am not sure why sending some data back to the host allows the Rx to receive data again.

Is there a flag I can check to see if there is any error? 

Here are the codes to initialize UART.

void MX_USART1_UART_Init(void)

{  huart1.Instance = USART1;  huart1.Init.BaudRate = 9600;  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_NONE;  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__);  }        UsartBuff[0] = 0;    UsartBuff[1] = 0;    L_UsartDataIdx = 0;        InitUsartReceiveIT();}

[Tesla DeLorean]

Posted on January 04, 2018 at 20:52

Make sure you recognize and clear framing or parity type errors.

I'd hazard it's not the initialization code.

[Bogdan Golab]

Posted on January 04, 2018 at 23:07

I would verify if the host is really sending the data (any logic analyser connected to the uart to sniff the traffic?). Maybe the host was unblocked by the traffic send back (we do not know the code of neither host nor STM32).

It seems that you handle the the received data through the IT. How much time you spend there after receiving the IT?. You may test the code without IT (waiting for the data in a loop).

Anyway I would try to simplify the code on both sides  (PC and STM32) to narrow down the problem and eliminate the problems mentioned by Clive One.

[Andrew Neil]

Posted on January 05, 2018 at 14:15

Clive One wrote:

I'd hazard it's not the initialization code.

Indeed.

The fact that it starts working suggests that the initialisation is OK - something is going wrong after initialisation.

As

Golab.Piotr

‌ said, are you sure that the

host is really still sending?

[Tesla DeLorean]

Posted on January 05, 2018 at 18:24

I've had Prolific serial drivers go brain dead, but that's been a few years ago.

When I have serial issues that don't make sense the scope is out pretty quickly to sanity check the situation so I don't spend hours looking in the wrong place.

[Bogdan Golab]

Posted on January 05, 2018 at 19:32

Some prolific drivers have problems on w7/w8 machine. I often use xp virtual machine to run a terminal because xp drivers are stable and free of this issue. Prolific says that the problem is either fake chip or an old chip. The drivers stops working when the traffic is bursty (I cannot receive data on the terminal). I do not see this issue on xp using the save chip revision.

[Tesla DeLorean]

Posted on January 05, 2018 at 21:18

I pretty much use SiLabs parts now universally. Prolific and FTDI have had very bad drivers, and FTDI's behaviour destroying consumer boards is unforgivable. The end user has very little control over whether a vendor ships fake parts, and the only way to be sure about FTDI parts is not to use FTDI parts.

[T J]

Posted on January 05, 2018 at 23:20

if you don't clear the Rx data register fast enough, then the interrupts will stop.

I use a while loop to clear the double buffered Rx data register.

while (rxne)

   { take data}

[Bogdan Golab]

Posted on January 06, 2018 at 09:47

Yes, exactly. I still keep old FTDI drivers - those which do not detect fake chips. Prolific at least only report meaningless error when the chip is fake...

[Bogdan Golab]

Posted on January 06, 2018 at 09:57

Do yo mean cp2102 chips? I have never used them but read that fake cp2102 chips may output 4.4V instead of 3.3V:

https://wiki.kewl.org/dokuwiki/interfaces:cp2102