Just as an update, this issue will be fixed in the next revision of the CP2102N (A02). Until then, there is a work-around that was found by one of our developers:
"The device is looking at the incorrect byte of the SERIAL_HANDFLOW structure (https://msdn.microsoft.com/en-us/library/windows/hardware/jj680685(v=vs.85).aspx). Instead of looking at the first byte of FlowReplace, it is reading the first byte of XonLimit and interpreting that as the first byte of FlowReplace. .NET sets the Xon/Xoff limits to 160, equal to 0xA0, which the CP2102N setModemHandshake function interprets as hardware flow control, and so it returns an error when manually setting RTS. I modified code I found at (https://social.msdn.microsoft.com/Forums/vstudio/en-US/89b88e89-5814-4819-8b50-7caa3faf5f54/xonxoff-values-in-net20-serialport-class?forum=csharpgeneral) to create a potential workaround in software (attached as Program.cs). This code sets the ON/XOFF limits to 0x00. Because of additional .NET limitations, I had to enable hardware flow control, enable the port, then switch to none - make sure this doesn't cause issues in your system. The fix allows the CP2102N to properly set/clear the RTS signal."

Program.cs is attached.

Just as an update, this issue will be fixed in the next revision of the CP2102N (A02). Until then, there is a work-around that was found by one of our developers:
"The device is looking at the incorrect byte of the SERIAL_HANDFLOW structure (https://msdn.microsoft.com/en-us/library/windows/hardware/jj680685(v=vs.85).aspx). Instead of looking at the first byte of FlowReplace, it is reading the first byte of XonLimit and interpreting that as the first byte of FlowReplace. .NET sets the Xon/Xoff limits to 160, equal to 0xA0, which the CP2102N setModemHandshake function interprets as hardware flow control, and so it returns an error when manually setting RTS. I modified code I found at (https://social.msdn.microsoft.com/Forums/vstudio/en-US/89b88e89-5814-4819-8b50-7caa3faf5f54/xonxoff-values-in-net20-serialport-class?forum=csharpgeneral) to create a potential workaround in software (attached as Program.cs). This code sets the XON/XOFF limits to 0x00. Because of additional .NET limitations, I had to enable hardware flow control, enable the port, then switch to none - make sure this doesn't cause issues in your system. The fix allows the CP2102N to properly set/clear the RTS signal."

Program.cs is attached.

Just as an update, this issue will be fixed in the next revision of the CP2102N (A02). Until then, there is a work-around that was found by one of our developers:
"The device is looking at the incorrect byte of the SERIAL_HANDFLOW structure (https://msdn.microsoft.com/en-us/library/windows/hardware/jj680685(v=vs.85).aspx). Instead of looking at the first byte of FlowReplace, it is reading the first byte of XonLimit and interpreting that as the first byte of FlowReplace. .NET sets the Xon/Xoff limits to 160, equal to 0xA0, which the CP2102N setModemHandshake function interprets as hardware flow control, and so it returns an error when manually setting RTS. I modified code I found at (https://social.msdn.microsoft.com/Forums/vstudio/en-US/89b88e89-5814-4819-8b50-7caa3faf5f54/xonxoff-values-in-net20-serialport-class?forum=csharpgeneral) to create a potential workaround in software (attached as Program.cs). This code sets the XON/XOFF limits to 0x00. Because of additional .NET limitations, I had to enable hardware flow control, enable the port, then switch to none - make sure this doesn't cause issues in your system. The fix allows the CP2102N to properly set/clear the RTS signal."

Program.cs is attached.

Can you see the voltage change on GPIO8 with a multimeter? Does iop_GetAnalogPin return any changing values?

I think there's an error in Xpress Configurator - the 'alternate' pin function lists VBUS_SENSE/ADC (input), but I think the alternate input is solely ADC Input - is the ping configured for that setting - "VBUS_SENSE/ADC (input)"?

Unfortunately, I didn't see any demo code for this. We have an internal iop example, but it only uses the CP2615 to download some configurations to a codec using I2C... nothing about using the ADC mode of GPIO8. =(

Just to confirm, you are using the pins on the right side of the CFG header (J13-J16) to connect to your external board?

Have you tested this same configuration on the eval board's CP2615 to see if the configuration gives you the correct behavior?

What OS are you using, and do you mind attaching your configuration so I can reproduce the issue here?

Hi Nick,

The latest version of the driver should no longer have this issue. Version 10.1.2 included the fix for RS4/1803 in May, we're currently on version 10.1.3.

-Brian

What errors are you receiving? What IDE are you using?

I tried to build this in the 8-bit IDE, and got an Improper Fixup error. This was resolved by removing 'bdata' from the Is_Initialized variable declaration/definition in F34x_MSD_MMC.c and F34x_MSD_Cmd.c

https://www.silabs.com/community/software/simplicity-studio/forum.topic.html/an282_and_improperf-t9nP