I'm trying to continuously transmit the character 'L' from the microcontroller 8051 to the PC at a baud rate of 9600. The frequency of the 8051 is 16 MHz, and I accordingly loaded the BRL register with "0XFC" for baud rate generation. However, I can see a stream of garbage values on the hyper terminal; I even tried changing the auto reload values from 0xFB to 0xFF to no avail. Is there any way for me to generate the exact Baud Rate in the microcontroller or a way for me to fix this problem?

Edit: Also, even if I transmit just a single alphabet from the PC to the controller, and the code is written in a way for the controller to echo everything sent from the PC sometimes the character the controller sends in response is different from what I'd sent.

My code is as follows:

#include "reg_c51.h"

char uart_data='L';

void main (void) 
    SCON = 0x40;                     
    BDRCON &=0xE0;              
    BDRCON |=0x08;               
    IEN0 = 0xF0;                            
    BDRCON |=0x10;              

        SBUF = uart_data;
  • \$\begingroup\$ Which 8051 (manufacturer, part number) are you using, exactly? \$\endgroup\$
    – Dave Tweed
    Jul 24, 2014 at 13:37
  • \$\begingroup\$ I'm using the AT89C5131A-L. \$\endgroup\$ Jul 25, 2014 at 4:09
  • \$\begingroup\$ Might not be the issue here, but never underestimate the ability of plain old wiring to mess things up. In one lab I work in we have numerous 'serial cables' that are made from CAT5 patches clipped into DB9-to-RJ45 ends. I can get glitchy comms on these even at 9600, but replace with a 'real' serial cable and the same setup can run glitch free at 115200. Just sayin' \$\endgroup\$
    – JustJeff
    Jul 25, 2014 at 4:40

1 Answer 1


That's actually a subtle "gotcha" in asynchronous serial communications — if there are never any gaps in the data that are at least as long as a character time, it's possible for the receiver to get out of sync with respect to the byte boundaries, and there's no way to recover. Any '1' followed by a '0' could be construed as being a stop bit/start bit pair.

One possible fix would be to send a byte of all-zeros (or all-ones) every now and then. If the receiver is out of sync, this will force it to resynchronize on the next start bit.

  • \$\begingroup\$ But if that is the case then shouldn't it have worked properly when only one character was sent from the microcontroller? I wrote similar code for the controller to echo what was sent from the PC, and when I sent one character the controller sometimes transmitted a different character. \$\endgroup\$ Jul 24, 2014 at 12:19
  • \$\begingroup\$ You didn't say that. I can only respond to the information you put in your question, which was about continuous transmission. \$\endgroup\$
    – Dave Tweed
    Jul 24, 2014 at 13:33
  • \$\begingroup\$ This is where a scope would be useful. \$\endgroup\$
    – Spoon
    Jul 24, 2014 at 22:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.