2018-01-04 11:38 AM
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();}2018-01-04 11:52 AM
Make sure you recognize and clear framing or parity type errors.
I'd hazard it's not the initialization code.
2018-01-04 02:07 PM
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.
2018-01-05 06:15 AM
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 thehost is really still sending?
2018-01-05 10:24 AM
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.
2018-01-05 11:32 AM
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.
2018-01-05 01:18 PM
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.
2018-01-05 02:20 PM
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}
2018-01-06 01:47 AM
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...
2018-01-06 01:57 AM
Do yo mean cp2102 chips? I have never used them but read that fake cp2102 chips may output 4.4V instead of 3.3V: