STM32 UART/USART RX message terminator detection with LIN Mode

[mauro2399]

Posted on September 01, 2015 at 09:32

Hi everybody,

I am using several flavours of STM32: STM32F407, STM32F030, STM32F071, STM32F303 (soon).

Concerning UART, I want to set up a protocol using variable-length messages.

In order to minimize the CPU overhead, I want to use the TX with DMA and interrupt at the end of the transmitted message, and RX with DMA and interrupt at the end of the received message.

• On the TX side I can fire an IRQ with TXE or TC status bits, that's fine.
• On the RX side I want to fire an IRQ at the end of the received message. Since the protocol uses variable-length messages, how can the RX tell the received message has ended?

At first I thought I might exploit a scheme for few-char idle line detection:

• RTOF (RX timeout)
• CMF (Character match)
• I don't like using IDLE because it would fire and IRQ as soon as the TX leaves the line idle for just 1 char, no mercy for the TX being a little busy sometimes...

But I discovered that the USART of the STM32F407, which is the richest MCU of the ones I am using, doesn't implement RTOF and CMF. Sounds strange...

Anyway, I thought I could use the Break character as a message terminator.

According to the Reference manuals, on the RX side the Break character is treated as a Framing error. Uhm... I don't like using this as a message terminator, as there's no way to distinguish it from a real error.

But the LIN mode seems to handle it slightly different, requiring *all* received bits as 0 (mark). The Break character used in LIN Mode sounds like a viable message terminator, although STM32F030 doesn't implement the LIN Mode.

I have no experience with

LIN mode

, can you give me some advice?

Q1: On the TX side, is there any difference with UART mode @ 8-bit data length?

Q2: On the RX side, apart from the Break character handling, is there any difference with UART mode @ 8-bit data length?

Q3: Any other caveats or constraints with LIN mode?

Best regards,

Mauro

#stm32-uart-lin-break

Note: this post was migrated and contained many threaded conversations, some content may be missing.

[Nesrine M_O]

Posted on September 22, 2015 at 13:05

Hi Mauro,

Q1 & Q2: you are right there is no difference with UART mode @ 8-bit data length

Q3: no constraints with LIN mode apart of ones mentioned in specification 

I'd highly recommend to have a look to LIN (local interconnection network) mode paragraph in the USART section of any STM32 reference manual.

-Syrine –

[benyBoy]

Posted on May 08, 2017 at 18:00

Hi Mauro,

did you ever find a solution for end of message termination over uart? I have a similar problem and LIN mode doesn't appear to do anything, I was hoping it would start a new write to the buffer on being triggered but it doesn't appear to.

I tried initializing the handle with: 

HAL_LIN_Init(&UartHandle,UART_LINBREAKDETECTLENGTH_10B);

then calling;

HAL_UART_Receive_IT(&UartHandle,(uint8_t *)buffer,sizebuf);

but no luck or clue. I'm just using a simple bluetooth module and trying to tx commands of different leghths.

Even if I used same size command leghths , they arrive in the buffer as if in a circular buffer !!

my simple bluetooth module just works on any other micro I have used it with without trouble since the end of line is detected.

[mauro2399]

Posted on May 11, 2017 at 16:31

Ben,

I never had a chance to experiment with the msg termination over UART by using the Break in LIN mode.

I don't understand your case, though.

You mention you want to transmit commands to a Bluetooth module, but you call HAL_UART_Receive_IT (), which is what you call when you are receiving.

I don't understand what you mean with 'arrive in the buffer as if in a circular buffer'. Can you make an example?

My case with variable msg lengths and Break in LIN mode was a case for the Receiver side, but you appear to be dealing with a Transmitter.

I guess a Receiver would call HAL_UART_Receive_IT () and await for the ISR to call HAL_UART_RxCpltCallback() if no errors occurred, or HAL_UART_ErrorCallback() if any errors occurred, including the Break detection error, which should be treated as a Message Termination case.

Cheers,

Mauro

[howard n2wx]

Posted on May 08, 2017 at 22:37

I don't like using this as a message terminator, as there's no way to distinguish it from a real error.

This attitude is wise and prudent. Do you have enough bandwidth to accommodate a CRC?

[mauro2399]

Posted on May 18, 2017 at 15:19

Probably no, but I'll keep this as an option.