UART Receiver glitches
I once fell into the same trap myself.

Remember, the "A" in "UART" means "asynchronous"! You need to treat the Rx signal as an asynchronous input, and synchronize it to your internal clock by running it through a pair of flip-flops before you do anything else with it.

Note that in your code (specifically, if counter = 0 and Rx = '0' then), the Rx input affects multiple flip-flops (counter) in parallel. You can think of the four flip-flops that hold the count value as being driven by a multiplexer that selects either (others =&gt; '0') or counter + 1 to be loaded into them. The Rx signal feeds the logic that drives this multiplexer. If it is asynchronous, it could be changing just as the clock edge arrives. If this happens, some of the flip-flops will get bits from  one value, and some of them will get bits from the other. The result will be a completely random state.

But also, as David Koontz points out, you really need to oversample Rx in the state machine so that you can ensure that the bits you're shifting into your shift register are NOT sampled close to the transitions. 4&times; oversampling should be considered a minimum, and the de-facto industry standard is to oversample at 16&times;, with optional "voting" among multiple samples near the center of each bit for extra noise immunity.

Here are some timing diagrams to help illustrate the issue that oversampling solves. In each case, the vertical line of '*' represents the point at which the state machine recognizes the incoming start bit, and the subsequent vertical lines of '|' represent when the bits are sampled. The Rx signal can arrive early or late with respect to the clock, so both extremes are shown.

With a 1&times; clock, at either extreme, the data bits might be sampled very close to where they might be changing. If the transmit clock phase drifts a bit with respect to the receive clock, bit errors will occur.

                  ______       *______       |______       |______
  1x clock ______/      \______/      \______/      \______/      \______
           _______             * ____________| ____________| _____________
  Rx (early)      \____________*X_____________X_____________X_____________
                      start    *    data     |    data     |    data
           ___________________ *             |____________ |____________ 
  Rx (late)                   \*____________X_____________X_____________X
                               *    start    |    data     |    data


With a 2&times; clock, the problem with the "late" extreme has been eliminated, but the problem with the "early" extreme remains. There's still a possibility of bit errors.

                  ___    *___    |___     ___    |___     ___    |___    
  2x clock ______/   \___/   \___/   \___/   \___/   \___/   \___/   \___
           _______       *       | ______________| ______________| _______
  Rx (early)      \______*_______|X______________|X______________|X_______
                      start      |    data       |    data       |    data
           _____________ *       |       ________|______ ________|______ _
  Rx (late)             \*_______|______X________|______X________|______X_
                         *  start|          data |          data |


The 4&times; clock completely eliminates the problem for both timing extremes. The bits will be sampled somewhere between 50% and 75% of the bit period.

                  __   *__    __   |__    __    __    __   |__    __    __   
  4x clock ______/  \__/  \__/  \__/  \__/  \__/  \__/  \__/  \__/  \__/  
           _______     *           |       ________________|___ __________
  Rx (early)      \____*___________|______X________________|___X__________
                      start        |          data         |       data
           ___________ *           |           ____________|__________ ___
  Rx (late)           \*___________|__________X____________|__________X___
                       *  start    |              data     |