2015-12-14 01:41 AM
Hi,
We are using an ARM STM32L100RC. We receive in our firmware a message of just two characters through the USART 1. At 9600 kbps it works ok, at 19200 it fails sometimes, but at 38400 it fails one in ten times (approximately). We receive the interrupt for the first character and we read it Then we receive the interrupt for the second character and we read it. But sometimes at 38400 we don't get the interrupt for the second character. We use the typical uint32_t USART_INT_ST;USART_INT_ST = USART1->SR;
if(USART_INT_ST & UART_FLAG_RXNE) /* Character received */ { datorx = recibe232(); tbl_prgserierx[protocolo_actual](); } else if(USART_INT_ST & UART_FLAG_TC) { if (nbuf_tx) tbl_prgserietx[protocolo_actual](); } to know if we have received a character and to send a character. We make this in USART1_IRQHandler. After that we: //Clear Tx interrupt if ( __HAL_UART_GET_IT_SOURCE(&huart1, UART_IT_TC) ) __HAL_UART_CLEAR_FLAG(&huart1, UART_FLAG_TC);//Clear Rx interrupt
if ( __HAL_UART_GET_IT_SOURCE(&huart1, UART_IT_RXNE) ) __HAL_UART_CLEAR_FLAG(&huart1, UART_FLAG_RXNE);There are 8 HAL_NVIC_SetPriority( IRQn, 0, 0) in our source code. All of them are 0, 0. I have re-writed the source code to try with all of them at 15, 15 except HAL_NVIC_SetPriority(USART1_IRQn, 0, 0). But it is the same, the USART1_IRQHandler doesn't get any interrupt for the second character received from time to time.
I am analyzing the signals that the microcontroller receives and they are the same when it goes ok or wrong. I analyze the transition between the stop of the first character and the start of the second character and they are equal too.
I check with the software emulator that the diferent bits of the registers SR, CR1, CR2, CR3 remain with the values that they have to be. Comparing the ok and the wrong situation but they don't differ.
I try configuring 8 or 16 oversampling, ONEBIT equal to 0 or 1 but is the same.
What can be wrong? What can we try to get always the interrupt for the second character?
Thank you.
2015-12-14 03:33 AM
I would, as a test, enable all error interrupts (overrun, noise, frame, parity error), and check with a debugger if any of those errors occured. I'm no Cube user, though, so I can't give example code recommendations.
In case of overrun, your reception interrupt routine probably takes too long. In the other cases, there might be a line issue.2015-12-14 05:14 AM
Be careful with the debugger, if you view the USART registers you will alter them. If it reads the USART->DR it will clear the RXNE flag. The debugger is invasive so instrument the code so you can see what's going on.
Check for error flags. In handlers that do a lot of work (call other functions, etc), perhaps you want to loop in the IRQ until all TXE/RXNE are cleared. Also get rid of the if/then/else scheme, more than one bit can assert at a time, check them individually.2015-12-15 07:49 AM
Yes, there was an Overrun error. But that was with the old board we used.
Now, with the new board we are using, the problem has disappeared fortunately. Thank you anyway.2015-12-15 08:14 AM
I mean, we are using the new board since today.
And with this board we receive the two characters always ok. Thank you.