一条 12 英寸晶圆产线单台设备每小时能产生上万条 SECS 消息。但决定良率的往往不是这些消息而是一个几十 KB 的 Recipe 文件。Recipe 就是工艺参数文件刻蚀多深、沉积多厚、退火多久全写在里面。用对了 Recipe良率 98%用错了直接掉成 60%。SECS/GEM 里专门用S7流消息来管这件事行业里通常叫 S2F25Recipe 管理的统称。这个环节看起来只是下载一个文件但实际调过的人都知道这里面的坑比 HSMS 连接还多。我把我踩过的 3 个最痛的坑分享出来都是真实场景但隐去了具体项目信息。坑一PPID 名字对了但 Checksum 死活对不上现象EAP 通过S7F5请求下载 Recipe设备回S7F6把 Recipe Body 发过来。EAP 校验 Checksum结果报错Recipe Checksum mismatch。一开始我以为 EAP 的 Checksum 算法写错了。我换了三种算法CRC32、MD5、Simple XOR都试了一遍设备还是报 mismatch。排查我直接拿设备端的 Recipe 文件和 EAP 端的文件做二进制对比。发现两个文件内容完全一样但设备端在文件末尾多了一个\r\n换行符。原因很荒谬EAP 从 MES 的 FTP 服务器下载 Recipe 时FTP 客户端默认按文本模式传输把\r\n转成了\n。设备端是按二进制模式校验的所以 Checksum 永远对不上。解决方案所有 Recipe 传输必须强制使用二进制模式。不管是 FTP、SCP 还是 HTTP 下载客户端配置里都要加binaryTrue或同等参数。另外CheckSum 校验不要只算 Body 内容要和设备端确认是否包含文件头是否包含末尾换行符设备厂商的文档往往不写这么细你得自己问。坑二Recipe 字段顺序变了设备解析失败现象新一批设备进厂EAP 用同样的流程下载 Recipe校验通过了设备却报Recipe Invalid。设备日志显示Missing required parameter: ChamberTemp。我打开 Recipe 文件一看ChamberTemp 明明在里面。但设备就是不认。排查把新老设备的 Recipe 模板对比发现同一个参数老设备是plain复制ChamberTemp85.0 Pressure10.0 GasFlow50.0新设备要求plain复制Pressure10.0 ChamberTemp85.0 GasFlow50.0新设备加了字段顺序校验。如果 ChamberTemp 出现在 Pressure 后面解析器直接报错。更坑的是这个设备厂商在协议文档里只写了Required Parameters没提字段顺序。解决方案Recipe 管理必须做版本绑定EAP 端维护一个RecipeTemplate表记录每台设备支持的字段和顺序下载前EAP 根据设备型号动态调整字段顺序不要假设同品牌设备用同一种格式同品牌不同型号都可能不同另外设备验收阶段就要做 Recipe 下载验证不要等量产了才发现格式不对。坑三PPID 存在但 Body 是空的产线跑出了废片现象这是最痛的一个坑。EAP 下载 Recipe 成功设备回S7F4确认收到EAP 日志显示Recipe downloaded: ETCH_V2.1。产线正常跑加工完成后良率报警发现晶圆刻蚀深度完全不对。查设备本地 Recipe发现文件存在但内容只有 2 个字节{}空 JSON。排查EAP 的S7F5请求里PPID 是ETCH_V2.1。设备端有这个 PPID但对应文件在之前的维护中被误删了设备返回了一个空 Body。问题出在设备回S7F6时没有检查文件是否存在直接发了一个空 Body。EAP 收到后只校验了 Checksum空文件的 Checksum 也是合法的没检查文件大小就认为是下载成功。解决方案EAP 端加文件大小校验Recipe 下载后检查 Body 长度是否大于某个阈值比如 100 字节。如果太小拒绝执行报Recipe Body Empty。设备端加保护如果 PPID 存在但文件为空设备应该回S7F6时带错误码而不是发空 Body。Recipe 下载后做验证设备收到 Recipe 后先解析一遍所有字段确认无空值再回S7F4。不要只看文件名对就开工。三个坑背后的共同教训这三个坑看似不同但根因是一样的Recipe 管理把下载成功当成了可用。实际上Recipe 的完整流程应该是下载S7F5→S7F6文件传过来校验Checksum Body 长度 字段完整性验证设备解析一遍确认无空值、无越界确认设备回S7F4才真正可用很多 EAP 系统只做了第 1 步后面 3 步省略了认为传过去就行。但半导体厂的 Recipe 是良率的生命线一步都不能省。给刚入行工程师的建议如果你刚开始做 Recipe 管理记住这三点Checksum 要约定算法和范围是只算 Body还是包含 Header换行符算不算写进技术协议。Recipe 要做版本和设备绑定不要一套 Recipe 走天下每台设备可能有自己的字段顺序和必填项。空文件比错文件更危险错文件至少会报错空文件可能静默通过最后反映在良率上追查成本极高。基于这些经验我整理了一份《SECS/GEM调试手册》有需要的朋友可以交流。
S2F25 配方管理：半导体厂最值钱的环节，我踩过 3 个坑
一条 12 英寸晶圆产线单台设备每小时能产生上万条 SECS 消息。但决定良率的往往不是这些消息而是一个几十 KB 的 Recipe 文件。Recipe 就是工艺参数文件刻蚀多深、沉积多厚、退火多久全写在里面。用对了 Recipe良率 98%用错了直接掉成 60%。SECS/GEM 里专门用S7流消息来管这件事行业里通常叫 S2F25Recipe 管理的统称。这个环节看起来只是下载一个文件但实际调过的人都知道这里面的坑比 HSMS 连接还多。我把我踩过的 3 个最痛的坑分享出来都是真实场景但隐去了具体项目信息。坑一PPID 名字对了但 Checksum 死活对不上现象EAP 通过S7F5请求下载 Recipe设备回S7F6把 Recipe Body 发过来。EAP 校验 Checksum结果报错Recipe Checksum mismatch。一开始我以为 EAP 的 Checksum 算法写错了。我换了三种算法CRC32、MD5、Simple XOR都试了一遍设备还是报 mismatch。排查我直接拿设备端的 Recipe 文件和 EAP 端的文件做二进制对比。发现两个文件内容完全一样但设备端在文件末尾多了一个\r\n换行符。原因很荒谬EAP 从 MES 的 FTP 服务器下载 Recipe 时FTP 客户端默认按文本模式传输把\r\n转成了\n。设备端是按二进制模式校验的所以 Checksum 永远对不上。解决方案所有 Recipe 传输必须强制使用二进制模式。不管是 FTP、SCP 还是 HTTP 下载客户端配置里都要加binaryTrue或同等参数。另外CheckSum 校验不要只算 Body 内容要和设备端确认是否包含文件头是否包含末尾换行符设备厂商的文档往往不写这么细你得自己问。坑二Recipe 字段顺序变了设备解析失败现象新一批设备进厂EAP 用同样的流程下载 Recipe校验通过了设备却报Recipe Invalid。设备日志显示Missing required parameter: ChamberTemp。我打开 Recipe 文件一看ChamberTemp 明明在里面。但设备就是不认。排查把新老设备的 Recipe 模板对比发现同一个参数老设备是plain复制ChamberTemp85.0 Pressure10.0 GasFlow50.0新设备要求plain复制Pressure10.0 ChamberTemp85.0 GasFlow50.0新设备加了字段顺序校验。如果 ChamberTemp 出现在 Pressure 后面解析器直接报错。更坑的是这个设备厂商在协议文档里只写了Required Parameters没提字段顺序。解决方案Recipe 管理必须做版本绑定EAP 端维护一个RecipeTemplate表记录每台设备支持的字段和顺序下载前EAP 根据设备型号动态调整字段顺序不要假设同品牌设备用同一种格式同品牌不同型号都可能不同另外设备验收阶段就要做 Recipe 下载验证不要等量产了才发现格式不对。坑三PPID 存在但 Body 是空的产线跑出了废片现象这是最痛的一个坑。EAP 下载 Recipe 成功设备回S7F4确认收到EAP 日志显示Recipe downloaded: ETCH_V2.1。产线正常跑加工完成后良率报警发现晶圆刻蚀深度完全不对。查设备本地 Recipe发现文件存在但内容只有 2 个字节{}空 JSON。排查EAP 的S7F5请求里PPID 是ETCH_V2.1。设备端有这个 PPID但对应文件在之前的维护中被误删了设备返回了一个空 Body。问题出在设备回S7F6时没有检查文件是否存在直接发了一个空 Body。EAP 收到后只校验了 Checksum空文件的 Checksum 也是合法的没检查文件大小就认为是下载成功。解决方案EAP 端加文件大小校验Recipe 下载后检查 Body 长度是否大于某个阈值比如 100 字节。如果太小拒绝执行报Recipe Body Empty。设备端加保护如果 PPID 存在但文件为空设备应该回S7F6时带错误码而不是发空 Body。Recipe 下载后做验证设备收到 Recipe 后先解析一遍所有字段确认无空值再回S7F4。不要只看文件名对就开工。三个坑背后的共同教训这三个坑看似不同但根因是一样的Recipe 管理把下载成功当成了可用。实际上Recipe 的完整流程应该是下载S7F5→S7F6文件传过来校验Checksum Body 长度 字段完整性验证设备解析一遍确认无空值、无越界确认设备回S7F4才真正可用很多 EAP 系统只做了第 1 步后面 3 步省略了认为传过去就行。但半导体厂的 Recipe 是良率的生命线一步都不能省。给刚入行工程师的建议如果你刚开始做 Recipe 管理记住这三点Checksum 要约定算法和范围是只算 Body还是包含 Header换行符算不算写进技术协议。Recipe 要做版本和设备绑定不要一套 Recipe 走天下每台设备可能有自己的字段顺序和必填项。空文件比错文件更危险错文件至少会报错空文件可能静默通过最后反映在良率上追查成本极高。基于这些经验我整理了一份《SECS/GEM调试手册》有需要的朋友可以交流。
