Hi Igor,

Yes, I've tested with Windows Driver v101.8.2466 and even though through the terminal program I can try to set to a higher baud rate, the VCP driver limits the BR down to 921,600. I'll get with our VCP driver development team and see if we can roll back this limitation for the CP2103 in the next driver release, as it should at the very least allow for 1Mbaud as specified in the datasheet. 

The import does not appear to be linking the emlib files and board specific include paths. Could you try to re-import the example project, but this time in the import "Reconstruct Build Configurations" window, manually enter your starter kit board name (BRD4161A Rev A02) and verify that it auto fills the part field also - 

Also, please verify that all the other fields are valid and as intended. I still get the "Selected part is not compatible with this project" warning at the top, but if I ignore and click next and finish, the project imports correctly and builds without error.

The import does not appear to be linking the emlib files and board specific include paths. Could you try to re-import the example project, but this time in the import "Reconstruct Build Configurations" window, manually enter your starter kit board name (BRD4161A Rev A02) and verify that it auto fills the part field also - 

Also, please verify that all the other fields are valid and as intended. I still get the "Selected part is not compatible with this project" warning at the top, but if I ignore and click next and finish, the project imports correctly and builds without error.

The import does not appear to be linking the emlib files and board specific include paths. Could you try to re-import the example project, but this time in the import "Reconstruct Build Configurations" window, manually enter your starter kit board name (BRD4161A Rev A02) and verify that it auto fills the part field also - 

I still get the "Selected part is not compatible with this project" error, but if I ignore and click next and finish, the project imports correctly and builds without error.

The import does not appear to be linking the emlib files and board specific include paths. Could you try to re-import the example project, but this time in the import "Reconstruct Build Configurations" manually enter your starter kit board name (BRD4161A Rev A02) and verify that it auto fills the part field also - 

I still get the "Selected part is not compatible with this project" error, but if I ignore and click next and finish, the project imports correctly and builds without error.

Hi Igor, Can you verify whether the enhanced port of the CP2105 allows you to change the baud rate to 1200000 and 2000000? The CP2105 datasheet specifies valid baudrates of 2400 bps to 921600 bps for the standard UART interface of the CP2105 and 300 bps to 2.0 Mbps for the enhanced UART interface. The CP2103 datasheet specifies baud rates from 200 bps to 1 Mbps.

Hi Igor, Can you verify whether the enhanced port of the CP2105 allows you to change the baud rate to 1200000 and 2000000? I am getting the problem you've reported with the CP2105 standard port and CP2103, and have reported this to our Windows driver support team.

I too do not see a compiler bug. Speaking of asm.png: The "orr" instruction is preceded by an "it" instruction (If-Then). The next line after the "it" does not have any effect, if the condition is not met (lt, Less-Than). To prove that, just change R3 to 0x4000AAF4 right before executing the comparison and have a look of what the "orr" does, it does nothing.

BTW: If this had been hand-crafted assembler, you had to write "orrlt r3, r3, #0x20000000" to make your intention clear. But even if you do so, the disassembler strips the "lt", leaving the "orr" on the screen.

Ah, and .w does not mean 16 Bit. It does mean "wide", 32 Bit instruction encoding. In contrast, .n means "narrow", 16 Bit instruction encoding. The comparison, however, is done with a 12 Bit immediate, as Austin said, which is perfectly fine in this case.

As for your bug, you have to look somewhere else, I'm afraid.

 

I'm not sure I'd describe this issue as a bug, but rather a effect of compiler optimization. Have you tried using a different compiler, such as the IAR compiler? Do you see the same differences in the assembly with differing levels of optimization? Do you believe that this comparison is causing a problem in your firmware, or are you just noticing a difference in the assembly with the various optimization levels?

Could you please try updating with the VCP driver provided on our website - https://www.silabs.com/products/development-tools/software/usb-to-uart-bridge-vcp-drivers? This should be version 10.1.8.2466.

Also, what terminal application are you using? I am able to manually set a variable baud rate using RealTerm and do not get any errors.

Can you provide a screen capture of the error message? I think this might be a limitation of the application, not the driver. I've verified with oscilloscope that the settings took for 2 Mbaud...here is a screen capture of an asscii "U"