"How can the host know lost events if the loop couldn't get them?"

I don't think you need to worry about losing events in the USB connection, especially when using the BLED112 in peripheral mode. The rate of events is relatively small. I have worked with the BLED112 quite a lot and never had an issue with lost events.

There is a complete example available in this article:
https://www.silabs.com/community/wireless/bluetooth/knowledge-base.entry.html/2017/01/13/using_bled112_todo-tE0Z

It implements an OTA firmware update client using the BLED112 dongle. It is a central application, but same kind of structure can be used for  peripheral mode, too.

Main difference between central / peripheral type of app in the startup phase:

• central: start scanning and wait for scan response events
• peripheral: start advertising and wait for connection opened event

Notice the analogy? You start by sending a command to the dongle and then wait for events produced by the dongle in a loop.

The way the application pumps events and command responses out from the dongle and sends commands to the dongle is the same, regardless of peripheral or central mode.

This is the main loop from the example that I referenced:

The main loop itself is very compact and it does nothing else but pumps out events or command responses from the dongle. All the rest of the code is implemented in the command or response handler functions that are called from read_message(), based on what type of event or response was received.

I suggest that you first try to implement a soft timer with the dongle. Before entering main loop, send a command to start soft timer with e.g. 1 second interval. Then you should receive a timer event from the dongle every 1 seconds. This is an easy way to test if your code can communicate with the dongle, kind of a "blinky" application for the BLED112.

There is a complete example available in this article:
https://www.silabs.com/community/wireless/bluetooth/knowledge-base.entry.html/2017/01/13/using_bled112_todo-tE0Z

It implements an OTA firmware update client using the BLED112 dongle. It is a central application, but same kind of structure can be used for  peripheral mode, too.

Main difference between central / peripheral type of app in the startup phase:

• central: start scanning and wait for scan response events
• peripheral: start advertising and wait for connection opened event

The way the application pumps events and command responses out from the dongle and sends commands to the dongle is the same, regardless of peripheral or central mode.

This is the main loop from the example that I referenced:

The main loop itself is very compact and it does nothing else but pumps out events or command responses from the dongle. All the rest of the code is implemented in the command or response handler functions that are called from read_message(), based on what type of event or response was received.

I suggest that you first try to implement a soft timer with the dongle. Before entering main loop, send a command to start soft timer with e.g. 1 second interval. Then you should receive a timer event from the dongle every 1 seconds. This is an easy way to test if your code can communicate with the dongle, kind of a "blinky" application for the BLED112.

I want to know how can it see the connection coming from a central device. Is it by the callback, or the polling?

Your application that talks to the BLED112 is supposed to poll the dongle for events all the time in a continuous loop. 

In peripheral mode, you first need to start advertising by sending command gap_set_mode like Marcin said. Then your polling loop will read any events from the dongle. When a client connects to the dongle you will receive one or more events. The events will tell you which is the address of the connected device etc. Later if the client disconnects there will again be an event for this.

Have you tried the BLE GUI tool that comes with the SDK? It is a very handy tool for learning the basics. You can use it to put the dongle into advertisement mode. Then if you connect to the dongle using your phone you can see the events printed in the GUI. 

I don't think there is any event that would indicate directly that the connection has been opened and established.

I suggest that you track all the stack events that are raised after a connection is opened. There should be at least one event to indicate that the connection parameters have been negotiated between master and slave. If you trigger your own code to this event then it should be safe to assume that the connection is already established.

Another event that is often (but not always!) raised is the one that indicates that MTU has been exchanged. The pitfall here is that if you happen to use the default MTU 23 that is the default for all newly opened connections, then the stack does not produce the MTU exchanged event (because MTU is not changed).

Thanks for bringing this out to our attention, I will report this issue to Silabs IT team and see if they could get it fixed. 

Thanks again! 

I don't see why you would need multiple steps to reproduce this issue. The first screenshot I attached should be quite self-explanatory. 

If I enter the "latest" URL to my browser manually, it shows the documentation of 2.13 (which is NOT latest).

Another way to reproduce: I go to docs.silabs.com and click Bluetooth => it points me to https://docs.silabs.com/bluetooth/latest which looks same as the picture I attached (i.e. version 2.13).

Try this:
https://docs.silabs.com/bluetooth/latest/le-connection#evt_le_connection_opened