TM4C123GH6PM_UART_BAUDRATE_WITH_9600

supreeth anil said:

When I changed the baud rate to 9600, some weird characters started appearing on the screen.

Your code listing reveals your changed baud rate w/in TM4C - but you don't confirm that you made that same shift to 9600 at your PC.   Did you?   And did that change - if you made it - impact any other of your PC's serial settings?

From the looks of your screen-shot - it may be that the PC "sees" the MSbit as "set" - or that you've "moved" from ASCII to another serial data format.

Usually - but not always - slowing the baud rate "eases/corrects" serial port issues.   Your report "flips" that (usual) expectation upon its head...

supreeth anil said:

When I changed the baud rate to 9600, some weird characters started appearing on the screen. I tried with Hyperterminal and Putty  with same result. Even if I get the desired output, it changes after pressing the reset button on TIVA C LaunchPad.

The code configures the UART in the Tiva device and then enters a loop which transmits characters continuously as quickly as possible.

When the Tiva device is reset the UART Tx pin will be left as tri-state until the software initializes the UART. When the Tiva UART Txx pin is tri-state, the receiving UART may not see a valid input which means when the Tiva starts transmitting means the receiver may correctly synchronize to the start bit.

Try one of the following to see if that allows the correct characters to be received by the PC:

1) Attach an external pull-up resistor to the Tiva UART Tx pin.

2) Change the software in the Tiva to insert a delay, say at least two character times, between initializing the UART and starting to transmit.

Either of these changes should hopefully allow the UART receiver to see the Tiva Tx as idle before the transmission of characters starts.

Great. This is a perfect answer. I put some delay between initialize and start of transmit to solve the problem. I have the following doubts regarding the problem

1) After reset the device remains in tri-state until the software initializes the UART. But it is clear from the screenshot that the device continue to send weird characters even after the initialization of UART. Once it is initialized, it should be able to provide proper states (idle, start, stop etc.) to the PC. What is the logic behind this?

2) How did you calculate the delay time as two characters or more in this example?

Thanks in advance

supreeth anil said:

Once it is initialized, it should be able to provide proper states (idle, start, stop etc.) to the PC. What is the logic behind this?

The program generates a continuous stream of characters on the UART, such that there is no "idle" time between the stop bit of one character and the start bit of the next character. The receiver looks for a 1 -> 0 edge for a start bit and if then sees a stop bit that the receiver thinks it has received a valid character. With a continuous stream of fixed characters then if the receiver has detected a start bit on what actually a data bit, then the receiver may remain incorrectly synchronized.

To demonstrate this, I put your code in a launchpad and used a LSA to capture the UART transmission. The launchpad was left continuously outputting characters and a capture started on the LSA. The LSA was set to decode the UART stream with 9600 baud, 8 data bits, no parity and one stop bit:

On some captures the LSA decoded the expected character sequence:

On other captures the LSA decoded an unexpected character sequence, without detecting any error, since remained incorrectly synchronized:

Another variation was a stop bit error, invalid character but then synchronized to the expected sequence of characters:

supreeth anil said:

How did you calculate the delay time as two characters or more in this example?

If the receiver has incorrectly synchronized to a start bit, then a maximum of one character time later the receiver should be looking for the next start bit. A two or more character delay should then give sufficient time for the receiver to have seen the data as idle before the start of the real data.

Thank you so much for a detailed explanation like this. All my doubts got cleared.

supreeth anil said:

It is working fine with 115200 baud rate (115200, 8bits, no parity, no flow control, 1 stop bit). When I changed the baud rate to 9600, some weird characters started

Agreed that poster Chester's response was most excellent.

That said - as "Working fine @ 115K" was earlier reported - wouldn't that (much) higher baud rate have (magnified - not "cured") this issue?

That's unexplained - and casts doubt (primarily) upon the earlier, "Working fine" comment...

It is still working fine with 115200 baud rate (115200, 8bits, no parity, no flow control, 1 stop bit). May be we can make use of the RS-232 decoder suggested by Chester for this baud rate.

Hello Supreeth,

Did you try switching from PuTTy to TeraTerm? Also do make sure that when using 9600bps, the windows device manager is also configured for 9600 bps.

Regards
Amit