Need to ignore the unwanted start bit during the stop mode.

[prudhvichitturi]

I am working on STM32L051R8, which is set to use Stop mode, which wakes up on the start bit.

I have a situation where the MCU wakes up on an unwanted start bit, and UART extracts unwanted data. The expected action is to ignore the unwanted data and enable it to wake up again when it is supposed to.

I have tried to use 

      SET_BIT( huart1.Instance->CR1, USART_CR1_RE );

      CLEAR_BIT( huart->Instance->CR1, USART_CR1_RE );

which kind of worked but when using below

    CLEAR_BIT( huart->Instance->CR1, USART_CR1_RE ); the current consumption increased.

[prudhvichitturi]

yes, it is ignored but the data of the wanted was partially taken too which causing problem , so the logic i have device wakes up early than expected then ignore the data by the above code and listen to start bit again .

[Andrew Neil]

---

@prudhvichitturi wrote:

yes, it is ignored but the data of the wanted was partially taken too which causing problem 

---

I don't understand what you mean by that - please explain further.

A diagram may help ...

There are notes in the RM about ensuring that the UART will catch a whole frame...

[TDK]

If the waveform on the UART_RX is some junk immediately followed by a valid character, there is no way to know where the junk stops and the character starts. Showing the waveform would help here. The chip has no way of knowing what you consider bad and good. It just reads what's on the line and reacts accordingly.

If the UART_RX line is getting glitches, it should be fixed by keeping the pin high when idle, using a pullup and ensuring the slave only pulls the line down when it's sending characters.

[prudhvichitturi]

The red arrow is where the MCU should wake up on the start bit from stop mode. The red block is where the Rx should ignore the received data, but the yellow arrow is the data received, which is not expected.

[prudhvichitturi]

while keeping the UART_RX high, can we enable stop mode? if so how do we do that in FW?

[TDK]

You don't control the UART_RX pin. It's an input.

Looks like two things are trying to control it at once, which is why the low level is not at 0 but at about 1/3 of the full range. There's a fundamental hardware/design issue here.

> but the yellow arrow is the data received, which is not expected.

It's data on the line. Why are you saying it's unexpected? Ignore it after you receive it if you're not interested in the byte. Or change the behavior of whatever device is sending the data if you can.

[prudhvichitturi]

It is ignored ./ got PE but the designed /architecture makes next frame missed .

as mentioned the goal CLEAR_BIT( huart1.Instance->CR1, USART_CR1_RE ); works when it is not needed.

but by using  CLEAR_BIT( huart1.Instance->CR1, USART_CR1_RE ); the current consumption increases.