On Tue, Jun 08, 2021 at 09:10:51AM +0000, Tung Pham wrote: > On Linux you can use manufacturing library to check firmware version. Ah, I remember now that you sent a link to this application a few ago in another thread. > Then it display some information of device: > > Found 1 CP210x devices > Device 0: > Product String - serial number: "a0d16702d2a3e81187d86c93f375b2a8" > Product String - Description: "CP2102N USB to UART Bridge Controller" > Error: CP210x_GetProductString() failed to return Full Path, status = 0x2 > Product String (unsafe) - CP210x_GETPRODUCTSTRING_SERIAL_NUMBER: "a0d16702d2a3e81187d86c93f375b2a8" > Product String (unsafe) - CP210x_GETPRODUCTSTRING_DESCRIPTION: "CP2102N USB to UART Bridge Controller" > Error: CP210x_GetProductString(CP210x_GETPRODUCTSTRING_FULL_PATH) failed, status = 0x2 > Part Number = 0x20 > Firmware version = 0.1.1 > Vendor ID = 0x10C4 > Product ID = 0xEA60 > > The Firmware version is field that we need to looking for, it is > formatted as major version; minor version; and patch. > The A01 have range <= 1.0.4 version. It have error "3.6 CP2102N_E104 – > IO Exception in .NET Applications when Manually Controlling RTS" as > the cp2102n-errata.pdf have mentioned. Thanks for the details and for confirming or findings. > Our recommend is you can chose 2 options: > - option 1: remove the set xon_limit and xoff_limit lines in driver, > because our firmware automatically set these value to some default > values (usually very small values) in its memory if it detect these > values are zeros. Yeah, this was the fallback option I had in mind, but the CP2102N I have here then sent XOFF after having received only 7 chars or so when I tried it. > - option 2: archive Part Number and Firmware version, > check if ( (PART_NUMBER == CP2102N_QFN28) \ > || (PART_NUMBER == CP2102N_QFN24) \ > || (PART_NUMBER == CP2102N_QFN20)) > and Firmware version <=1.0.4 set the xon_limit and xoff_limit to > zeros, other while set to other values. This option are more > suitable. > > #define CP2102N_QFN28 0x20 > #define CP2102N_QFN24 0x21 > #define CP2102N_QFN20 0x22 Yes, we'll go with something like that now that we know how to check the firmware version. I guess it's even possible to implement flow-control support for these buggy firmware revisions (by abusing xon_limit), but that would be a new feature and not something that's needed to fix the regression. Thanks again. Johan
