Low level details for serial communication between UART of a microcontroller and PC
A lot of this is about software, not hardware. I'll provide a simple overview, that doesn't get too far afield. (My background is having read almost 1000 pages of the USB 2.0 specification and having used many such USB connected devices. I also have some background with Windows drivers.)


  I will really appreciate if someone can enlighten my how internally
  data flows from micro to PC and vice verse using single Rx and Tx
  pins. I really want to understand how it actually work at hardware
  level. (I am not looking for a sample code though)


There is a process for a USB device to enumerate itself via USB. For the Windows operating system, the process can be found here: How does USB stack enumerate a device?. That web page will give you a good overview of the enumeration process followed by Windows and some of the reasons why that process is followed. So I won't try and duplicate what has already been done far better than I could have written, here. Read that page and get an overview of that process.

Without getting into a lot of details, a USB device can have multiple endpoints and they can be of several types. The host operating system doesn't really care. It just goes through a process of enumerating them so that they can act according to their descriptions. So you may have a composite USB device that enumerates as both HID and MSD, for example.

For many demo boards, there is a separate IC (or several) related to providing the interface into the USB host operating system. For example, if you buy a TI MSP430 demo board, with a socket for a variety of MSP430 DIP devices, there will also be a separate USB section on the board, too. This section includes a special MCU (you can see it, so just look) that handles all of the USB enumeration details that you are NOT told about when you hook it up to the USB host computer.

One endpoint that this preloaded MCU enumerates will be used for debugging the MSP430 DIP chip you can add to the board. You won't get much information about this USB endpoint or the commands and queries that it handles. That's because TI doesn't document the debugging interface (publicly.) So this USB endpoint communications will be handled by a driver arranged on the USB host side, plus software preloaded onto that special MCU on the demo board side. This debugging endpoint allows special software and debugging protocols, almost always undocumented, to use the debugging portions of the JTAG interface (or similar) that resides on your DIP MCU in the demo board. So debugging software gets its job done by using this particular "back channel" USB endpoint. You will NEVER get much info on this particular endpoint without first proving you have a need to know and then also signing your life away. (Sometimes, you can get information about how to download code into a device. So you get information on part of this interface, at times. Also, ARM CPU JTAG debugging, by contrast, is documented. However, custom peripherals added by manufacturers to the ARM CPU may not be documented well.)

However, this special MCU also handles another endpoint for you. This will be a virtual COM port (HID) endpoint. So the host OS sets up a virtual COM port driver designed to present a "standard" COM port interface that can be used by software running on the USB host computer (PC) side. Any software you write on that PC computer will "talk" to this driver as if it were a "real" COM port. It's not. It's just software. There is NO hardware associated with this virtualized COM port on the host PC. It's a "virtual" COM port, after all. All that happens is that stuff you do with this virtual COM port get's turned into USB endpoint communications (in and out.) Similarly, what your PC software does in configuring that port also gets passed along to the demo board's USB-handling special MCU via this virtual COM port endpoint link in little packets that tell it what the PC software is asking to have done. Some of this just gets swallowed up by the special MCU and is stored internally so that it knows what's expected, later. For data, to be exchanged over the TX and RX pins, the special MCU then acts as if it were an external serial device hooked up to your DIP MCU's TX and RX pins. (The special MCU works its own pins to drive and receive from your DIP MCU pins.) This information is turned into USB packets, though, for exchanges between the host PC and this special MCU handling the USB interface to the PC.

So, as far as your newly programmed DIP MCU can tell, it is in fact talking to a serial device via TX and RX. It does so without all the usual RS-232 voltage requirements, using instead the local \$V_\text{CC}\$ power supplies present on the board. But your software doesn't care. So long as the TX and RX pins "appear" to be talking to something which handles things correctly, all is well and your software "just works" like it is supposed to work.



NOTE

The use of bit rates (often incorrectly called "baud" here) configured on the PC side software using the usual configuration software calls have NO AFFECT AT ALL on the USB endpoint communications. USB works by a completely different set of communication mechanisms. So the host PC and your demo board's special MCU communicate via USB and the bit-rate configurations are passed along regardless. It is then the job of the special MCU on the demo board to "configure" itself so that it uses the right timing details to act as if that bit rate was selected. But subsequent data transmitted from the host PC software towards the demo board ALWAYS arrives perfectly well and intact, regardless of the set bit rate for the serial communications. By this, I mean it always arrives to the special MCU just fine. However, the special MCU now has to bit-bang the pins at a certain rate to your DIP MCU, which it does. If the rates aren't matched correctly, this has the same problems you'd normally expect. But these problems only occur between the special MCU and your MCU, but not between the host PC and the demo board's special MCU.