2011-03-15 11:10 PM
How to stop the IDLE frame on UART
2011-05-17 05:28 AM
> 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.2011-05-17 05:28 AM
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 problem2011-05-17 05:28 AM
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.2011-05-17 05:28 AM
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...2011-05-17 05:28 AM
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.
2011-05-17 05:28 AM
The standard maxim for creating interoperable systems is,
''Be liberal in what you accept, and conservative in what you send''In practice, that means:
2011-05-17 05:28 AM
(ignore - stupid forum playing up again)
2011-05-17 05:28 AM
(ignore - stupid forum playing up again)
2011-05-17 05:28 AM
thanks, the problem is solved now by using your suggestions