2017-10-12 01:04 AM
Hi,
trying to transmit data via USART1 of STM32L476 Nucleo evaluation board. Use PA9 for TxD.Character count is 254*2+14 = 522 or 255*2+14 = 524.
522 always is ok, 524 gives errors at receiver site.Data switches between 'all 0x00' and 'all 0xFF' every cycle.Use HAL_UART_Transmit (...) for sending data.
Receiver always flags Error on 0xFF packets.Took measurement on TxD with oscilloscope. That shows that with 'all 0xFF' always 8 characters are not sent!!! (s. attachement). What may be the cause of this?P.S.
By the way: Took a look into HAL_UART_Transmit () source code. Found that writing TDR does not check TXE flag first (but that is not the cause of the 8 byte error).2017-10-12 04:54 AM
What baudrate? Isn't the timeout too short?
JW
2017-10-12 05:03 AM
Oh yes, you're absolutely right.
10 msec timeout is too short (although we are using 500 kbit/sec).What about TXE bit checking before writing TDR in HAL_UART_Transmit () ?Thank you for support!2017-10-12 07:25 AM
Oh yes, you're absolutely right.
we are using 500 kbit/sec
Was I? Now I'm confused. I was under the impression that the timeout is per character. The ehm 'documentation' does not tell much.
What about TXE bit checking
I don't know. I don't and won't Cube.
JW
2017-10-12 07:38 AM
Looked again at 'HAL_UART_Transmit ()' source code...
TXE checking IS done (prior to TDR writing by call to 'WaitOnFlag...(UART_FLAG_TXE)...' ). So at first sight timeout parameter seems to be a 'by char' timeout.But: Before entering the loop ('TxFerCount--'...) a ticker value ('HAL_GetTick()' is fetched.
And further on the timeout is checked every char against this initial HAL_GetTick().So timeout parameter becomes a frame timeout...
And: My frame with 524 chars has 10.06 msecs...2017-10-12 07:46 AM
Thanks for the explanation.
Jan