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