Cannot get USART timeout counter to count

[Krenek.Steve]

Hi,

I'm receiving characters in polling mode on USART2 in an STM32L476VG.

The USART is set up and enabled. I have the following in my receive character routine:

// Get a character from the Aquaflex port
// timeout with return = 0
int8_t AquaGetChar() {
	int8_t chr;
	uint32_t timeoutFlag = 0;
	uint32_t receivedCharFlag = 0;
 
	// Set the receiver timeout value to 1 sec (10,000 bit periods)
	LL_USART_SetRxTimeout(USART2, 10000);
 
	// Enable the receiver timeout
	LL_USART_EnableRxTimeout(USART2);
	
	// clear the receiver timeout flag if it's set for some reason
	LL_USART_ClearFlag_RTO(USART2);
 
 	while (!receivedCharFlag) {
		receivedCharFlag = LL_USART_IsActiveFlag_RXNE(USART2);
		timeoutFlag = LL_USART_IsActiveFlag_RTO(USART2);
		if (timeoutFlag) {   // no char received - set the return value to 0;
			chr = 0;
			break;
		}
	}
 
	//  if the timeout flag is not set then we must have got a char in the buffer
 	if (!timeoutFlag) {
 		chr = LL_USART_ReceiveData8(USART2);
 	}
 
	// disable the receiver timeout or we will get one very shortly (when no more chars coming in)
	LL_USART_DisableRxTimeout(USART2);
	LL_USART_ClearFlag_RTO(USART2);
 
	return chr;
}

The code will remain in the while loop indefinitely until a character comes in, ie the timeout feature does not seem to be working.

Checking the SFRs, the RTOEN bit in CR2 is set

The counter register RTOR is correctly set to 10,000 (0x2710)

However, the counter value remains fixed a 0x2710 and will not count down.

I do not have the interrupt enable flag set but the Ref manual for the chip does not indicate this is necessary.

The USART receives and transmits character fine - it just doesn't timeout.

Is there some other thing I need to enable to get the counter to count down? Clock of some sort?

Many thanks,

Steve Krenek

[Krenek.Steve · Accepted solution]

Solved by myself. I have in fact asked the wrong question. The problem is that the timeout does not count down if the idle time since the last received char is greater than the timeout period. That is, if a character is first successfully received, and then a gap of longer than the timeout period occurs, the timeout flag will trigger. 

However, it will not trigger again after a further timeout period. It needs a character to be received before is gets armed again. It therefore cannot pick the situation where no characters are received when they are expected.

I will make this the subject of another question.