Fake Idle Line Interrupt

[Yevpator]

Hello,

I​ use Idle Line interrupt as a timeout for UART Receive, to end up an ongoing receive process.

All in all, it works good for me, but I do have a constant issue on all the STM32, like L1, L4, H7, with a "fake interrupt upon reset". That means :

After reset I configure Rx and as result Rx pin raises from low to high and that triggers Idle line to count and that in turn means​ I will have a fake Idle line interrupt and a junk packet + Frame Error interrupt. I can filter out all the messages with FE and len=1 and I just implemented that, but I am uncertain how this solution is reliable. Do you see yet another solution on how to get rid of this 1st fake Idle line upon reset?

Thanks!

[Jack Peacock_2]

How do you currently handle receive errors like framing, parity, overrun?

Have you tried only enabling idle interrupt after the start of a message? Interrupt on first character received, clear idle irq, enable idle irq, and you have an end of frame when the message stops. If you get a receive error during the packet you can drop it when idle event occurs. Noise that triggers an invalid receive is dropped without enabling idle.

Jack Peacock

[Yevpator]

Dear Jack

Thank you for spending time to comment on my question.

I don't work this way/ I completely disabled a char-by-char receive on UART. I only have DMA. Framing error - if I encounter one of 4 errors - NE, FE, ORE and PE (this one is completely irrelevant as I don't work with parity)- then I ignore the entire message. This is actually the solution to the issue I mentioned in my post. My fake Idle Interrupt was always accompanied with the FE error, the rising low to high of the UART Rx was considered as a wrong frame, so filtering out the message in case of Frame error solves the issue.

Your solution sounds reliable , but implies adding new code and more code == more probability for a new bug (-: and also I don't like to use DMA with something else in addition, since all the concept of DMA is to release MCU from wasting time on things that DMA can do itslef. Think I have 8 UARTS at 921600 bps in parallel and some can work in stress . In addition to these UARTS I have may other tasks as well. Still your solution does not sound like something that will kill my program and I will definitely consider it.

Still don't understand why IDLE line was triggered from the last data receive if there was a pending FE... Maybe it was expected developer to filter that out?

[Bob S]

Wait - before you configure the UART, the RX line is low???? That means the TX line from whatever other device is talking to you is low and that shouldn't be. Unless the other device hasn't started up yet, or the serial lines are unplugged.

Next question - how does enabling the UART cause the RX line to go from low to high?

None the less, if you are sure the rising RX line (when you enable the UART) is what triggers the start of the idle timeout**(, what happens if you drive the RX pin high BEFORE you enable the UART? Actually, it should be "configure the RX line as an input with the pull-up enabled". That way, if there is nothing connected to the RX line when you start, the UART will see the RX line high as it is enabled. No rising edge, supposedly no idle interrupt.

** The L43x/44x reference manual does not explicitly mention whether an RX "idle frame" occurs only after receiving data, or if it happens ANY time the UART sees 10 consecutive "idle" bits on the RX pin. If it happens any time, then the above work-around won't help.

[Yevpator]

Dear Bob,

Thank you for your valuable comment.

Please look at the attached picture.

3 red and blue pulses are just a marker that I am going to init the UART.

Yellow is the UART Rx, it raised immediately after I called the init UART function. Reading your comment I thought maybe my conclusion that the Init UART RX called this low-to-high edge is wrong and actually the device that is connected to my Rx drove the pin high while I am initiating UART was just an occasion. Tried to check that and got contradicted results and then was compelled to postpone this investigation.

You can see on the picture, that there are 1 red and 1 blue pulses that are following the yellow edge. The blue pulse is my marker on the Idle Line interrupt (IDLE Line Interrupt is set) and red is my marker on the Frame Error (FE). The time between the yellow edge and the blue pulse is about 100us which is exactly 1 byte duration @ baud 115200 bps. This is the proof that Idle line is activated upon  "10 consecutive "idle" bits on the RX pin".

Even though looking at the FE helps me to filter out this fake Idle line, I think it is worth to take your advise , if that what you advised, and to wait on the Rx line until it becomes high. Will try that.

As for the Pullup, this is a nice idea. I supposed, without checking )-: that if we select a post as Alternate, we have no Pullup configuration, but it was a mistake. GPIO can be both alternate and PU.

Will check this a bit later.

Thank you once again for your help!

[Uwe Bonnes]

But GPIO pullup is only available after GPIO init. So iyou must set GPIO to pullup before uart init.

[Yevpator]

Yes, this is my intention. Thank you !​