ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

解决CH340驱动冲突:用CH34xSerCfg修改VID/PID完整教程

解决CH340驱动冲突:用CH34xSerCfg修改VID/PID完整教程 你有没有遇到过这种情况一个绿色的CH340模块插在电脑上设备管理器里明明显示“USB-SERIAL CH340 (COM3)”但某天换了一个模块或者同时插了两个不同牌子但都用CH340的板子其中一个总是变成未知设备COM口时有时无甚至程序打开串口直接报“端口被占用”。很多人第一反应是驱动坏了重新卸载安装结果折腾一下午还是老样子。其实问题很可能就出在VID/PID上。所有CH340芯片出厂默认的VID是1A86PID是5523Windows拿到这组ID之后就去匹配驱动一旦两个设备用同一个ID系统就分不清谁是谁驱动缓存一乱冲突就来了。CH34xSerCfg是沁恒官方提供的小工具能直接修改USB转串口芯片的VID/PID把ID改成你自己项目独有的值从根上避开这种冲突。这篇教程适合硬件工程师、嵌入式开发者和DIY玩家手把手带你走完整条路从原理到翻车恢复都有。1. 驱动冲突是怎么找上你的VID/PID与Windows驱动匹配机制1.1 VID/PID到底是什么VID是Vendor ID厂商ID由USB-IF组织分配用来标识这个USB设备是哪家厂商做的。沁恒的VID是1A86FTDI的VID是0403Silicon Labs的VID是10C4。PID是Product ID产品ID由厂商自己定义用来标识同一个厂商下的不同产品。CH340的默认PID通常是5523CH341也是5523这个比较特殊容易混淆CH9102的PID就是55D4每个型号可能不一样。USB设备插到电脑上之后主机控制器通过USB枚举流程读取设备描述符里面最重要的字段就是idVendor和idProduct。操作系统拿到这两个值再去自己的驱动库里找对应的驱动。你可以把它理解成身份证号VID是发证机关PID是证件编号两者组合起来才是一个设备的完整身份。只靠“USB转串口芯片”这个名称系统是没法精确匹配驱动的必须靠这组ID。1.2 Windows按什么规则给USB设备装驱动Windows在发现新设备的时候会先读取VID/PID然后去C:\Windows\System32\DriverStore\FileRepository这个目录下搜索所有INF文件看哪个INF声明支持这个VID/PID组合。INF文件里有一个[Models]段里面写的就是类似“USB\VID_1A86PID_5523”的硬件ID。如果只有一个驱动匹配那没问题直接装但如果多个驱动都声明支持同一个VID/PID情况就复杂了。系统会按照驱动签名、日期、版本号、发布者等条件选择优先级最高的那个。问题在于这个选择结果不一定是你要的。比如你电脑里装过某个旧设备的驱动包里面包含了一个老版本的CH340驱动它声称支持VID_1A86PID_5523签名和日期又恰好比官方新驱动更“靠前”Windows就可能给所有CH340芯片都装上这个老驱动。结果就是你新买的模块能枚举但通信一会儿断一会儿断或者波特率稍高就出错。1.3 为什么“官方驱动”也可能装错更隐蔽的场景是你手上有两个开发板一个用的是官方CH340模块另一个是某小厂做的CH340板子两个板子的硬件ID完全一样都是1A86:5523。Windows会认为它们是同一个设备共用一套驱动和COM口号。今天插A板子是COM5明天插B板子可能还是COM5但如果你同时插上两个系统就会给其中一个分配COM7另一个分配COM8。问题是你程序里写死的串口号怎么办在自动化测试、多串口设备同时工作的项目里这简直是一场灾难。改VID/PID就是让每块板子有独立的硬件ID然后给不同的ID指定不同的驱动和COM名系统就能从机制上把设备区分开。哪怕两个设备物理上用的是同一颗芯片只要ID不同Windows也会把它们当成两个完全不同的设备来管理。2. CH34xSerCfg工具准备与芯片识别2.1 工具从哪里拿、怎么确认版本CH34xSerCfg是沁恒官方发布的配置工具一般可以在官网的CH340/CH341产品页面里找到也可以在一些开发板厂商的资料包中拿到。工具本身的版本不少界面会有差异但核心功能都是读配置、改配置、写配置这三件事。我建议你尽量去官网下载或者找芯片代理商要最新版避免从某些资源站拿到来历不明的版本。修改VID/PID这类操作会直接写入芯片的配置区或外部EEPROM工具不对或者版本太旧轻则读取失败重则把芯片配置区写坏。拿到工具之后先做两件事第一右键管理员身份运行因为这个工具需要直接访问USB设备权限不够可能读不出来第二打开工具后先别接设备看看主界面有没有设备型号选择或者自动扫描功能心里有个数。2.2 确认自己手上是哪颗芯片这个工具并不是对所有芯片都支持至少要把芯片型号搞对。CH340常见的有CH340C、CH340G、CH340T、CH340N等CH341、CH9102、CH9103等也在支持列表里。最简单的方法就是看芯片表面丝印。CH340G是SOP-16封装CH340C是SOP-16但内置晶振CH340N是SOP-8小封装CH341是SOP-16丝印上都有明确的型号。如果板子已经焊好看不清丝印可以在Windows设备管理器里查看硬件ID。展开“端口COM和LPT”或“通用串行总线设备”右键设备属性详细信息页签里选择“硬件ID”会看到类似USB\VID_1A86PID_5523这样的字符串。根据PID就能大致推断出芯片型号。CH340这类芯片通常VID是1A86PID可能是5523CH341也是5523CH9102是55D4CH9103是55D3之类的。不过最好还是以芯片手册为准别只看PID猜型号因为同一PID可能对应多个型号。2.3 驱动签名与系统环境的坑改配置之前先把芯片驱动装好保证设备在系统里能正常识别。尤其要注意修改VID/PID之后原来的驱动匹配1A86:5523就不再认这个设备了系统会把它识别成一个陌生的USB设备显示黄色感叹号。这不是操作失败而是驱动还没跟上。所以修改之前最好先把新ID对应的驱动INF准备好或者至少知道手动指定驱动的入口在哪里。Windows 10/11的驱动签名校验默认是强制开启的。官方工具本身是签过名的没问题但如果你后面要生成自定义INF在64位系统上加载没有签名的驱动就会很麻烦。个人开发者在测试阶段可以用“禁用驱动程序强制签名”的方式临时加载测试驱动重启后签名校验会恢复。如果你要发布产品给别人用建议走正规的数字签名流程。这一步需要提前规划因为EV代码签名证书的申请周期可能要一两周纯个人DIY就无所谓了。3. 保姆级修改流程读、改、写、验3.1 连接设备并读取原始配置把USB转串口模块插入电脑确认系统已经认出设备。打开CH34xSerCfg界面一般会列出一个设备列表里面显示当前连接的设备名称或硬件ID。选择你要操作的设备点击“读取”Read工具就会通过USB控制传输读取芯片内部的配置信息然后显示在界面上。我经常看到有人跳过读取直接修改结果把自己原来的配置覆盖了。这一步真的不要省。读取之后用手机拍个照或者复制到记事本保存把原始VID、PID、芯片型号、版本号这些信息留底。万一后面写坏了你至少知道出厂值是多少可以尝试恢复。我自己踩过这个坑当年改一个模块的PID没留原始值结果写了一个非法ID进去系统不认折腾了好久才从另一颗同型号芯片上读回默认配置才把砖救回来。3.2 修改VID/PID的正确姿势在界面上找到VID和PID的输入框输入你想要的值。这里有两个常见的坑。第一个是数据宽度。VID是16位十六进制数通常写成4位比如1A86。PID也是16位4位十六进制比如5523。工具界面如果要求不带0x前缀你就直接填四位十六进制字符如果要求带0x就补全成0x1A86这样的格式。填错位数或者填了非法字符工具一般会拒绝写入但也有的版本会把数据截断写出一个奇怪的ID后面设备就无法枚举了。第二个是ID冲突问题。不要随便用其他厂商的VID比如FTDI的0403、Silicon Labs的10C4因为那是别人注册的厂商ID和你的设备定义不相符。真正做产品发布需要向USB-IF申请自己的VID或者购买一个合法的VID。如果只是DIY或者公司内部使用不想走申请流程可以保留沁恒的VID1A86只修改PID来区分不同产品线。这样也能达到避免驱动冲突的目的因为驱动匹配是按VIDPID组合来的PID只要不同驱动就能区分开。3.3 写入与重新枚举填写完成后点击“写入”Write。写入过程中芯片会重新枚举USB连接会断开一下设备管理器里的设备会消失几秒然后又出现新硬件这是正常现象不要慌。写入成功之后有一个很关键的步骤拔掉USB线等两三秒再重新插一次让芯片以新的ID重新枚举。这个重新拔插的动作我在教程里反复强调因为很多人都只看到工具提示“写入成功”就以为大功告成结果设备管理器里显示的还是旧ID。有些芯片在写入后需要重新上电才能生效工具里的写入成功只是说数据已经写进配置区了但芯片还没有真正切换。重新拔插后再看设备管理器基本就能看到新ID了。3.4 验证修改是否生效重新插上后打开设备管理器查看端口COM和LPT或通用串行总线设备里的设备属性在“详细信息”页签的“硬件ID”属性里应该能看到新的VID/PID。如果你改了PID比如改成1A86:6001硬件ID里就会显示VID_1A86PID_6001。用USBView或usbdeview这类工具看更直观它们可以直接读出设备描述符里的idVendor和idProduct以及序列号、厂商字符串等。我习惯同时打开设备管理器和usbdeview对照看因为设备管理器有时候会缓存旧信息。如果设备管理器里已经显示新ID说明修改成功。如果设备变成未知设备也不用急下一节专门讲怎么处理。4. 翻车现场与恢复方案4.1 写错ID导致系统不认设备这是最常见的翻车情况。比如你写的时候少了一位或者写入了保留值0x0000芯片枚举出来的ID乱七八糟Windows直接不认。这时候不要立刻以为芯片废了。首先拔掉USB线冷静一下。大多数CH340芯片的配置区是可以重新写入的关键是Windows不识别时CH34xSerCfg可能也找不到设备。解决办法是在设备管理器里选中未知设备右键更新驱动手动把驱动指向沁恒官方驱动的兼容版。这一步的目的是让设备先被系统认成CH340重新变成“USB-SERIAL CH340”之类可识别的设备然后再打开配置工具重新把ID改回来。如果这一招不行还可以尝试进入芯片的ROM bootloader模式。不同芯片进入方式不一样有的需要把TXD和RXD短接再上电有的需要在复位时拉低某个引脚。具体操作要查对应芯片手册不要乱试。进了bootloader之后用官方烧录工具可以把芯片恢复到出厂配置。这个操作相对底层如果芯片封装太小飞线操作会很痛苦所以最好在修改之前就做好备份。4.2 Windows缓存驱动的连锁反应另一个很隐蔽的问题是Windows对USB设备有缓存即便你改好了ID系统可能还残留旧设备的信息。USB设备一旦被识别过系统会在注册表里记录设备实例路径旧ID的缓存也会保留。当你改完ID重新插上系统会把它当成一个新设备同时旧缓存还在如果你再把ID改回去系统会用缓存里的驱动信息可能导致“残余设备”和“当前设备”同时存在设备管理器里出现两个一模一样的设备名字其中一个带感叹号。建议每次改完ID都在设备管理器里右键删除设备并且勾选“删除此设备的驱动程序软件”然后点“扫描检测硬件改动”让系统重新枚举一次。这个操作可以清掉大部分缓存问题。如果删完还是有残留可以打开“显示隐藏的设备”把幽灵设备也删掉。注册表里的USB设备缓存不建议新手去手动改容易把系统搞坏。4.3 用官网驱动或自定义INF把设备“救回来”如果是自己的产品要发布给用户建议制作专用INF里面明确写上新VID/PID再放入自己的驱动包。这样设备插入后用户看到的设备名可以显示成你公司的产品名而不是通用的USB-SERIAL CH340。INF的基本结构不复杂一个最简的INF文件大概长这样[Version] Signature$Windows NT$ ClassPorts ClassGuid{4D36E978-E325-11CE-BFC1-08002BE10318} Provider%ProviderName% DriverVer01/01/2024,1.0.0.0 [Manufacturer] %ProviderName%DeviceList,NTamd64 [DeviceList.NTamd64] MyDevice.DeviceNameUSB\VID_1A86PID_6001 [DestinationDirs] DefaultDestDir12 [MyDevice_Service] DisplayName%ProviderName% ServiceType1 StartType3 ErrorControl1 ServiceBinary%12%\ch9344ser.sys [Strings] ProviderNameMyCompany MyDevice.DeviceNameMyCompany USB Serial Port这个例子只是让大家知道结构实际做驱动包时还需要处理驱动文件、签名和安装脚本。64位Windows下驱动文件必须有数字签名否则安装会被拒绝。个人开发者可以用测试签名模式或者购买EV代码签名证书。我在项目里一般会先做一套未签名INF用于内部测试等产品稳定了再走签名流程。这个周期确实长但产品要交付给客户这一步躲不掉。5. 批量定制与长期维护的经验教训5.1 按项目规划VID/PID而不是随手改很多朋友改完ID发现不冲突了就把ID记在小本本上下一个项目又随手改了另一个ID。这样做短期没问题但批量生产时会乱。建议按项目分配ID段。比如一个产品线固定一个PID不同硬件版本用PID的低字节区分或者把序列号字段用来区分批次。CH34xSerCfg通常也支持配置序列号。序列号对多设备管理非常有用。你可以让每一块板子的序列号连续增长比如MYDEV0001、MYDEV0002。这样Windows会把它们识别为不同设备COM口号可以稳定对应不会互相串。尤其是接多个同型号模块的测试治具有序列号和没有序列号完全是两个体验。没有序列号时Windows区分不了两个相同VID/PID的设备COM口号分配完全随机程序根本没法稳定找到目标设备。5.2 不同操作系统踩过的坑在Linux下系统用的是内核自带的cdc_acm或者ch341驱动它不一定理会VID/PID很多时候只要芯片是CH340就能识别。但你如果改成特殊ID有些发行版的modprobe配置可能会把它当成未知设备。解决办法是自己写udev规则按新的VID/PID给设备分配固定权限和别名。举个例子在/etc/udev/rules.d/下新建一个规则文件比如99-mydev.rulesATTRS{idVendor}1a86, ATTRS{idProduct}6001, MODE0666, SYMLINKttyUSB_mydev修改后执行sudo udevadm control --reload和sudo udevadm trigger再把设备重新插一次。这样/dev/ttyUSB_mydev就会固定存在不管系统把设备识别成ttyUSB0还是ttyUSB1你程序里直接打开固定别名就行再也不用去猜设备名。macOS也是类似逻辑系统对USB串口芯片的支持比较粗多数情况下不改ID也能识别但如果你改了PID某些老版本系统可能不认需要手动安装厂商驱动。我的建议是修改ID后在所有目标系统上都插一遍不要只在Windows上通过就认为万事大吉。尤其是工业现场用Linux的一定要提前把udev规则和权限配置好不然现场设备插上没权限访问串口会比驱动冲突更让人崩溃。5.3 打样和量产时的一致性检查如果你是公司批量生产建议写一个简单的质检脚本。每生产一块板子用CH34xSerCfg批量写入预置的VID/PID和序列号然后用串口工具回读确认设备管理器里的硬件ID和序列号和计划一致。这个步骤可以通过命令行工具或脚本配合Windows设备信息查询完成。我见过很多工厂流水线上的板子写着写着就有一批PID写成了0x0000因为工装夹具接触不良写操作被中断。回读校验能把这批问题板子拦在前端而不是等到成品出货之后才在客户现场发现驱动冲突。做产品不比自己做着玩ID写错导致的产品返工人工和物流成本远大于写配置那几秒钟。另外批量写入时的生产文件一定要受控。我习惯把每个项目的VID/PID、序列号规则、驱动包版本放在一个统一的表格里由负责人审核后发布给产线。产线电脑上只放当前项目的配置文件避免上一批产品的配置被误刷到这一批板子上。这件事听起来很基础但实际踩坑的人不少。最后说个我自己的习惯拿到任何一颗USB转串口芯片我做的第一件事不是急着接线路而是先把它的出厂VID/PID读出来存档然后在标签上写清楚项目代号和改好的ID。修改VID/PID不是一个高频操作但一旦需要它的时候往往是在生产现场或者客户那边手忙脚乱时最容易出错。把工具、驱动包、原始配置和恢复方法放在同一个文件夹里比临时去官网下载靠谱得多。希望这篇教程能帮你少走弯路。
返回列表