I have an Atmel SAM D20J18 uC. I'm trying to print something via USART. The first few symbols are ok, but after 8-9th symbol there is garbage. However, if I run the code line-by-line in debug mode (with SAM ICE JTAG), all the symbols are printed correctly. I'm sure that I have correct serial settings in both uC and the terminal program (I use Putty). I use USB-to-TTL as serial device. What else could cause the problem? (link to the source code: main.c)

enter image description here


See my own answer below

  • 2
    \$\begingroup\$ You have a speed mismatch. The baud rate is close, but not close enough, probably because of the limitations of integer clock dividers at high speeds. What is the baud rate you're trying to use? Does it work at a lower rate? \$\endgroup\$
    – Dave Tweed
    Oct 4, 2015 at 12:20
  • \$\begingroup\$ Are the number of correct and 'broken' characters written into PuTTY always the same every time? Have you changed the baud rates? Is it the same effect? Have you a way to capture the set of 'broken' characters, and save them? What does usart_write_wait do? Does it wait, and for how long? Have you tried inserting a delay (say 0.5 seconds) after every write? If so does that change the result? \$\endgroup\$
    – gbulmer
    Oct 4, 2015 at 12:22
  • \$\begingroup\$ The amount of correct symbols vary from time to time. The baudrate is 9600, if I choose lower or higher, it won't work at all. I don't really know what usart_write_wait() do — I see this uC for the first time and was told to learn it a little :-) The same problem with garbage if I use printf() instean of usart_write_wait(). I haven't tried to insert a delay between the symbol printings. Unfortunately, I'll be able to check it only tomorrow. Thanks for the answers. \$\endgroup\$
    – c_spk
    Oct 4, 2015 at 12:49

2 Answers 2


There are two distinct possibilities here.

  1. You have the baud rate close but off by some percentage in the 3-5% range. If you are sending in a way to keep the UART pipe full there may not be an opportunity for the receiver end to re-sync its clocking to the center of the start bit and this lead to picking up garbage as the UART ends go out of sync with respect to each other.

  2. You are sending too fast as the transmitter end. Most UARTS has a transmit buffering of one byte. Sounds like yours has a FIFO that can store up to the first 7 or 8 write bytes. After that, if your sending routine does not wait properly for next FIFO slot to be available the the last one is likely overwritten by the wrong data.

In either case the fact that you single step a single character at a time and see it function OK confirms it is one of the above two cases because the delay allows the either the receiver to re-sync or the FIFO to empty at the transmitter.


Checked it today again and got no output at all though I hadn't changed anything in the code. But later I found the problem — it was poor soldering. Now as it's resoldered it works as it should without any garbage. Thanks for the answers.


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.