Answer

This is a known issue and Silicon Labs is working on updating the library. 

When a device enumerates as a CP210x, the host asks the device a string of questions, which are either ACK'ed or NAK'ed (till the information is made available by the device). If the device is NAK-ing, the host will continue to wait for the information from the device and we are in a sense "stuck". 

The USB traffic for this particular case shows that there is a command(lock_byte) causing a continuous stream of NAK's from the device. The device was not being recognized as a COM port in teraterm because the device had not fully enumerated in this case. This does not happen in case of a CP210x device, because all the commands are handled in the library source. The VCPXpress is for devices that behave as CP210x, hence parameters such as lock byte, gpio configuration of the CP210x device etc have no meaning. When such information is asked for by the host, the device is supposed to stall the host. The host will then continue to handle other commands sent and the device will be finally enumerated.

There is an error in the VCPXpress library code that was causing this issue. This change needs to be done in a lot of APIs within the library source and will need to undergo testing which is current underway. There is a patch that fixes the issue mentioned above (which is attached to this article). This has to be replaced in the library in the SDK. A point to be kept in mind is that this is a WIP library and we will be rolling out the fixed version soon.