How to stop the IDLE frame on UART

[himanshu]

Posted on March 16, 2011 at 07:10

How to stop the IDLE frame on UART

[ColdWeather]

Posted on May 17, 2011 at 14:28

> Is there any method to stop the IDLE frame when TE bit is enabled.

According to RM0008 Rev 1.2, Page 767, any set of TE results in the idle frame. As long as the idle frame is in progress, TXE bit is cleared, so the data register cannot be written to (or writing should not have an effect). I cannot imagine yet what is your intention to interrupt the idel frame. This frame seems to be neccessary to initialize the UART and to generate a definite condition on the TX line. You can count it to the general CPU initialisation phase, that you must do to start the whole firmware properly. If you really need to shorten the idle frame time to accelerate the initialisation after reset, I would suggest a trick: program the UART to the highest possible baud rate then enable TE, wait until TXE is set and finally set the desired baud rate and don't ''play''any more with TE bit during UART transmissions later.

[himanshu]

Posted on May 17, 2011 at 14:28

Thanks for reply,

But the problem acutaly is that on power on when we intailise UART the FF is send by micro on this UART due to which the device that is connected on this UART misbehave, to solve this i want to know can we supress this IDLE character. i hope u can now underatand my problem

[ColdWeather]

Posted on May 17, 2011 at 14:28

IDLE frame is nothing else but the high state of the TX pin kept for at least frame length. NO start bit is sent!

Your problem is, on power on the TX pin seems to go electrically low because of power up transitions yet before the controller starts and initializes its peripherals while your receiver goes ready faster than the controller and reads the TX line transition as the start bit: the reset state of the GPIOs is high impedance, and if your receiver loads the TX line, it looks for it like a low level for a while until the TX line goes strongly high after the initialization completed. The receiver sees 0xFF! Set a pull-up resistor of about 1K on the TX line in your design.

[Andrew Neil]

Posted on May 17, 2011 at 14:28

It is common for startup glitches to cause the odd spurious character at startup.

Try powering-up (or even rebooting) various devices while connected to hyperterminal... This is not a peculiar issue to the STM32. Your receiver should be designed to cope with this...

[Tesla DeLorean]

Posted on May 17, 2011 at 14:28

Just a thought, delay the configuration of the USART TX pin to GPIO_Mode_AF_PP until you are ready. Try experimenting with configuring/driving it as a GPIO in a High or Low state during initialization.

[Andrew Neil]

Posted on May 17, 2011 at 14:28

The standard maxim for creating interoperable systems is,

''Be liberal in what you accept, and conservative in what you send'' In practice, that means:

• Your receiver should be designed to cope with spurious characters at startup;
• Your transmitter should strive not to cause spurious conditions at startup.

[Andrew Neil]

Posted on May 17, 2011 at 14:28

(ignore - stupid forum playing up again)

[Andrew Neil]

Posted on May 17, 2011 at 14:28

(ignore - stupid forum playing up again)

[himanshu]

Posted on May 17, 2011 at 14:28

thanks, the problem is solved now by using your suggestions