前往官网 
发布
CW080发布：君正交出AI穿戴视觉的旗舰答卷
CW080发布：君正交出AI穿戴视觉的旗舰答卷 穿戴设备的视觉能力不是只加一颗摄像头 AI眼镜、拍照耳机、智能手表陆续推出，但体验和销量真正站住脚的并不多。镜腿、耳机柄空间有限，电池被迫压缩，散热天然受限。要在这样的物理约束下实现高清拍摄、防抖稳定、快速抓拍，传统ISP方案很难兼顾。 CW080是全新定义首颗AI穿戴旗舰ISP，2026年Q1正式发布——将轻薄穿戴设备的视觉能力真正转化为实用功能 功耗分层管理不浪费每一毫瓦 AI穿戴设备续航受限，一是因为电池容量有限；二是因为现在穿戴设备方案的耗电量大，没有真正的符合穿戴设备要求的低功耗解决方案。 CW080的思路很清晰：专注于图像的效果呈现，图像采集、4K编码、EIS防抖由ISP独立处理；蓝牙连接、语音交互、系统调度交由MCU负责。非图像采集模式下进入深度休眠，杜绝无效的电量消耗。CW0 80实测数据• ➤ 待机功耗：CW080SN：6mW；CW080SNP：1mW• ➤ 1080P@30fps录像开EIS，整机功耗350mW• ➤ 全天候感知场景，平均功耗仅9mW 在300mAh电池供电情况下，CW080系列可以实现持续录制接近100个1分钟视频，或者在全天候实时现实感知场景下持续运行72小时，CW080SNP待机时间可以达到30天。 CW080 功耗分层管理 / 架构图7*11mm封装内置DDR为结构设计留足余地 CW080采用7*11mm一体化封装，片上集成128MB DDR3，无需外挂内存。 外围器件减少，镜腿可更窄；散热路径优化，长时间录像无明显温升；兼容单摄/双摄，覆盖入门到高端多摄设备。 同系列产品矩阵完整：C100（5×6mm）、CW020（2mm超微型，2026Q3）、CW240（8nm高性能高分辨率多摄，2027Q2），客户可按需选型。 成像与响应，两者兼备 CW080支持1200万像素拍照，4K/2K/1080P H.265编码，视频体积减半。硬件级畸变矫正、WDR宽动态、3A算法、EIS防抖全内置。1T NPU可承担物体识别、场景标签等轻量AI推理。 响应速度同样是核心体验。传统方案从触发到成像普遍延迟600ms以上。CW080自研iVGrab v2引擎将拍照全链路压缩至300ms以内，录像启动200ms内完成。 CW080 成像与响应 / iVGrab v2 链路图 量产落地，一站式 穿戴芯片行业，方案演示易、量产落地难。 2025年已有多家AI眼镜客户完成量产验证，覆盖娱乐、商务、运动等赛道。为CW080交付打好坚实基础：1. 标准化硬件参考设计、PCB 布局模板，兼容市面主流蓝牙 MCU，无需客户重新开发底层通信协议；2. 完整 ISP 图像调参工具包，内置防抖、宽动态、畸变矫正成熟参数，省去客户 3–6 个月画质调试周期；3. 多模态交互底层驱动，打通视觉采集 + 数据上传，开配合蓝牙与APP，可实现场景识别、云端视频同步等主流 AI 眼镜功能；4. 专属技术支持团队全程跟进硬件调试、试产良率优化，一站式解决功耗、画质、兼容性量产难题。 不止AI眼镜 CW080适用场景覆盖AI拍摄眼镜、拍照TWS耳机、智能手表等轻量化环境感知终端等多个品类。 除了CW080以外，CW020也即将发布，超小尺寸、极致低功耗，以TWS真无线蓝牙耳机为典型应用场景，赋予耳机环境感知、环境识别、AI交互能力。 结语 CW080不是参数最激进的芯片，在功耗、封装、成像、响应、量产等多维度上都给出了务实的解决方案。 CW080 将于 2026 年第三度正式批量供货，后续将与 CW020、CW240 组成梯度完备的穿戴视觉芯片产品矩阵，完整覆盖高、中、低端全价位智能终端，为各类智能穿戴视觉设备提供分场景、分层级的芯片解决方案。 关于北京君正 北京君正集成电路股份有限公司成立于2005年，基于创始团队创新的CPU设计技术，迅速在消费电子市场实现SoC芯片产业化，2011年5月公司在深圳创业板上市（300223）。君正在处理器技术、多媒体技术和AI技术等计算技术领域持续投入，其芯片在智能视频监控、AIoT、工业和消费、生物识别及教育电子领域获得了稳健和广阔的市场。 2020年，君正完成对美国ISSI及其下属子品牌Lumissil的收购。ISSI面向汽车、工业和医疗等领域提供高品质、高可靠性的存储器产品，包括SRAM、DRAM、NOR Flash、2D NAND Flash和eMMC，客户遍布全球。Lumissil面向汽车、家电和消费电子等领域提供LED驱动、微处理器、电源管理和互联等芯片产品。 君正将整合其积累十几年的计算技术，及ISSI三十余年的存储、模拟和互联技术，利用公司拥有的完整车规芯片质量和服务体系，为汽车、工业、AIoT等行业的发展持续做出贡献。
给耳机装上“眼睛”：君正 CW020 系列正式发布，DDR-less 超小封装开启环境感知耳机新赛道
给耳机装上“眼睛”：君正 CW020 系列正式发布，DDR-less 超小封装开启环境感知耳机新赛道AI 耳机正在从“听”走向“看”全球耳机市场正处于结构性拐点：传统 TWS 增长见顶——2026 上半年中国耳机市场销量 8797 万副、同比下滑 15.9%（洛图数据）；与此同时，AI 耳机成为唯一高增长赛道，全球市场规模预计将从 2026 年的 74.2 亿美元增长至 2030 年的 173.4 亿美元（Research and Markets）。更重要的变化发生在架构与形态上：端云协同成为主流架构：降噪、唤醒等轻任务在端侧，理解、摘要等智能上云。这意味着耳机端芯片的核心任务不是“算”，而是高质量、低功耗地感知采集——把视觉信息干净地交给主控与云端。耳机是被验证的 AI 载体：第三方调研显示，消费者对“带摄像头的耳机”接受度达 93.3%，显著高于眼镜形态（62.7%）。耳机无需改变佩戴习惯，是比眼镜更自然的随身 AI“眼睛”。摄像头正在成为旗舰耳机的新标配：国际头部品牌已陆续为耳机引入摄像头，定位是环境感知传感器（识别人脸、物体、文字与场景，为 AI 助手提供视觉上下文），而非拍照工具。对 ISP 芯片而言，这意味着一组前所未有的苛刻要求：极小封装、极低功耗、极简 BOM、全天候待机。君正 CW020 系列正是为此而生。作为业界尺寸最小的穿戴 ISP 方案之一，CW020 系列以 2×5.5mm（11mm²） 的极致小封装与 DDR-less 架构，专为耳机、眼镜等超小空间可穿戴设备打造，为正在从概念走向货架的环境感知耳机品类，提供关键的视觉入口方案。产品规格四大技术亮点1.全球最小之一，11mm² 塞进耳机柄：CW020UN 面积仅 11mm²（约一粒米大小），可在耳机柄、眼镜腿等传统 ISP 无法进入的空间从容布局——这是摄像耳机从“概念”到“能落地”的关键一步；2.DDR-less 架构，BOM 直降：无需 DDR/PSRAM，仅需 SPI NOR Flash，存储成本与功耗同步下降，为极致成本敏感的穿戴设备扫清量产障碍；3.超低功耗，全天候感知无压力：内置 LDO、外设极简，待机功耗低至 µA 级；低频环境感知抓拍（VGA@1fps）功耗<3mA；4.单摄/双摄灵活可选：CW020UN 主打超小空间单摄，CW020UA 支持 RGB+IR 双摄，覆盖环境感知、扫码、人脸识别触发、视频通话等多元场景。面向场景环境感知耳机（摄像耳机）：实时感知周围环境、人脸、物体与文字，为 AI 助手提供“视觉上下文”——摄像头是传感器，不是相机；AI 眼镜：轻量级视觉眼镜的抓拍、推流与感知入口；穿戴抓拍/扫码：移动支付、身份核验、AR 交互等轻视觉应用。生态与量产就绪CW020 系列提供 Turnkey 方案支持：可与主流蓝牙 SoC 平台适配，参考设计已达到交付标准，助力客户顺利进入产品设计阶段，帮助客户从立项到量产以最快路径落地。CW020UN / CW020UA 即将于 2026 年 9 月下旬开放样品与评估板申请。关于君正股份北京君正集成电路股份有限公司成立于 2005 年，基于创始团队创新的 CPU 设计技术，迅速在消费电子市场实现 SoC 芯片产业化。2011 年 5 月公司在深圳创业板上市（300223），2026 年 8 月登陆香港联交所（03223.HK），完成 A+H 双资本市场布局。君正在处理器技术、多媒体技术和AI技术等计算技术领域持续投入，其芯片在智能视频监控、AIoT、工业和消费、生物识别及教育电子领域获得了稳健和广阔的市场。2020年，君正完成对美国ISSI的收购。ISSI面向汽车、工业和医疗等领域提供高品质、高可靠性的存储器产品，包括SRAM、DRAM、NOR Flash、2D NAND Flash 和eMMC，客户遍布全球。君正将整合其积累十几年的计算技术，及ISSI三十余年的存储、模拟和互联技术，利用公司拥有的完整车规芯片质量和服务体系，为汽车、工业、AIoT等行业的发展持续做出贡献。
T32Pro-AOV 唤醒后音频驱动加载卡死及无法取流的排查与修复
T32Pro-AOV 唤醒后音频驱动加载卡死及无法取流的排查与修复适用范围 本文适用于 T32 平台使用 AOV 低功耗模式的音频场景。系统冷启动后首次加载音频驱动正常，但卸载驱动、进入 AOV、完成唤醒并再次加载音频驱动时，如果出现加载过程卡死、AIC 寄存器状态异常，或者驱动能够加载但录音、放音无法取得音频流，可以按照本文思路检查 AIC 时钟、PDMA 恢复以及 clk 引用计数。问题现象 系统上电后，音频驱动可以正常加载，录音或放音链路也能够工作。卸载音频驱动并进入 AOV 后，系统虽然能够唤醒，但再次加载音频驱动时可能卡住，同时读取到的 AIC 寄存器状态异常。完成部分时钟逻辑修正后，驱动加载可以恢复，但音频数据仍可能无法传输，表现为录音或放音无法取流。 该问题在程序运行、UART0 与外部 MCU 相连且处于下拉状态时可以触发，而 UART0 两个引脚悬空时音频工作正常。不运行程序且不进行音频出流时，即使 UART0 处于下拉状态，休眠唤醒后的音频也可以正常工作。UART0 的连接状态可用于构造对照环境，但最终需要修复的是音频时钟恢复、PDMA 恢复和 clk 引用计数逻辑。诊断过程 排查此类问题时，首先应比较冷启动首次加载与 AOV 唤醒后再次加载的差异。首次加载正常而唤醒后加载异常，说明常规初始化流程基本可用，检查重点应转向低功耗期间丢失的硬件状态以及唤醒后的恢复流程。 第一步检查 AIC 时钟。AOV 休眠期间，实际 CPM 寄存器会被清零，但内存中的 clk->source->rate 仍保留休眠前的值。唤醒后执行 clk_set_rate 时，如果代码只比较目标频率与缓存频率，就会因为两者相同而直接返回。此时软件记录看似正确，硬件时钟实际上却没有重新配置，因此会出现 AIC 时钟异常、寄存器状态异常以及驱动加载卡死。 第二步检查音频传输通道。AIC 时钟恢复后，如果驱动可以加载但仍然无法取流，应继续检查 PDMA 是否已经随系统唤醒而恢复。音频数据传输依赖 PDMA，仅恢复 AIC 时钟不能使整个音频链路重新工作。 第三步检查 clk 引用计数。应沿驱动加载、录音、放音和卸载路径核对时钟使能与关闭操作。录音或放音路径重复使能对应 clk 时，count 会额外增加一次。驱动卸载后，如果 count 仍为 1，下一次加载检测到非零计数便会直接返回，不再执行真正的硬件时钟使能。根因 该问题由三处软件逻辑共同造成。首先，AOV 休眠清除了 CPM 寄存器状态，但内存仍保留旧的 clk->source->rate，导致唤醒后的 clk_set_rate 错误跳过 AIC 时钟重配。其次，唤醒流程没有恢复音频传输依赖的 PDMA，导致控制器时钟恢复后仍然无法传输音频数据。最后，录音或放音路径重复使能 clk，使引用计数与真实硬件状态不一致，驱动再次加载时因此跳过硬件时钟使能。分步修复 1. 修正 AIC 时钟重配逻辑 调整 AOV 唤醒后的时钟恢复逻辑。只要低功耗过程已经使 CPM 寄存器状态丢失，就不能仅依据内存中保存的 clk->source->rate 判断硬件已经处于目标频率。即使缓存频率与目标频率相同，也需要重新完成 AIC 时钟配置，使软件记录与硬件状态重新一致。 2. 在唤醒流程中恢复 PDMA 将音频传输依赖的 PDMA 纳入 AOV 唤醒恢复流程。AIC 时钟恢复负责重新建立音频控制器的工作条件，PDMA 恢复负责重新建立音频数据传输通道。两部分都正确恢复后，录音和放音链路才能正常取流。 3. 移除重复的 clk 使能 梳理音频驱动加载、录音、放音和卸载过程中的时钟生命周期，移除录音或放音路径中多余的 clk 使能操作，并确保每次有效使能都有对应的关闭操作。这样可以避免卸载驱动后残留 count=1，使下次加载能够执行真实的硬件时钟使能。验证结果与方法 完成三处修复后，AOV 唤醒后再次加载音频驱动时的卡死和 AIC 时钟异常得到解决，PDMA 恢复后音频无法取流的问题得到解决，移除重复 clk 使能后，驱动卸载再加载时也能够正常使能硬件时钟。 建议按照完整的状态转换顺序验证。先在上电状态加载音频驱动并确认录音或放音正常，再卸载驱动、进入 AOV、执行唤醒并重新加载驱动，观察加载过程能否完成以及 AIC 状态是否正常。随后执行录音或放音，确认音频流能够通过恢复后的 PDMA 正常传输。最后再次执行卸载和加载，检查 clk 引用计数是否随使能与关闭正确变化，并确认再次加载时不会跳过硬件时钟使能。还可以分别使用 UART0 连接并下拉、UART0 引脚悬空两种条件进行对照，以覆盖原有触发场景。实践注意事项• 低功耗过程可能使硬件寄存器状态丢失，而内存中的软件缓存仍保留旧值。唤醒恢复不能只依赖缓存值判断硬件是否已经完成配置。• 驱动能够完成加载并不代表音频链路已经全部恢复。AIC 时钟与 PDMA 承担不同职责，应结合实际录音或放音检查数据传输。• 修改 clk 逻辑时，建议同时检查加载、录音、放音、卸载和唤醒恢复路径，确保引用计数与真实硬件开关状态一致。• UART0 的连接与下拉状态可以作为复现对照条件，但不应替代对 AIC 时钟恢复、PDMA 恢复和 clk 引用计数的检查。• 对其他低功耗外设问题，也建议同时核对软件缓存、硬件寄存器、依赖模块和引用计数，避免只恢复单一模块后遗漏完整数据链路。
T33/T32Pro-Camera 强光场景出现发雾、鬼影和红斑，应该如何定位？
T33/T32Pro-Camera 强光场景出现发雾、鬼影和红斑，应该如何定位？导读太阳、路灯、车灯等强光源进入或靠近 Camera 视场时，画面可能出现发白、发雾、虚影、重复光斑、边角红光或花瓣状红斑。这些现象经常被统称为 Flare（眩光），但它们的形态、形成路径和改善方法并不完全相同。如果只把所有问题都归结为“镜头不好”，很难指导后续整改；如果一开始就调整曝光、对比度或其他 ISP 参数，又可能暂时掩盖现象，无法消除真正的反射路径。更有效的分析思路是： 先观察异常形态 ↓判断更像散射、杂散光还是界面反射 ↓通过光源位置和异常轨迹推测可能光路 ↓每次只改变一个光学件或结构变量 ↓找到主要贡献路径并完成 A/B 验证 本文基于五类典型现象，介绍 Flare 与 Ghost 的基础光学原理、定位实验和 ISP 的能力边界。原始资料没有提供具体模组、镜头、Cover Glass、IR Filter 和实测结构参数，因此文中的根因判断均作为排查方向，最终结论需要结合实物实验确认。 一、问题：强光场景下常见的五种异常1.1 画面发白、发雾，强光源看起来变粗 雾状眩光 这类现象常见表现是：• 画面像蒙了一层白雾；• 黑色区域被抬亮；• 全局或局部对比度下降；• 灯管、车灯等强光源周围形成较大的光晕，看起来“变胖”；• 强光源不一定必须完全进入画面，靠近视场边缘也可能触发。原始资料给出的优先方向是 镜头镀膜或镜筒反光。进一步排查时，还需要考虑镜片散射、表面脏污、视场外杂散光和结构消光等因素。1.2 点光源附近出现白色或蓝绿色虚影 Cover 反射鬼影 这类异常通常具有较明确的轮廓，可能表现为：• 点光源旁边出现另一个虚像；• 虚影呈白色、蓝绿色或其他镀膜相关颜色；• 移动光源时，虚影也按一定规律移动；• 在暗背景和夜间点光源场景下更加明显。原始资料建议优先检查 镜头前 Cover Glass 或镜头表面反射。但仅凭颜色和位置不能直接锁定具体界面，还要通过拆分和替换实验验证。1.3 画面出现多个重复光斑或重影 多重鬼影示意 如果画面中出现多个有规律的光斑、圆环或重复虚影，通常说明光线可能在多个光学表面之间发生了多次反射。原始资料给出的优先方向是 镜头内部镜片反射。实际项目中还可能涉及 Cover Glass、IR Filter、Sensor 保护玻璃等多个界面共同参与。1.4 画面边角出现红光 角落红光 边角发红往往与大角度入射光有关，原始资料建议优先检查 IR 滤光片。进一步还需要观察：• 是否只在特定视场角出现；• 红光是否随强光源角度移动；• 白天和夜间、不同 IRCUT 状态下是否有差异；• 更换或调整滤片后现象是否变化。1.5 画面中部出现花瓣状红色光斑 花瓣状红斑 这类红斑通常具有一定几何形态，不像普通污渍那样固定为模糊暗斑。原始资料给出的优先方向是 Sensor 与 IR 滤光片之间的反射。花瓣或多边形轮廓还可能携带光阑、镜片或反射光路的信息，但不能仅凭形状直接指定某个零件。仍应通过光源移动、器件替换和结构调整验证。1.6 先按形态建立初步方向画面现象优先考虑的方向仍需排除大面积发白、发雾、对比度下降镜头镀膜、镜筒反光、杂散光、散射脏污、水汽、过曝、HDR 异常点光源旁白色/蓝绿色虚影Cover Glass、镜头表面反射镜头内部反射、显示重影多个光斑、圆环或重影镜头多镜片表面、多界面反射Cover、IR Filter、Sensor 保护玻璃画面边角红光IR Filter、大角度入射路径IRCUT 状态、其他局部漏光中部花瓣状红斑Sensor 与 IR Filter 间反射光阑形态、镜头内部 Ghost这张表用于确定第一批实验，不代表现象和根因绝对一一对应。 二、分析：从杂散光、反射和散射理解 Flare2.1 正常成像光线与非预期光线理想情况下，场景中的光线经过镜头后，被正确聚焦到 Sensor 对应位置，形成清晰图像。但实际 Camera 模组包含多个光学和结构界面：场景光线 ↓前盖 / Cover Glass（如果有） ↓镜头外表面与多组内部镜片 ↓IRCUT / IR Filter ↓Sensor 保护玻璃和感光面 每个空气—玻璃、玻璃—镀膜或其他材料界面，都可能让一部分光透射、一部分光反射。镜筒内壁、固定结构、灰尘、划伤和表面污染还可能造成散射。正常聚焦之外，最终进入 Sensor 的非预期光线可以统称为杂散光。强光源能量很高，即使只有很小比例发生反射或散射，仍可能在画面中形成明显异常。2.2 Veiling Flare：像一层雾覆盖画面Veiling Flare 常表现为大面积亮度抬升和对比度下降。它不一定形成清晰虚像，更像一层附加光覆盖在真实图像上。形成路径可能包括：• 镜头表面散射；• 镜筒内壁反光；• 视场外强光经非成像路径进入 Sensor；• 灰尘、油污、水汽或划伤导致散射；• 镀膜效果不足或不适合当前光谱和入射角。当杂散光叠加到暗部时，黑色会变灰，局部细节被淹没。因此画面虽然可能没有明显重影，却会显得发白、发雾。2.3 Ghost：反射光形成的虚像Ghost 通常由两个或多个光学界面之间的反射形成。简化理解如下：强光进入镜头 ↓在某个表面发生一次反射 ↓又在另一个表面反射回来 ↓以非正常成像路径落到 Sensor ↓形成光源的虚像、光斑、圆环或几何图案 由于反射路径具有一定几何关系，Ghost 往往比 Veiling Flare 更有轮廓，也更可能随着光源移动而规律移动。多个镜片、Cover Glass、IR Filter 和 Sensor 保护玻璃都可能参与反射，因此画面上可能出现一个或多个 Ghost。2.4 为什么 Ghost 会有颜色？光学表面的反射率与波长、入射角和镀膜有关。某个反射路径如果对不同波长的透射和反射不同，Ghost 就可能呈现：• 蓝绿色；• 紫色；• 红色；• 黄白色；• 其他与光源本身不同的颜色。因此，Ghost 的颜色可以作为线索，但不能作为唯一判据。不同镜头、滤片、镀膜和入射角都可能改变颜色表现。2.5 为什么会出现圆形、环形、花瓣或多边形？Ghost 的形状可能受到以下因素影响：• 光源形状；• 镜片有效口径；• 光阑形状；• 镜片曲率；• 反射界面距离；• 离焦程度；• Sensor 微透镜或滤片结构；• 光线入射角。所以几何形态能够帮助判断光路，但形状相同不代表根因一定相同。2.6 为什么问题只在某个角度出现？Flare 和 Ghost 对入射角非常敏感。光源稍微移动，就可能让反射光：• 从 Sensor 范围外进入画面；• 从画面一角移到中部；• 从聚集光斑变为大面积发雾；• 被镜筒遮挡而消失；• 进入另一个反射路径。因此，“普通场景看不见”不能证明模组没有 Flare 问题。测试必须覆盖视场内、视场边缘和视场外的多个光源角度。 三、从异常形态寻找可能的光路3.1 大面积发白、发雾：先查散射和非成像杂散光如果主要表现为整体对比度下降，而没有明确虚影，应优先考虑：• 镜头前后表面是否有油污、灰尘、水汽或划伤；• 镜筒内壁是否有高反射区域；• 镜头镀膜是否满足当前光源和入射角；• Cover Glass 是否产生散射；• 视场外强光是否通过结构缝隙进入；• 模组内是否存在漏光路径。可以先清洁表面，再用遮光罩或黑色消光材料临时遮挡可疑路径。如果现象显著减轻，就能缩小范围。3.2 单个规则虚影：先寻找两界面反射点光源附近出现一个较清晰虚影时，可以观察：• 虚影位于光源同侧还是对侧；• 光源移动时虚影移动方向；• 虚影移动速度是否与光源一致；• 拆除或倾斜 Cover Glass 后是否变化；• 更换镜头后是否变化。如果某个光学件改变后，虚影位置、颜色或大小明显变化，该器件或其与其他表面的组合可能位于主要反射路径中。3.3 多个光斑：按界面数量和轨迹逐步拆分多个 Ghost 可能来自多组反射路径。不要试图仅靠一张图一次性猜出全部界面，可以：1. 固定 Camera；2. 让点光源按固定轨迹移动；3. 记录每个光斑的轨迹、大小和亮度；4. 逐个替换或移除可拆卸光学件；5. 比较哪些光斑消失、减弱或改变位置。不同光斑可能来自不同路径，某次结构修改只改善其中一部分是正常的。3.4 边角红光：关注大角度光线与 IR Filter当异常集中在边角，并带有明显红色时，可优先检查：• IR Filter 在大角度入射下的光谱表现；• 滤片是否倾斜、偏移或装配不平；• 镜头主光线角度与滤片是否匹配；• 滤片边缘是否存在漏光或反射；• IRCUT 在不同状态下现象是否变化。边角红光不一定都是滤片材料本身，也可能是滤片、镜头和结构共同形成的角度相关路径。3.5 花瓣状红斑：关注 Sensor 前方的近距离反射如果红斑位于画面中部，并呈花瓣、多边形或规则图案，可以优先验证：• IR Filter 与 Sensor 之间距离变化是否影响形态；• 滤片倾角变化是否让红斑移动或减弱；• 更换滤片后颜色和强度是否变化；• 更换镜头后图案是否仍然存在；• 光源移动时红斑是否按固定规律运动。这些实验能帮助判断异常更接近 Sensor/Filter 的短距离反射，还是来自镜头内部的其他界面。 四、解决：如何设计一组有效的定位实验？4.1 第一步：建立可重复的强光测试场景测试环境至少要记录：• 光源类型；• 光源亮度或驱动档位；• 光源与 Camera 的距离；• 水平和垂直入射角；• 光源在视场内、边缘还是视场外；• Camera 曝光时间、模拟增益和数字增益；• HDR、WDR 和局部色调映射状态；• 镜头、Cover、滤片和模组版本。如果光源位置和曝光每次都不同，就很难判断结构修改是否真正有效。4.2 第二步：固定曝光，避免 AE 干扰对比强光源移动时，AE 可能自动改变曝光，导致：• Flare 看起来突然变弱或变强；• 暗部亮度变化被误认为杂散光变化；• 两次结构对比失去相同基准。因此，在安全且平台支持的情况下，建议先锁定曝光和增益进行 A/B 对比，同时保存自动曝光场景作为实际效果参考。4.3 第三步：移动光源，记录异常轨迹保持 Camera 不动，让点光源沿固定方向缓慢移动，记录：• 光源位置；• Ghost 位置；• Ghost 移动方向和速度；• 光斑大小、形状和颜色；• Veiling Flare 覆盖范围；• 异常出现和消失的角度。相比一张静态截图，轨迹能提供更多光路信息。4.4 第四步：先做非破坏性检查建议先检查：• 镜头、Cover 和滤片表面是否清洁；• 是否有保护膜未撕；• 是否存在指纹、油污、水汽、胶水残留和划伤；• 镜筒、支架和螺丝附近是否有亮面；• 模组是否存在结构缝隙和漏光；• 镜头是否完全安装到位。清洁前后都要在相同条件下拍照，避免凭主观印象判断。4.5 第五步：遮挡可疑杂散光路径可以使用合适的遮光罩、黑色消光材料或临时遮挡结构，对视场外强光和可疑反射面进行隔离。注意：• 不要遮挡正常有效视场；• 不要让临时材料接触或损伤镜片和 Sensor；• 不要因材料掉屑引入新的脏污；• 每次只遮挡一个位置，并保存前后对比。如果遮挡某处后发雾显著减轻，说明该方向可能存在重要杂散光路径。4.6 第六步：依次替换光学件在条件允许时，按照容易拆分且风险较低的顺序进行 A/B 对比，例如：1. 正常样机与问题样机互换镜头；2. 对比有无 Cover Glass；3. 替换已知正常的 IR Filter 或 IRCUT；4. 对比不同模组或 Sensor；5. 调整可控的间距、倾角或装配状态。每次只改变一个变量，并保持光源、角度、曝光和 ISP 配置一致。如果更换镜头后问题随镜头迁移，应重点分析镜头；如果镜头不变而拆除 Cover 后某个 Ghost 消失，应重点分析 Cover 相关路径。4.7 第七步：验证整改是否覆盖完整角度某个角度下 Ghost 消失，并不代表整体性能一定改善。结构或倾角调整可能只是把 Ghost 移到了另一个视场位置。整改后应重新扫描：• 视场内多个位置；• 视场四周边缘；• 视场外多个角度；• 不同强度和色温的光源；• 白天太阳和夜间点光源场景；• 不同曝光和 HDR 模式。 五、进一步判断：看起来像 Flare，也可能是什么问题？5.1 Sensor 饱和与普通过曝强光源本身超过 Sensor 动态范围，会形成纯白区域和细节丢失。它与 Veiling Flare 的区别通常是：• 过曝主要集中在高亮区域；• Veiling Flare 还会抬升周围暗部、降低较大范围对比度；• 降低曝光后，高亮饱和可能缓解，但真实的反射 Ghost 仍可能存在。两者可以同时出现。5.2 Blooming、拖尾或 Sensor 相关异常某些强光异常可能表现为亮区向周围扩散、竖向或横向拖尾。它们更可能与 Sensor 饱和、电荷溢出或读出特性有关，而不是清晰的光学反射虚像。可以通过降低曝光、改变读出模式、对比 RAW 和更换 Sensor 模组进行区分。5.3 表面脏污、水汽和划伤脏污或水汽通常会显著增强散射，让点光源周围形成大光晕，画面整体发雾。与固定反射 Ghost 相比，它可能：• 形状更模糊；• 与污渍位置相关；• 清洁后明显改善；• 不一定呈现规则的镜像运动轨迹。清洁是重要的第一步，但清洁无效不能排除其他光学问题。5.4 HDR、WDR 或多帧融合异常HDR 合成或多帧处理可能在移动光源、相机抖动或曝光差异较大时产生重影。但这种重影通常与：• 帧间运动；• 多曝光合成；• 算法开关；• 时序和对齐误差有关。关闭相关算法或查看单帧 RAW/YUV 后，如果重影消失，应继续沿图像处理链路检查，而不是直接归因于镜头 Ghost。5.5 IRCUT 或 IR Filter 状态异常白天 IRCUT 未切到正确滤片，可能导致整体偏红、偏紫；IR Filter 的角度和光谱特性也可能影响边角红光。区分时可以观察：• 是全局颜色偏差，还是只在强光下出现局部红斑；• 强制切换 IRCUT 后，整体颜色和红斑是否同时变化；• 更换滤片后异常是否改变。5.6 编码或显示重影如果 RAW 和 ISP 输出没有虚影，而编码后或显示端出现重影，应检查：• 帧缓存；• 时域降噪；• 编码参考帧；• 显示刷新；• 多帧后处理。真正的光学 Ghost 通常已经存在于 RAW 或最早的 Sensor 输出中。5.7 快速对比问题类型主要特征验证方式Veiling Flare大范围亮度抬升、对比度下降移动光源、遮挡杂散光、清洁和替换镜头光学 Ghost规则虚影、光斑或几何图案记录轨迹、拆分 Cover/镜头/滤片普通过曝高亮区饱和，局部细节丢失降低曝光，观察非高亮区域是否恢复Sensor 拖尾/Blooming沿特定方向扩散或拖尾降曝光、换模式、查看 RAW脏污/水汽模糊光晕、散射增强清洁前后同条件对比HDR/多帧重影与运动和算法开关相关关闭 HDR/多帧，查看单帧输出IRCUT/IR Filter全局偏色或角度相关红光强制切换、替换或调整滤片编码/显示问题前级正常，后级才出现重影分层对比 RAW、YUV、编码和显示 六、ISP 能做什么，不能做什么？原始资料指出，这类问题大多由模组硬件光学结构导致，ISP 没有有效手段从根本上优化。这个方向是正确的，但可以进一步明确边界。6.1 ISP 可以减轻某些视觉表现根据平台能力，以下处理可能让画面“看起来好一些”：• 降低曝光，减轻高光饱和和光晕扩张；• 高光压缩或 Tone Mapping，改善强光区域显示；• 调整局部对比度，减轻轻微发雾感；• 优化 HDR 合成，减少算法重影；• 适当调整色彩，减轻局部色偏的视觉影响。这些方法通常是在现有输入上做取舍，可能同时牺牲暗部亮度、噪声、动态范围或颜色表现。6.2 ISP 无法恢复已经丢失的信息当杂散光叠加到 Sensor 上后：• 暗部对比度可能已经被物理性抬升；• 真实细节可能被强光和散射淹没；• Ghost 已经成为 RAW 中的额外虚像；• 饱和区域的信息已经丢失。ISP 无法知道某个亮斑中哪些光属于真实物体、哪些属于反射路径，也无法可靠还原被完全淹没或饱和的细节。因此，ISP 一般不能从根本上消除确定光学路径形成的 Ghost，也不能替代镜头镀膜、结构消光和滤片设计。6.3 根本改善通常在光学和结构端常见改善方向包括：• 选择更合适的镜头和镀膜；• 优化镜筒内壁消光；• 避免亮面结构暴露在强光路径中；• 优化 Cover Glass 镀膜、倾角和距离；• 优化 IR Filter 的光谱、镀膜、倾角和装配；• 降低 Sensor 前方多界面平行反射；• 增加遮光和防漏光结构；• 改善洁净度和装配一致性。具体方案需要结合成本、FOV、CRA、模组高度、可靠性和量产工艺评估，不能仅凭单张图片确定。 七、让问题更容易复现和定位7.1 建议记录的条件 问题样机和正常样机编号镜头型号与批次Cover Glass 版本IR Filter / IRCUT 版本Sensor 与模组版本光源类型、距离和亮度档位水平/垂直入射角光源在视场中的位置曝光、增益、HDR/WDR 状态ISP 参数版本异常形状、颜色、位置和强度 7.2 建议建立角度扫描矩阵光源位置水平角度垂直角度曝光异常类型位置/强度图片编号视场中心待填写待填写待填写待填写待填写待填写左侧边缘待填写待填写待填写待填写待填写待填写右侧边缘待填写待填写待填写待填写待填写待填写视场外左侧待填写待填写待填写待填写待填写待填写视场外右侧待填写待填写待填写待填写待填写待填写角度数据是否需要高精度，应根据项目阶段决定。早期定位至少要保证不同方案在相同位置和曝光下对比。7.3 每次只改变一个变量实验只改变的变量主要回答的问题A镜头主要反射或散射是否来自镜头？BCover Glass虚影是否与 Cover 相关？CIR Filter / IRCUT红斑和边角红光是否与滤片相关？D遮光/消光结构是否存在视场外杂散光路径？E光源角度异常轨迹是否符合光学反射特征？F曝光是真实光学异常还是单纯饱和放大？GHDR/WDR是否存在算法合成重影？H输出节点异常最早出现在哪个数据阶段？7.4 修改后必须做 A/B 和回归整改结论至少应包含：• 修改前后同条件图片；• 同一曝光下的强度对比；• 多角度扫描结果；• 是否引入新的 Ghost 位置；• 对清晰度、透过率、颜色和夜视的影响；• 不同样机和批次的一致性。只在一台样机、一个角度下改善，不足以证明方案适合量产。 八、常见误区误区 1：所有强光异常都叫镜头鬼影发雾、散射、单个 Ghost、多重 Ghost、局部红斑和 Sensor 饱和的形成机制不同，应先分类再定位。误区 2：根据光斑颜色直接指定某个镀膜或器件颜色与波长、镀膜、入射角和曝光有关，只能作为线索，不能替代拆分实验。误区 3：降低曝光后看不明显，就认为问题解决降低曝光可能只是让异常不易观察，反射路径仍然存在。需要在相同曝光下比较硬件方案。误区 4：只拍一张图就下结论Ghost 的移动轨迹、出现角度和结构替换结果，比单张截图更有定位价值。误区 5：一次同时更换镜头、Cover 和滤片多个变量同时改变后，即使问题消失，也无法知道真正起作用的是哪一项。误区 6：认为 ISP 可以完全消除光学 GhostISP 可以改善观感，但通常无法恢复被杂散光淹没的真实细节，也无法可靠分离 RAW 中已经形成的虚像。误区 7：某个角度改善就停止验证倾角或结构变化可能把 Ghost 从一个位置移动到另一个位置，必须重新扫描完整视场和视场外角度。 九、故障定位记录表编号检查项目结果1异常是发雾、虚影、光斑、红边还是红斑待填写2光源是否在视场内待填写3异常出现的水平/垂直角度待测量4降低曝光后现象如何变化待测试5锁定曝光后是否稳定复现待测试6镜头/Cover/滤片表面是否清洁待确认7是否存在保护膜、胶污、水汽或划伤待确认8遮挡视场外杂散光后是否改善待测试9光源移动时异常轨迹待记录10更换镜头后是否随镜头迁移待验证11移除/替换 Cover 后是否变化待验证12替换 IR Filter/IRCUT 后是否变化待验证13正常样机与问题样机差异待记录14RAW 中是否已经存在异常待验证15关闭 HDR/WDR 后是否仍存在待测试16修改后是否完成全角度回归待验证17是否引入清晰度、颜色或夜视副作用待验证18多台样机和批次是否一致待验证 十、结论Camera 在强光场景下出现发白、发雾、虚影、多个光斑、边角红光或花瓣状红斑，通常与非预期光线进入 Sensor 有关，但不同形态对应的主要路径可能不同：• 发白、发雾和对比度下降，更应关注散射、镜头镀膜、镜筒反光和视场外杂散光；• 白色或蓝绿色虚影，可优先检查 Cover Glass 和镜头表面反射；• 多个重复光斑，可能涉及镜头内部或多个光学界面的反射；• 边角红光，可优先检查 IR Filter 及大角度入射路径；• 花瓣状红斑，可优先验证 Sensor 与 IR Filter 之间的反射。这些对应关系是排查起点，不是最终结论。可靠定位需要固定光源、角度和曝光，记录异常轨迹，并通过遮挡、清洁、替换和结构 A/B 实验逐步拆分光路。推荐的排查顺序是：text 1. 先按形态区分发雾、Ghost、红边和红斑2. 固定光源、角度、曝光和结构版本3. 移动光源并记录异常轨迹4. 检查清洁度、保护膜、水汽、划伤和漏光5. 遮挡可疑视场外杂散光路径6. 依次替换镜头、Cover、IR Filter/IRCUT 和模组7. 对比 RAW、ISP 输出和最终画面8. 区分过曝、Sensor 饱和、HDR 和显示重影9. 完成多角度、多样机和多模式回归 一句话总结： Flare 定位的关键不是看到光斑就猜器件，而是观察形态和运动规律，再用单变量实验拆分反射、散射与杂散光路径；ISP 可以改善观感，但根本解决通常仍在光学和结构端。
T33-Linux 3.10 下 USB 4G 模组软重启后连接失败的 RX URB 回收修复
T33-Linux 3.10 下 USB 4G 模组软重启后连接失败的 RX URB 回收修复适用范围 本文适用于 T32 平台、Linux kernel 3.10 与 EC801 USB 4G 网卡模组组合中出现的断开及重连异常。典型触发条件是模组工作期间执行软重启。其他内核版本或 USB 网卡驱动的断开流程可能不同，应先核对接收队列和 URB 回收实现，再决定是否采用相同方案。问题现象 模组正常接入后，系统能够创建 usb0 网卡并完成网络通信。执行软重启时，网卡连接可能无法恢复。异常发生后，旧的 usb0 节点在断开阶段未被完整删除；模组重新启动并再次接入后，网卡也不能正常重建。这个特征表明故障发生在 USB 网卡断开和资源释放阶段，而不是单纯的拨号失败或网络参数错误。原因分析 模组软重启会触发 USB 设备断开。此时，网卡驱动的 rxq 接收队列中可能仍有尚未处理完的 skb。驱动对相应 URB 执行 unlink 后，URB 状态变为 -131，即 ECONNRESET。在发生问题的 Linux kernel 3.10 USB 驱动实现中，该状态下的 URB 未能顺利完成后续终止和回收，kill URB 流程因等待事件不能结束。由于 RX URB 回收被阻塞，USB 网卡的终止流程无法继续完成，usb0 节点及相关资源也不能彻底释放。模组再次接入时，旧连接遗留的状态影响网卡重建，最终表现为软重启后概率性连接失败。因此，排查重点应放在断开阶段的 rxq 和 RX URB 回收链路，而不能只观察模组重新枚举后的网络状态。修复方法1. 检查 USB 网卡驱动中是否存在为解决此问题而修改 urb done 路径的代码。如有此类改动，先回退该方向的修改，避免在完成回调中继续绕行处理。2. 在驱动中定位 usbnet_terminate_urbs，确认该函数对 dev->rxq 执行 unlink_urbs 的方式。3. 将 dev->rxq 的 URB unlink 调整为同步处理，使处于 -131（ECONNRESET） 状态的 RX URB 能够在设备断开期间完成终止和回收，不再长期阻塞于等待事件。4. 重新编译并部署修改后的内核或驱动，随后执行模组软重启测试。具体代码写法应与当前分支的函数接口、USB 休眠唤醒逻辑及资源释放顺序保持一致，不宜直接套用其他分支的实现。如果暂时无法更新驱动，可在软重启模组前先执行：sh ifconfig usb0 down 该命令会主动关闭网卡接口，可作为临时规避措施。它能够避免原故障再次出现，但不能替代对 RX URB 回收链路的修复。验证方法与结果 驱动修改后，应反复执行模组软重启，并检查以下完整链路：旧的 usb0 节点能够正常删除；RX URB 回收不再持续阻塞；模组重新接入后能够重新创建 usb0；网络通信能够恢复；持续业务负载下不再出现相同故障。 实际连续运行验证中，一套设备在修改后持续运行 3 天未出现异常，另一套设备持续运行一晚未出现异常。采用临时规避方式时，在模组重启前执行 ifconfig usb0 down，原连接失败现象也未再次出现。这些结果支持故障与 RX URB 回收阻塞有关，并支持在 usbnet_terminate_urbs 中同步处理 dev->rxq 的修复方向。由于现有记录未包含完整的软重启次数和更大规模的长期统计，部署到长期运行环境时仍应结合实际业务负载扩大循环重启和并发设备测试。注意事项 同步回收 dev->rxq 中的 RX URB 是针对根因的处理方式，重启前关闭 usb0 仅用于临时规避，两者不能混为一谈。修改范围应聚焦于 USB 网卡接收队列的终止与回收逻辑，不应把缺少独立验证的外围驱动调整列为必要步骤。移植到不同内核或驱动分支时，还应核对断开处理、休眠唤醒和 URB 生命周期管理，防止同步化调整破坏原有资源释放顺序。验证过程中建议保留 USB 断开、URB 终止、网卡节点删除和重新枚举日志，以确认故障确实消失在回收阶段，而不是被上层网络重试暂时掩盖。
T33T32Pro-高温后暗部噪声变多，怎么处理？
T33T32Pro-高温后暗部噪声变多，怎么处理？Q：设备运行一段时间后，低照度画面出现更多颗粒、暗部发灰，应该先查哪里？A：优先检查 Sensor 温度、曝光增益和黑电平补偿。温度升高会增加暗电流，让暗部噪声、异常亮点和黑位不纯更明显。一、问题现象：高温热噪通常现象表现二、问题产生原因温度升高后，Sensor 即使没有接收到光，也会产生更多额外电荷，称为暗电流。在弱光、高增益或长曝光下，这些额外电荷会和正常图像信号一起被放大。因此会出现三类变化：1. 暗部颗粒增多：随机噪声与色噪更明显；2. 黑位不稳定：不同温度下黑电平（OB/BLC）可能变化，暗部出现发灰、偏色或不均匀；3. 异常亮点更明显：部分热像素或固定异常点在高温、高增益下更容易暴露。三、解决问题的思路：先源头，后 ISP优先级处理方向目的1散热、导热、通风与模组温度从源头降低暗电流2曝光、模拟增益和 ISP 数字增益避免把热噪过度放大3按温度/增益补偿 BLC / OB改善暗部发灰、偏色与黑位不稳4DPC 校正异常亮点缓解热像素或固定异常点5时域/空域降噪改善剩余颗粒观感1. 先检查散热与工作温度• 模组是否紧贴热源；• 外壳、导热垫和散热片是否有效；• 密闭空间是否积热；• 长时间高帧率、高码率运行后是否明显恶化；• 可以咨询sensor原厂是否有sensor温度节点寄存器，通过读取sensor温度。对高温 BLC 漂移的问题建议：先尝试硬件降温或 Sensor 端设置，最后才由 ISP 处理。2. 硬件确认无法修改的情况下，软件可做如下调整第一步：确认需要调整的温度阈值，该值可通过读取sensor寄存器得到；第二步：区分常温、高温参数，通过上面温度阈值分别调用对应参数效果文件；第三步：在高温热噪明显情况下调整效果参数包含不仅限：多扣BLC、LSC强度置0、限制AE、降低饱和度、降暗处提亮强度、降锐化等，具体参数调整看实际效果表现确认高温参数。高温、长曝光和高增益叠加时，暗电流和读出噪声更容易被看见。应在亮度、拖影与噪声之间取平衡，避免不必要的过高数字增益。四、ISP优化实际表现，以及会牺牲画质点 实际项目高温热噪ISP弱化前后对比 高温后暗场画面对比：左为原始输出，四角暗部红紫彩噪明显；右为 ISP 弱化结果。严重热噪下，ISP 只能通过牺牲亮度、清晰度、色彩鲜艳度来降低噪声、发紫的观感，不能无损恢复已经被噪声淹没的纹理。快速判断观察到的现象优先检查升温后暗部整体发灰暗电流、BLC / OB 温度补偿固定坐标反复出现亮点热像素、坏点校正、DPC高增益时颗粒和色噪增加Sensor 噪声、增益策略、降噪强度运行越久画面越脏散热、模组温度、长期负载结论高温热噪的根本处理是降低 Sensor 温度、控制曝光与增益，并按温度做好 BLC / OB 补偿。ISP 可以弱化残留颗粒和异常亮点，但需要平衡弱纹理、反射层次和孔边细节的保留，不能替代散热和采集端优化。
T33/T32Pro-Camera 画面出现工频干扰水波纹怎么办？
T33/T32Pro-Camera 画面出现工频干扰水波纹怎么办？Q：室内拍摄时，画面出现一条条横向明暗带，并且在视频中不断向上或向下滚动，是什么原因？A：这通常是灯光闪烁频率与 Camera 曝光、帧率或逐行读出不同步造成的工频干扰，也常叫 Flicker、频闪条纹或水波纹。问题现象 正常与异常对比 左侧为正常画面，右侧墙面上可看到宽幅横向明暗带。静态异常示例 工频干扰水波纹 视频中的动态表现 工频水波纹动态滚动示例 动态示意中，横向明暗带会随帧向上或向下滚动。以上图片和 GIF 为基于实拍画面制作的现象演示。为什么会产生水波纹？1. 人眼看着常亮，灯光实际可能一直在闪市电交流频率一般为：• 中国及多数地区：50 Hz；• 部分国家和地区：60 Hz。很多 LED 灯、日光灯并不是完全稳定发光。灯具驱动如果整流和滤波不足，光强会随电网周期变化。50 Hz 交流电经过全波整流后，灯光亮度常以约 100 Hz 波动；60 Hz 电网下则常见约 120 Hz 光强波动。人眼通常感觉不到，但 Camera 能记录下来。2. Rolling Shutter 不是整帧同时曝光多数 CMOS Sensor 使用 Rolling Shutter，也就是从上到下逐行曝光和读出：text 第 1 行曝光时，灯光可能较亮第 100 行曝光时，灯光开始变暗第 300 行曝光时，灯光又变亮…… 同一帧内，不同行采集到的灯光亮度不一样，最后就会形成横向的明暗条带。3. 为什么视频里的条纹会移动？灯光闪烁周期、Sensor 行扫描时间和视频帧率通常不会完全同步。每一帧开始曝光时，灯光所处的亮暗相位都会有一点变化，因此条带位置会逐帧变化，看起来就像水波一样向上或向下滚动。滚动方向和速度会受以下因素影响：• 帧率；• 曝光时间；• Sensor 行读出时间；• 灯具闪烁频率；• LED 驱动电源质量。4. 为什么有时是宽条，有时是细条？条带宽度不是固定的，主要与灯光闪烁频率和 Sensor 行扫描速度有关：• 灯光变化较慢、行扫描较快：可能看到较宽的明暗带；• 灯光 PWM 频率较高、行扫描较慢：可能出现较密的细条；• 曝光时间较长：多个亮暗周期被平均，条带可能减轻；• 曝光时间较短：更容易把瞬时亮度变化记录下来，条带更明显。哪些场景容易出现？• LED 灯、日光灯照明的室内场景；• 低成本 LED 驱动或灯具老化；• LED 广告屏、显示器、灯箱；• 高帧率或短曝光拍摄；• 夜间增益较高的监控场景；• Camera 的 Anti-flicker 配置与当地电网频率不一致。怎么判断是不是工频干扰？现象工频干扰的典型表现条纹方向通常为横向明暗带视频表现条带会上下滚动或闪烁场景关系在白墙、灰卡等均匀区域最明显光源关系更换灯具或关闭室内灯后明显变化参数关系调整曝光、帧率或 Anti-flicker 后会变化常见优化方法1. 设置正确的 Anti-flicker根据当地电网频率选择：• 50 Hz 地区：选择 50 Hz Anti-flicker；• 60 Hz 地区：选择 60 Hz Anti-flicker。不要把 50 Hz 环境设置成 60 Hz，否则条纹通常不能稳定抑制。2. 限制曝光时间可消除水波纹保证sensor曝光时间为灯光能量周期的整数倍，即Exp time = TN T=(1/Fre)(1/2)，能量周期为期波形周期的1/2，例如：50Hz环境下，T=10msExp_time为时间单位，要换算为row_time单位。 row_time = hts/pclk 不同sensor，不同配置，计算得出的row_time可能不一致。 Exp_time=Nsteprow_time 此处的step便是能消除水波纹所需要的最小曝光步长。API：IMP_ISP_Tuning_SetAntiFlickerAttr(IMPVI_NUM num, IMPISPAntiflickerAttr *pattr)注意：ANTIFLICKER_NORMAL_MODE 最小曝光会限制到1个step，这样户外必然过曝严重，慎用；建议使用ANTIFLICKER_AUTO_MODE 这样不会有过曝的风险，在高亮环境的水波纹可以用下面方法固定住水波纹。3. 控制帧间隔可固定水波纹不滚动上面提到，完全消除水波纹的话，需要至少1step的曝光时间。当环境亮度足够，且存在工频干扰，此时sensor不需要1step的曝光便能达到AE设定的目标亮度。在这种环境下，水波纹是无法消除的，但是可以固定住。既然无法满足每行（每个pixel）在相同曝光时间段内能积累同样的光能，就无法避免的会出现成像画面中会出现纵向明暗变化的横条。但是，可以把每行的曝光起始点固定住，即让其在不同帧时的曝光起始点固定在能量波型的同一个相位上。这样便可以把水波纹固定住。满足 1/fps=T*N 即可。结论室内画面出现会滚动的横向宽幅明暗带，优先检查灯光频闪、Anti-flicker、曝光时间和帧率。
T33/T32Pro-如何快速判断问题出在 Sensor、ISP 还是编码端？
T33/T32Pro-如何快速判断问题出在 Sensor、ISP 还是编码端？Q：摄像头画面出现偏色、噪点、条纹、模糊或马赛克时，怎样快速定位是哪一层的问题？A：依次对比 RAW、ISP 输出 YUV、编码后码流。问题第一次出现在哪一级，就优先检查哪一级。 RAW、YUV、码流三级定位流程RAW、YUV 怎么抓取？方法一：使用 Tiziano 动态调试工具设备连接动态工具后，在 TOP 页面操作：• 点击 GNV12：抓取 ISP 输出的 NV12 图，选择路径和文件名后保存；• 点击 GRaw：抓取 Sensor RAW，选择路径和文件名后保存；• 如果 RAW 无法正常抓取，可进入 RawCfg 检查抓图内存方式。方法二：通过板端命令抓取 RAW、YUV选择 RAW 抓取模式支持 3 种内存模式：模式内存来源适用模式特点mode 0malloc 动态分配线性、WDR不需要预留内存，但可能因系统内存不足而失败mode 1ispmem 预留内存线性、WDR稳定可靠，但需要在 cmdline 中预留 ispmemmode 2MDNS 缓存线性、WDR不需要额外分配内存；WDR 会分别抓出长帧和短帧模式配置命令： # 按需要将 0 改为 1 或 2echo "mode 0" > /proc/jz/isp/isp-w02 模式可以不配置，系统默认采用 mode 2。使用 mode 1 时，需要在 cmdline 中预留足够的 ispmem。可按下面的值估算最小空间： ispmem ≥ 图像宽 × 图像高 × 2 字节 × 实际输出帧数 例如一帧 500 万像素 RAW 约为 9.54 MiB，通常至少预留约 9～10 MB。WDR 会输出长、短两帧，计算内存时还要考虑帧数翻倍。执行 RAW 抓取命令格式： # snapraw <vinum> <抓取帧数>echo "snapraw 0 1" > /proc/jz/isp/isp-w02 参数含义：• 第一个数字是 vinum：0 表示主摄，1 表示次摄；• 第二个数字是需要抓取的帧数；• 在线性模式下，snapraw 0 1 抓取主摄 1 帧 RAW；• 在 WDR 模式下，长帧和短帧会分别输出，因此实际文件数量是设置帧数的 2 倍。proc 节点、输出文件名和保存位置可能随芯片平台、驱动版本变化。若节点不存在或命令返回错误，应以当前项目的软件说明为准。通过板端命令抓取 NV12板端抓取方式需要先区分 ISP 是否为直通模式。非直通模式通过在 /tmp/mountdir/ 下创建指定文件触发抓图： # ISP 处理后的 NV12touch /tmp/mountdir/ispsnap0.nv12 # 主码流touch /tmp/mountdir/ispsnap1.nv12 # 次码流 # 编码通路的 NV12，通常用于检查编码器输入帧touch /tmp/mountdir/encsnap0.nv12 # 主码流touch /tmp/mountdir/encsnap1.nv12 # 次码流 # OSD 叠加后的 NV12touch /tmp/mountdir/osdsnap0.nv12 # 主码流touch /tmp/mountdir/osdsnap1.nv12 # 次码流 直通模式主码流通过 isp-ivdc 节点触发： echo snapyuv > /proc/jz/isp/isp-ivdc 直通模式下，次码流仍使用非直通模式的文件触发方式，根据需要创建： touch /tmp/mountdir/ispsnap1.nv12 抓取点主码流次码流用途ISP 处理后ispsnap0.nv12ispsnap1.nv12判断 ISP 输出是否已经异常编码通路encsnap0.nv12encsnap1.nv12检查送入编码链路的 NV12 是否正常OSD 叠加后osdsnap0.nv12osdsnap1.nv12判断异常是否由 OSD 叠加引入encsnap*.nv12 仍是 NV12 原始帧，不是 H.264/H.265 压缩码流。判断编码器是否产生块效应、花屏等问题，还需要继续抓取并解码实际码流进行比较。文件触发路径、输出位置和 proc 节点可能随产品软件版本变化。使用前应确认 /tmp/mountdir/ 可写、相关进程正在运行，并以当前项目说明为准。第一步：先看 RAWRAW 是进入 ISP 前的原始采集数据。• RAW 已经异常：优先检查 Sensor 和采集前端；• RAW 正常：继续检查 ISP 输出 YUV。RAW 异常时，常见检查方向包括：• 镜头、Sensor 本体；• Sensor 供电、时钟和复位；• MIPI 时序、Lane 配置和传输稳定性；• 曝光、模拟增益、帧率及 Sensor 寄存器；• RAW 位宽、Bayer 排列、尺寸和抓图方式。这里的“Sensor 端”是采集前端的统称，不代表一定是 Sensor 芯片损坏。第二步：再看 ISP 输出 YUV如果 RAW 正常，但 NV12、NV21 等 YUV 图已经异常，问题优先位于 ISP。常见检查方向包括：• BLC、DPC、LSC；• 去马赛克、AWB、CCM、Gamma；• 降噪、锐化、色彩和宽动态处理；• 模块开关、参数及数据格式配置。Tiziano 动态调试工具可以在同一链路抓取 RAW 和 NV12/NV21，适合直接进行前后对比。第三步：最后看编码后码流如果编码前 YUV 正常，但 H.264/H.265 码流解码后的画面异常，优先检查编码或传输链路。常见检查方向包括：• 码率是否过低；• GOP、QP、帧率配置；• 编码分辨率、stride 和像素格式；• I 帧、P 帧参考关系；• 码流丢包、缺帧或数据损坏。如果换一个解码器后恢复正常，或者解码出的帧正常、只有某个播放器显示异常，则应继续检查解码器、播放器或显示链路，而不是直接归因于编码器。快速判断表对比结果优先检查层面RAW 已异常Sensor / 镜头 / 供电 / 时钟 / MIPI / Sensor 配置RAW 正常，YUV 异常ISP 模块和参数YUV 正常，码流解码帧异常编码器或码流传输解码帧正常，只有播放器异常解码、播放器或显示端常见现象参考现象优先检查RAW 就有固定坏点、行列条纹Sensor、供电、时钟、MIPIRAW 正常，YUV 出现偏色或过度锐化ISP静止画面正常，运动时出现拖影ISP 时域降噪或编码参考帧，需通过 YUV 对比区分YUV 正常，码流出现块效应码率、QP、编码器码流偶发绿屏、花屏或半屏丢包、码流损坏、解码或格式配置避免误判1. 使用同一场景、相同曝光条件抓取数据；2. 尽量抓取同一帧，或根据时间戳对齐 RAW、YUV 和码流帧；3. RAW 必须按正确的分辨率、位宽和 Bayer 排列解析；4. YUV 必须确认 NV12/NV21、stride 和色彩范围配置正确；5. 编码问题要看解码后的原始帧，不要只看一个播放器窗口。结论RAW 异常，先查 Sensor 和采集前端；RAW 正常但 YUV 异常，先查 ISP；YUV 正常但码流解码帧异常，先查编码和传输。不要只看最终预览画面定责。沿着 RAW → YUV → 码流逐级对比，通常可以最快缩小问题范围。
T33-录音异常（16k 改 48k 后声音异常）：特定 CPU/DDR 频率组合的时钟问题
T33-录音异常（16k 改 48k 后声音异常）：特定 CPU/DDR 频率组合的时钟问题适用场景 设备在特定 CPU 主频 / DDR 频率组合下，音频录音采样率从 16k 切换到 48k 后出现声音异常。本文适用于排查这类「与频率配置强相关」的音频采样异常。问题现象 T33L 设备音频 16k 录音正常，改为 48k 录音后声音异常。根因分析 问题与 CPU 主频 / DDR 频率组合强相关： • 默认配置 CPU 891 / DDR 700：录音无问题； • 改为 CPU 950 / DDR 650：可复现录音异常。 根因在音频采样时钟（PLL/分频）在该频率组合下配置异常，导致 48k 采样率下音频数据异常。这类问题常被误判为音频驱动或 codec 问题，实际与平台时钟树/频率配置有关。排查与修复方法 第一步，锁定频率相关性。对比不同 CPU/DDR 频率组合下的录音表现，确认是否与频率配置相关。 第二步，检查音频时钟配置。核对音频采样时钟（PLL/分频）在目标频率组合下的配置是否正确。 第三步，修复时钟/采样相关代码。调整音频时钟分频或相关配置，使 48k 采样在该频率组合下正确。 第四步，验证。在问题频率组合下，测试 16k→48k 切换及纯 48k 录音，确认声音正常，并回归默认频率组合。验证结果 本地已复现并解决，相关代码入库，本地测试无问题。使用建议 排查音频采样异常时，若默认配置正常、特定频率组合异常，优先检查音频时钟与 CPU/DDR 频率的联动配置，而非直接怀疑 codec 或驱动逻辑。备注 根因到「CPU 950 + DDR 650 频率组合」层，具体音频时钟/PLL 分频机制材料未给出，需音频/BSP 经办人补充。
T33-AOV 双摄拼接 resume 断流：Sensor 休眠唤醒 streamon/off 重复执行
T33-AOV 双摄拼接 resume 断流：Sensor 休眠唤醒 streamon/off 重复执行适用场景 采用双摄拼接的 AOV（低功耗）方案，在休眠唤醒（resume）后出现断流。本文适用于排查「唤醒后拼接通路断流」类问题，重点提示 Sensor 休眠唤醒时 streamon/streamoff 的执行次数。问题现象T33 AOV 双摄拼接方案，在 resume（休眠唤醒）时出现断流；正常出流与休眠阶段无异常，问题集中在唤醒恢复时刻。根因分析 断流根因是 Sensor 休眠唤醒时 streamon/streamoff 都执行了两次。唤醒恢复流程本应对 Sensor 各执行一次 streamon（开启出流），重复执行会导致 Sensor 出流状态机异常，进而使双摄拼接通路在唤醒后断流。这类问题容易与拼接算法、sensor 驱动本身混淆，实际根因在唤醒流程对 streamon/off 的调用次数。排查与修复方法 第一步，确认问题只在 resume 后出现。对比休眠前、唤醒后的出流状态，锁定为唤醒恢复问题。 第二步，检查唤醒流程中 streamon/streamoff 的调用次数。排查是否在唤醒路径中重复调用了 streamon/streamoff。 第三步，将重复调用改为单次。确保 Sensor 休眠唤醒时 streamon/off 各执行一次。 第四步，准备兜底方案。可在应用层加 oneshottick 逻辑作为兜底。 第五步，挂机验证。多台设备长时间挂机，确认唤醒后不再断流。验证结果 修改后 5 台设备挂机 1 天 16 小时未复现断流；后续客户继续观察一段时间未复现，问题挂起处理。使用建议 排查 AOV 双摄拼接「唤醒后断流」，应优先核对休眠唤醒流程中 Sensor streamon/streamoff 的调用次数，以及是否存在重复开关流；多台挂机是验证「唤醒必现/概率复现」问题的有效手段。
Camera 画面偏红、偏紫怎么查？——从 IRCUT 未切换到多原因定位
Camera 画面偏红、偏紫怎么查？——从 IRCUT 未切换到多原因定位导读：先回答三个问题Camera 画面偏红、偏紫，很多人第一反应是调 ISP 的 R/G/B 增益、AWB 或 CCM。但在带红外夜视功能的 Camera 模组中，IRCUT 是否真正切换到正确位置，往往应该是最先确认的事项。本文按照下面的思路展开：text 问题：画面到底出现了什么现象？ ↓分析：光学、硬件、Sensor 和 ISP 哪一层可能导致偏色？ ↓解决：如何设计最小成本的验证实验并修复？ ↓进一步判断：如果不是 IRCUT，还可能是哪一种问题？如何区分？ 核心原则： 先确认进入 Sensor 的光学条件和 RAW 数据是否正确，再调整 ISP。不要用 ISP 参数去掩盖 IRCUT 机构、滤片装配或控制时序问题。本文使用的原始资料没有提供具体芯片、Sensor、IRCUT、开发板、GPIO 和 SDK 信息。因此，文中的 GPIO、电压、动作时间和寄存器配置均不写死，具体平台需要以硬件资料和实测结果为准。 一、问题：画面偏红、偏紫时，先观察什么？1.1 典型现象需要重点关注以下表现：• 白天画面整体偏红、偏紫或偏红紫；• 对着窗户、室外或自然光时，偏色明显加重；• 白色、灰色和黑色物体的颜色还原异常；• 日夜状态已经切换，但画面颜色没有随之恢复；• 同一套 ISP 参数在室内看起来正常，换到自然光下又异常；• 手动推动或强制控制 IRCUT 后，画面颜色发生明显变化。这些现象可以帮助我们建立方向，但仅凭一张图片不能直接证明根因。偏红、偏紫可能来自 IRCUT，也可能来自 Bayer Pattern、Sensor 数据链路、ISP 参数、镜头或显示后处理。1.2 原始资料中的现象对比IRCUT 红片状态示例 IRCUT 红片正常图 IRCUT 白片状态下的偏紫示例 IRCUT 白片偏紫图 原始技术资料的结论是：IRCUT 没有切到红片、切换位置不准、机构卡住/偏移/松动，或者红片/白片装配异常，都可能导致画面偏紫或偏红紫。1.3 先做三个快速判断判断一：问题是否只在白天或自然光下明显？如果室内普通光源下不明显，而窗边、室外或自然光下加重，应优先关注滤片状态和光学路径。判断二：强制切换 IRCUT 后，画面是否变化？在光源、曝光和 ISP 参数尽量不变时，分别采集红片和白片状态的画面：• 红片正常、白片偏紫：优先检查白天是否误停在白片位置；• 软件状态变化但画面不变化：检查机构是否实际动作、控制极性和驱动链路；• 两个状态都没有明显变化：先确认 IRCUT 是否被真正驱动，也要考虑测试光源差异不足；• 两个状态都异常：不要继续只盯着 IRCUT，应扩大排查范围。判断三：问题是“切换后出现”，还是“从启动就存在”？• 日夜切换后出现： 优先查 IRCUT、切换时序、ISP Profile 同步；• 从启动开始一直异常： 同时检查 Bayer Pattern、Sensor 数据格式、镜头/滤片装配和基础 ISP 配置；• 只在最终显示画面异常： 还要检查 YUV/RGB、色彩空间、编码和显示链路。 二、分析：从基础光学理解 IRCUT 为什么影响颜色2.1 光从哪里到哪里？可以把 Camera 成像链路简化为： 场景光线 ↓镜头 ↓IRCUT / 其他光学滤片 ↓Sensor 感光面 ↓RAW Bayer 数据 ↓ISP：AE、AWB、去噪、CCM、Gamma 等 ↓YUV/RGB、编码或显示 偏色可能在这条链路的任何一层产生。因此，排查时不能只看最终画面，还要尽可能判断偏色最早在哪一层出现。2.2 可见光和近红外光人眼主要感知可见光，而 Camera Sensor 通常还会对一定范围的近红外光产生响应。自然光和一些人工光源中都可能包含近红外成分，只是比例不同。如果白天没有正确过滤近红外光，Sensor 接收到的光谱就与正常白天状态不同。由于 Sensor 的 R、G、B 感光响应并不完全相同，光谱变化会改变三个颜色通道的相对比例，最终可能表现为：• 红色增强；• 紫色或品红倾向；• 白色物体无法还原为中性白；• AWB 在不同光源下表现不稳定。可以用下面的关系理解： 滤片状态改变 ↓进入 Sensor 的光谱改变 ↓R/G/B 通道响应比例改变 ↓RAW 或 ISP 统计值发生变化 ↓最终画面出现偏色 这里讲的是通用原理，不等于对所有设备的颜色方向作绝对保证。最终偏红还是偏紫，还与 Sensor 光谱响应、镜头、滤片特性、AWB 和 ISP 配置有关。2.3 IRCUT、红片和白片是什么？带红外夜视功能的 Camera 通常在白天和夜间使用两种不同的光学状态：状态常见滤片称呼主要目的白天红片、IR-CUT 片过滤近红外成分，改善可见光颜色还原夜间白片、透光片放行更多光线，配合红外灯提升夜视能力本文沿用原始资料中的“红片”“白片”叫法。但不同厂家可能使用不同的外观、命名和控制逻辑，不能仅凭颜色名称推断功能，也不能直接推断 GPIO 高低电平。工程上真正需要确认的是： 当前实际进入 Sensor 的光学状态是什么？软件目标状态和机械实际位置是否一致？当前 ISP Profile 是否与该光学状态匹配？ 2.4 为什么不能先调 ISP？AWB、CCM 和颜色增益是在某种光学条件下工作的。如果 IRCUT 没切到位，进入 Sensor 的光谱已经改变，ISP 看到的是一个与预期不同的输入。此时强行调参数可能出现：• 一个固定场景下暂时正常；• 换光源后再次偏色；• 日夜切换后颜色跳变；• AWB 增益达到异常范围；• 同一套参数在不同模组上表现不一致。所以正确顺序应该是： 先确认光学状态 ↓再确认 RAW、Sensor 和数据格式 ↓再确认 ISP Profile、AWB 和 CCM ↓最后做参数微调 三、解决：如何一步一步定位 IRCUT 问题？3.1 第一步：固定测试条件为了避免 AE/AWB 自动变化干扰判断，尽量固定：• Camera 模组和镜头；• 测试目标和光源；• 曝光、模拟增益和数字增益；• AWB 状态；• 日夜模式；• ISP Profile；• 录像或抓帧方式。建议至少准备：1. 室内均匀光源；2. 窗边或室外自然光；3. 白色纸张；4. 灰色或黑色目标；5. 条件允许时，增加红外反射明显的目标。每次只改变一个主要变量，避免同时切换 IRCUT、ISP Profile、曝光和 AWB，导致实验结果无法解释。3.2 第二步：记录软件状态和实际状态建议把以下信息记录下来：项目记录内容软件日夜状态白天/夜间/未知目标 IRCUT 状态红片/白片/未知实际滤片位置红片/白片/中间/未确认控制输出按实际平台填写机构动作正常/无动作/卡顿/未确认画面现象正常/偏红/偏紫等ISP Profile名称、版本和加载时间AE/AWB自动、锁定及统计值结果是否可复现这里最重要的一点是：软件打印“白天”不等于 IRCUT 已经物理切到红片；软件发送了命令也不等于机构已经到位。3.3 第三步：强制对比红片和白片先不要依赖完整的自动日夜流程，而是使用已有调试接口、驱动接口或受控硬件手段，分别让 IRCUT 进入两个状态： 目标状态 A：红片等待机构稳定采集画面和日志 目标状态 B：白片等待机构稳定采集画面和日志 对比时观察：• 机构是否动作；• 是否到达机械终点；• 画面亮度是否变化；• 颜色是否变化；• 目标状态和实际位置是否一致。不要在没有原理图或规格书的情况下直接断言“GPIO 高电平就是红片”。控制极性应由硬件定义和实测共同确认。3.4 第四步：检查机械和装配原始资料列出的常见机械原因包括：1. IRCUT 没有切到红片；2. 切换位置不准；3. 机构卡住、偏移或松动；4. 红片/白片装配异常。进一步检查：• 滤片是否完整移动到限位；• 电机是否只有声音而没有到位；• 机构是否回弹；• 镜头座、支架或螺丝是否挤压机构；• 红片和白片是否装反或位置异常；• 连接器和排线是否松动。如果手动将滤片调整到红片位置后画面恢复，说明应优先沿 IRCUT 机构、装配、驱动和供电方向继续排查，而不是先改 CCM。3.5 第五步：检查 GPIO、驱动和供电在硬件允许并具备测量条件时，检查：• GPIO 是否初始化成功；• GPIO 方向是否正确；• 控制极性是否符合原理图；• 两路控制是否同时处于冲突状态；• 驱动芯片输入和输出是否符合预期；• IRCUT 动作期间供电是否稳定；• 连接器、排线和地线是否可靠；• 控制命令是否被其他模块覆盖。当前资料没有提供具体 GPIO、驱动芯片、电压和动作波形，因此这些值必须由项目资料或实测补充。3.6 第六步：检查日夜切换时序一个完整的切换过程通常类似： 检测亮度 ↓确定目标日夜状态 ↓控制 IRCUT ↓等待机构到位并稳定 ↓切换 Sensor/ISP 配置 ↓丢弃过渡帧 ↓等待 AE/AWB 稳定 如果 ISP Profile 在 IRCUT 到位前就切换，可能出现：• 切换过程画面短暂偏色；• 切换后持续偏色；• 机构还在动作但 ISP 已按新状态工作；• 日夜状态反复跳变；• GPIO 命令被下一次状态更新覆盖。建议增加：亮度滞回、连续多帧确认、最小状态保持时间、切换锁、动作超时和异常告警。实际等待时间应以器件规格和实测为准。3.7 第七步：确认修复结果修复后不能只看一张“正常截图”，至少要重复验证：• 室内均匀光源；• 窗边或室外自然光；• 白天到夜间切换；• 夜间到白天切换；• 多次重复切换；• 冷启动和热启动；• 不同亮度临界条件。建议保存：画面、切换日志、软件状态、实际位置确认、ISP Profile、AE/AWB 统计和版本信息。 四、进一步判断：偏红、偏紫还可能是什么原因？4.1 先建立候选原因树最终画面偏红或偏紫，可能来自以下层级： 光学层：IRCUT 状态、滤片装配、镜头和反射 ↓机械/电气层：机构卡滞、GPIO、驱动、供电 ↓Sensor/数据层：Sensor 配置、RAW 格式、Bayer Pattern ↓ISP 层：AWB、CCM、R/G/B 增益、日夜 Profile ↓输出层：YUV/RGB、色彩空间、编码、显示和后处理 排查的关键不是列出尽可能多的原因，而是设计实验，判断偏色最早出现在哪一层。4.2 IRCUT 未切换与其他问题的对比候选原因典型表现常见触发时机优先验证方法IRCUT 未切到红片白天偏红/偏紫，自然光下加重日夜切换后或白天强制切换并确认实际滤片位置IRCUT 机构不到位偶发、状态不稳定、重复切换结果不同机构动作时观察机械位置、动作时间和供电红片/白片装配异常更换或拆装后异常，状态与预期不符装配后一直存在与正常模组对比、确认滤片位置Bayer Pattern 错误红蓝关系明显错误，可能整体偏紫或伴随条纹上电出图即存在核对 Sensor 输出和 ISP Bayer 配置Sensor 数据格式错误颜色和图像结构同时异常Sensor/驱动配置变更后抓 RAW，核对 mbus code、位宽和格式AWB 异常颜色随场景变化，收敛慢或增益极端光源变化、模式切换后锁定 AWB，观察统计值和 R/G、B/G 增益CCM/Profile 错误整体色调固定异常，换参数后变化ISP 参数加载后确认 Profile、CCM 版本和实际生效寄存器镜头/滤片反射或光学问题局部红斑、鬼影、边角异常强光源或特定角度改变光源角度、替换镜头/模组显示/后处理问题RAW/ISP 输出正常，最终画面异常编码、显示或后处理后对比 RAW、YUV/RGB 和显示结果表中的“典型表现”只是定位线索，不是绝对判据，最终仍需实验确认。4.3 如何区分 Bayer Pattern 错误？Bayer Pattern 不匹配时，Sensor 实际输出顺序与 ISP 解码配置不一致。例如实际输出和 ISP 配置使用了不同的 RGGB、BGGR、GRBG 或 GBRG 顺序，可能产生：• 红蓝关系明显错误；• 整体异常偏紫；• 颜色区域伴随条纹噪声；• 从设备开始出图就异常；• 强制切换 IRCUT 对红蓝关系没有根本影响。因此： 从启动开始持续反色/偏紫 → 优先核对 Bayer Pattern 和 RAW 数据格式 日夜切换后才偏色，且改变滤片位置会改变画面 → 优先检查 IRCUT 和切换时序 这两种问题也可能同时存在，不能只凭一个现象排除另一种可能。4.4 如何区分 AWB/CCM 问题？可以尝试在平台支持的情况下固定 AE、增益和 AWB：• 固定后偏色仍随滤片位置变化：优先关注光学路径和 IRCUT；• 固定后颜色稳定但整体色调仍固定错误：检查 CCM、颜色增益和 Profile；• AWB 增益达到极端值且随光源变化：检查输入光谱、AWB 统计区域和算法配置；• 日夜切换时 Profile 与滤片状态不一致：先修正状态同步，再讨论调参。不能把“调到某个场景正常”当作根因已经解决。应验证多个光源和多个场景。4.5 如何用 RAW 和分层输出定位？如果平台支持，建议同时保存：• RAW Bayer 数据；• ISP 输出的 YUV/RGB；• AWB/AE 统计值；• 日夜状态和 IRCUT 控制日志；• 最终显示或编码后的画面。可以按下面的逻辑判断： RAW 已经偏色 → 优先查 IRCUT、镜头、滤片、Sensor 和模拟链路 RAW 颜色关系正常，ISP 输出异常 → 优先查 Bayer 解码、AWB、CCM、Profile 和 ISP 配置 ISP 输出正常，最终显示异常 → 优先查色彩空间、编码、显示和后处理链路 这里的“RAW 正常”需要有合适的参考物和对比条件，不能仅凭肉眼查看一张未经处理的 RAW 图像下结论。4.6 用“只改变一个变量”的实验建立证据链进一步定位最重要的不是一次性检查所有项目，而是控制变量：实验只改变的变量可以回答的问题AIRCUT 状态颜色是否与滤片状态相关？BISP Profile是否是日夜参数不匹配？CAWB 开关/锁定状态是否是自动白平衡放大了问题？D镜头或 IRCUT 模组是否是光学件或机构问题？EBayer 配置是否是 RAW 解码顺序错误？F输出链路偏色最早出现在哪个数据节点？每次实验都记录：输入条件、唯一变量、输出画面、日志和结论。这样才能从“猜原因”变成“用证据排原因”。 五、让问题更容易复现和定位5.1 建立三层 IRCUT 状态不要只维护一个 day/night 变量，建议分别记录： 目标状态：系统希望 IRCUT 处于什么位置控制状态：当前输出了什么 GPIO 或驱动命令实际状态：机构实际到达了什么位置，或当前是否未知 例如： 目标状态：DAY_FILTER控制命令：已发送机构反馈：无实际状态：未知 这比直接打印“切换到白天成功”更准确。5.2 建议增加的日志 环境亮度和日夜判定结果目标 IRCUT 状态控制输出命令发送时间机构稳定时间动作耗时实际或推断位置当前 ISP ProfileSensor 模式AE/AWB 状态切换超时次数重复切换次数 示例： [IRCUT] target=DAY_FILTER[IRCUT] control_output=[IRCUT] command_sent[IRCUT] settle_done[ISP] profile=DAY[AWB] state= 只是占位符，不能直接作为实际 GPIO 或状态值使用。5.3 日夜状态机要防抖和防重入临界光照下，亮度可能在阈值附近波动，导致： 白天 → 夜间 → 白天 → 夜间 建议至少加入：• 白天/夜间不同阈值的滞回；• 连续多帧确认；• 最小状态保持时间；• 切换期间禁止重复触发；• 机构到位等待；• 动作超时；• 失败重试或告警。可以抽象成：text DAY_STABLE ↓ 连续满足夜间条件SWITCHING_TO_NIGHT ↓ IRCUT 到位并完成稳定等待NIGHT_STABLE NIGHT_STABLE ↓ 连续满足白天条件SWITCHING_TO_DAY ↓ IRCUT 到位并完成稳定等待DAY_STABLE 5.4 处理“软件成功、硬件失败”如果 IRCUT 没有位置反馈，软件通常只能知道命令是否发送，不能直接知道滤片是否到位。因此建议把状态分成： 命令发送成功 ≠ 机构动作成功 ≠ 滤片到位 ≠ 画面已稳定 必要时通过机械观察、电气测量、切换后画面、超时检测和维护测试建立间接确认机制。 六、常见误区误区 1：所有偏红都调 R 增益可能暂时改善一个场景，但不能修复滤片状态、机械不到位或光谱变化。误区 2：所有偏紫都是 IRCUTBayer Pattern、Sensor 数据格式、AWB、CCM、镜头反射和显示链路都可能造成偏色。误区 3：软件状态就是实际状态软件显示“白天”不代表滤片已切到红片；发送 GPIO 也不代表机构已经到位。误区 4：听到电机声音就是成功电机有声音不等于滤片到达机械限位，仍需检查位置和结果。误区 5：只在室内普通光源下测试自然光和不同光源的光谱成分不同，建议至少增加窗边和室外场景。误区 6：只看最终截图，不保存中间数据没有 RAW、统计值、状态日志和版本信息，就很难判断偏色从哪里开始出现。 七、故障定位记录表编号检查项目结果1白天是否偏红或偏紫待填写2窗边/自然光下是否加重待填写3问题从启动就存在，还是切换后出现待填写4软件日夜状态待填写5IRCUT 实际滤片位置待确认6强制切换是否有机械动作待填写7强制红片后画面是否恢复待填写8GPIO 控制定义是否已核对待填写9动作期间供电是否稳定待测量10机构是否到达机械限位待确认11红片/白片是否装配正确待确认12日夜 ISP Profile 是否匹配待填写13Bayer Pattern 是否与 Sensor 输出一致待确认14AWB 增益是否异常待填写15RAW 数据是否已经偏色待填写16ISP 输出是否已经偏色待填写17更换正常 IRCUT 后是否恢复待验证18更换镜头/模组后是否恢复待验证 八、结论对于白天画面偏红、偏紫的问题，IRCUT 未切到红片是一个重要且应优先验证的方向。原因可能是滤片没有动作、切换位置不准、机构卡住/偏移/松动、红片白片装配异常，也可能是 GPIO、驱动、供电和日夜切换时序造成的。但偏红、偏紫并不只由 IRCUT 引起。Bayer Pattern 配置错误、Sensor 数据格式错误、AWB/CCM/ISP Profile 异常、镜头或滤片光学问题以及显示后处理问题，都可能产生相似现象。推荐的完整排查顺序是：text 1. 固定场景，确认现象和触发条件2. 确认软件目标状态与 IRCUT 实际物理位置3. 强制切换红片/白片并对比画面4. 检查机械结构、滤片装配和到位情况5. 检查 GPIO、驱动、供电和动作时序6. 确认 IRCUT 与 Sensor/ISP Profile 同步7. 核对 Bayer Pattern 和 Sensor 数据格式8. 对比 RAW、ISP 输出和最终显示链路9. 最后再调整 AWB、CCM 和颜色增益 一句话总结： 先确认光学状态，再确认 RAW 和数据链路，最后才调 ISP；只有通过对比实验和数据分层，才能判断画面偏红、偏紫到底是 IRCUT，还是其他环节的问题。
T33-自动化测试反复跑 test 触发 OOM：ISP bin 内存改 vmalloc 并缩减分配大小
T33-自动化测试反复跑 test 触发 OOM：ISP bin 内存改 vmalloc 并缩减分配大小适用场景 在 T32Pro（及同类平台）做自动化测试、反复轮询 test 程序时，出现 OOM 内存错误，且摄数越多越明显。本文适用于排查这类「重复运行导致的累计/分配内存不足」问题，重点是 ISP bin 文件的内存分配方式与大小。问题现象 T32Pro 跑自动化测试反复轮询 test 程序报 OOM，双摄、三摄、四摄均出现。关键对照：相同双摄 500W 配置下 T32-NQ 正常，仅 T32Pro 报 OOM；test 之间加延时后概率缓解但未解决，重复跑同一个 test 即可复现。根因分析 OOM 的根因是 ISP bin 文件内存使用 kmalloc 分配，且默认分配偏大： • kmalloc 分配的是连续物理内存，分配大块时更容易因内存碎片化失败； • bin 默认分配较大，在自动化测试反复加载 bin 的场景下，物理连续内存被反复占用，最终触发 OOM。 「加延时概率缓解」说明与重复分配/释放的时序相关，但根因在分配方式与大小，延时只是降低复现概率。排查与修复方法 第一步，确认对照关系。用同配置在小内存压力或不同芯片（T32-NQ vs T32Pro）上对比，锁定是平台/分配路径差异。 第二步，定位 ISP bin 的内存分配。确认 bin 解析加载时用 kmalloc 还是 vmalloc、分配大小是多少。 第三步，改为 vmalloc。vmalloc 分配虚拟连续（物理可不连续）内存，对大块分配更友好，降低 OOM 风险。 第四步，缩减分配大小。将 bin 分配由 400 缩减为 200（K），并同步修改 SDK 侧 mmap，保证驱动与 SDK 一致。 第五步，压测验证。反复运行 test，确认不再 OOM；并对大分辨率 sensor（如 800 万）回归，确认缩减后无副作用。验证结果 修改后测试数天有效，代码（SDK + ISP）已入库，T32Pro 与 CW080 同步修改，后续数日测试 ok。使用建议 排查自动化测试反复运行导致的 OOM，优先检查大块内存的分配方式（kmalloc 的物理连续限制）与分配大小是否可优化；改 vmalloc + 缩减分配是常见有效手段，但需回归大分辨率场景确认无副作用。
T33-自行编译 kernel 后无码流：排查方向梳理
T33-自行编译 kernel 后无码流：排查方向梳理适用场景在 T33N（及同类）开发板上，用原厂固件能正常出图，但改用自己编译的 kernel 后 carrier-server 无法出流。本文适用于这类「原厂能出、自编不能出」的环境搭建类问题。现象关键对比本工单的现象描述很有价值，给出了三组对照：1. 原厂固件 → 能出图；2. 原厂固件导出的 kernel → 能出图；3. 自编的 4.4.94 kernel → 无码流。「原厂 kernel 能出、自编 kernel 不能出」说明问题不在硬件，而在自编 kernel 与可用的原厂 kernel 之间的差异。排查方向1. 对比 kernel config将自编 kernel 的 config 与「原厂固件导出的可用 kernel」的 config 做差异比对，重点检查 ISP/sensor 相关驱动、media 框架、DMA/I2C/时钟等配置是否被误关或缺失。2. 检查驱动模块是否编入/加载确认 ISP 驱动、sensor 驱动是否已编译进内核或作为模块加载；检查开机日志中是否有驱动 probe 失败、sensor 识别失败等报错。3. 检查 carrier-server 依赖确认 carrier-server 所需的用户态库、接口与自编 kernel 提供的接口是否匹配（版本、符号、设备节点）。4. 检查编译选项与工具链确认编译工具链、内核版本（4.4.94）与 SDK 预期一致，避免工具链不匹配导致的功能异常。注意事项• 本工单评论 0 条，无已确认根因；以上为通用排查方向，具体根因需结合实际 config 差异与日志定位。• 附件中提供了 kernel config，应以此与原厂可用 config 做逐项差异分析。结论「原厂能出图、自编 kernel 不能出图」的环境搭建问题，排查重点在自编 kernel 与原厂可用 kernel 的 config 差异、驱动模块编入/加载情况，以及 carrier-server 接口匹配。
加载 ISP 驱动报错：Makefile 需同时覆盖 glibc 与 uclibc 工具链
加载 ISP 驱动报错：Makefile 需同时覆盖 glibc 与 uclibc 工具链适用场景 本文适用于客户使用 uclibc 工具链交叉编译、加载 ISP 驱动时报错的场景。当同一份 SDK 分别由 glibc 与 uclibc 工具链编译，其中一种工具链下加载驱动报错时，除了检查驱动代码本身，还应检查编译脚本（Makefile）是否对工具链类型做了完整判断，是否缺少某一工具链分支导致库拷贝或链接错误。问题现象 客户使用 uclibc 工具链时，加载 ISP 驱动出现报错。同一份代码在默认工具链下可以正常工作，问题只在切换到 uclibc 工具链后出现，说明不是驱动逻辑本身，而是与工具链相关的编译/拷贝环节出了问题。根因分析 ISP 驱动编译的 Makefile 中只有 glibc 工具链的判断逻辑，缺少 uclibc 分支。编译脚本通常在识别工具链类型后，决定拷贝哪一份预编译的 ISP 库；当只有 glibc 分支时，uclibc 工具链无法匹配到正确分支，走错或漏掉库拷贝逻辑，最终导致 ISP 库拷贝错误、加载驱动时报错。这类问题常被误判为「驱动代码 bug」或「库不兼容」，实际根因在编译脚本的工具链分支覆盖不完整。排查与修复方法 第一步，确认报错与工具链相关。分别用默认（glibc）工具链与 uclibc 工具链编译同一份代码，观察是否只有 uclibc 下报错，锁定为工具链差异问题。 第二步，检查 ISP 驱动编译 Makefile 的工具链判断逻辑。查看脚本通过什么方式识别工具链（如 gcc -dumpmachine、编译前缀、版本号等），确认是否只写了 glibc 分支、缺少 uclibc 分支。 第三步，补充 uclibc 工具链判断逻辑。在 Makefile 中增加 uclibc 分支，使该工具链下能够正确匹配并拷贝对应的 ISP 库，例如根据工具链三元组（如 mips-linux-gnu-）区分 glibc 与 uclibc。 第四步，验证修复。使用 uclibc 工具链重新编译并加载 ISP 驱动，确认报错消失、驱动正常加载。验证结果 库侧已适配 uclibc 工具链（mips-linux-gnu-gcc，Ingenic r2.4.2 gcc add npu uclibc sub rpc sub locale 2024.11-08 4.7.2），工单状态更新为已完成。材料未明确记录客户重新编译后的复测结果，本结论主要依据库侧已适配 uclibc 工具链这一修复记录。使用建议 维护面向多种工具链的 SDK 时，应确保编译脚本对 glibc、uclibc 等工具链分支覆盖完整，并在发布前分别用各工具链做一次编译+加载冒烟测试。定位「某一工具链下才出现的报错」时，优先比对编译脚本的工具链分支，而非先怀疑驱动逻辑。
T33-AOV 双摄休眠唤醒后次摄取不到流：唤醒时把顶层宽高切到次摄
T33-AOV 双摄休眠唤醒后次摄取不到流：唤醒时把顶层宽高切到次摄适用场景 本文适用于采用双摄的 AOV 低功耗设备。设备正常出流时两路画面都正常，但休眠唤醒后，次摄（副摄像头）必现取流失败，主摄仍可正常出流。排查这类「唤醒后仅某一路不出流」的问题时，除了检查 Sensor 供电与复位，还应重点核对唤醒阶段多摄通道的上下文（如顶层宽高）是否随通道切换而同步更新。问题现象 修复前，设备长出流正常，但休眠唤醒后次摄必现取流失败。主摄与次摄在正常出流阶段均无异常，问题只出现在唤醒后的次摄一路，说明并非 Sensor 硬件或整机供电问题，而是唤醒阶段次摄通道的配置没有正确恢复。根因分析 AOV 设备休眠后，ISP 与编码各通道会进入低功耗或复位状态；唤醒时需要对每个通道重新下发配置。本例中，次摄断流的原因是唤醒阶段顶层（top layer）宽高没有切到次摄，仍沿用主摄的宽高配置。顶层宽高是通道上下文的关键参数，决定了取流/显示的输出尺寸。当唤醒后次摄通道被重新拉起，而顶层宽高仍指向主摄时，次摄的通道配置与实际 Sensor 输出不匹配，从而无法取到流。这类问题常被误判为 Sensor 驱动或电源问题，实际根因在通道上下文切换。排查与修复方法 第一步，确认故障是否只在唤醒后出现。记录休眠前、唤醒后两路的出流状态，确认只有次摄一路受影响，排除整机复位或供电问题。 第二步，检查唤醒时次摄通道的完整配置恢复。逐一核对顶层宽高、通道绑定关系、分辨率等上下文参数，确认唤醒阶段是否对次摄重新下发了与主摄无关的独立配置。 第三步，将顶层宽高切换到次摄。在唤醒/切流逻辑中，把顶层宽高更新为次摄对应的取值，而不是继续沿用主摄的宽高。 第四步，验证修复。修改后先在本机复现环境验证次摄唤醒后能正常取流，再制作固件交由客户在实际 AOV 唤醒场景试测，确认问题不再复现。验证结果 修改后本地验证正常，次摄唤醒后不再断流。后续制作固件交由客户试测，工单状态更新为已完成。由于材料未给出客户侧试测的最终反馈，本结论主要依据「修改后本地验证正常」这一内部验证结果；客户实测是否完全通过，需经办人进一步确认。使用建议 排查 AOV 多摄「唤醒后仅一路不出流」类问题，应优先建立「休眠前正常、唤醒后异常」的对比，并将通道上下文（顶层宽高、通道绑定、分辨率）纳入排查清单。修改通道上下文后，建议同时在单摄与双摄、直通与非直通、主摄与次摄之间分别验证，避免只修主摄或只修一路的偏差。
Camera 画面反色、整体偏紫怎么查？——从 Bayer Pattern 理解到配置定位
Camera 画面反色、整体偏紫怎么查？——从 Bayer Pattern 理解到配置定位导读Camera 出图后颜色关系明显不对，例如红蓝反色、画面整体偏紫，甚至彩色区域伴有条纹噪声，这时不要急着修改 AWB、CCM 或颜色增益，应该先确认：Sensor 实际输出的 Bayer Pattern，是否与驱动声明和 ISP 解码配置一致？本文从画面现象开始，解释 Bayer Pattern 的基本原理，再逐步梳理 Sensor、驱动、Mirror/Flip 和 ISP 之间的配置关系。最后还会讨论：如果不是 Bayer Pattern，画面偏紫还可能来自哪些环节。当前资料没有提供具体芯片、Sensor、开发板、SDK、寄存器和实测日志，因此本文以通用方法为主。具体配置项、命令和代码位置应以实际平台资料为准。 一、问题：哪些现象需要优先检查 Bayer Pattern？1.1 正常与异常画面对比正常画面 正常画面示例 正常情况下，红、绿、蓝之间的关系符合实际场景，白色和中性色区域也能得到合理还原。异常现象一：红蓝反色 Bayer Pattern 反色示例 这类画面常见表现是：• 红色和蓝色关系明显不对；• 暖色物体变成冷色，或者冷色物体变成暖色；• 部分白色或低饱和区域看起来可能仍接近正常；• 调节简单的颜色增益难以恢复所有颜色关系。异常现象二：整体偏紫并伴随纹理异常 Bayer Pattern 异常偏紫示例 除了整体偏紫，还可能观察到：• 彩色区域出现细密条纹或网格感；• 物体边缘出现异常彩边；• 细节区域出现彩色伪影；• 颜色错误从设备出图开始就持续存在。这些现象不能单独证明 Bayer Pattern 一定配置错误，但如果颜色关系是系统性错乱，而不是轻微色温偏差，就应该优先核对 RAW 像素排列和 ISP 解码方式。1.2 先做三个判断判断一：是“颜色偏一点”，还是“颜色关系错了”？• 如果整个画面只是轻微偏暖或偏冷，AWB、CCM、光源和滤片都可能是原因；• 如果红蓝明显对调、颜色完全不符合物体本身，应优先检查 Bayer Pattern；• 如果偏紫同时伴随条纹、网格或彩边，也要检查 RAW 排列和去马赛克过程。判断二：问题是否从第一帧就存在？如果设备一开始出图就持续反色，而日夜切换、光源变化或 AWB 收敛都不能改变这种颜色关系，通常更像基础数据格式或 Bayer 配置问题。如果问题只在日夜切换后出现，则还需要检查 IRCUT、日夜 ISP Profile 和切换时序。判断三：Mirror/Flip 前后是否发生变化？部分 Sensor 在开启水平镜像或垂直翻转后，有效 Bayer Pattern 会随读出方向变化。如果画面只在某种 Mirror/Flip 组合下反色或偏紫，应重点检查翻转后的 Bayer 配置是否同步更新。 二、分析：从 Bayer 阵列理解颜色为什么会错2.1 Sensor 的一个像素通常只采集一种颜色常见彩色 Sensor 的感光面上覆盖着彩色滤光阵列（Color Filter Array，CFA）。在 Bayer CFA 中，每个感光像素通常主要对应红、绿、蓝中的一种颜色分量。一个最小的 2×2 单元包含：• 1 个红色像素 R；• 2 个绿色像素 G；• 1 个蓝色像素 B。绿色像素数量较多，与人眼对亮度细节更敏感的特性有关。Sensor 输出的 RAW 数据并不是每个位置都已经具备完整 RGB，而是类似下面的马赛克排列：text R G R G R G ...G B G B G B ...R G R G R G ...G B G B G B ... ISP 需要知道每个像素位置究竟是 R、G 还是 B，然后通过去马赛克（Demosaic）计算出每个输出像素完整的 RGB 信息。2.2 四种常见 Bayer Pattern根据左上角 2×2 单元的排列，常见 Bayer Pattern 有四种：RGGBtext R GG B BGGRtext B GG R GRBGtext G RB G GBRGtext G BR G 汇总如下：Bayer Pattern第一行第二行RGGBR GG BBGGRB GG RGRBGG RB GGBRGG BR G这些名称描述的是像素颜色位置，不是“画面偏什么颜色”的风格选项。2.3 ISP 为什么必须知道正确排列？假设 Sensor 实际输出的是 RGGB：text R GG B 如果 ISP 却按 BGGR 解码：text B GG R 那么原本属于红色的位置会被当作蓝色，原本属于蓝色的位置会被当作红色。后续去马赛克、白平衡和颜色校正都建立在错误的颜色身份上，于是可能产生：• 红蓝反色；• 整体偏紫或偏青；• 颜色边缘出现伪色；• 高频细节产生彩色条纹；• AWB 怎么调也难以恢复真实颜色。问题的本质不是“红色增益太高”，而是 ISP 一开始就把像素的颜色身份认错了。2.4 为什么白色区域有时看起来还算正常？白色或灰色区域中的 R、G、B 分量相对接近。红蓝位置互换后，中性色区域的视觉变化有时不如高饱和红色、蓝色物体明显。此外，AWB 和后续颜色处理还可能对中性色进行一定补偿。因此，不能因为白纸看起来接近白色，就排除 Bayer Pattern 错误。更可靠的测试目标应该同时包含：• 高饱和红色；• 高饱和绿色；• 高饱和蓝色；• 白色、灰色和黑色；• 细密纹理和清晰边缘。2.5 为什么会出现条纹、网格和彩边？Demosaic 会利用相邻像素推算缺失的颜色分量。如果 ISP 对像素颜色位置的理解错误，插值就会使用错误的邻域关系。在纯色边缘、细纹理和高频区域，这种错误容易表现为：• 周期性彩色条纹；• 网格状伪影；• 红蓝彩边；• 细节区域颜色闪烁；• 去马赛克后的结构异常。因此，“偏紫 + 条纹噪声”通常比单纯轻微偏色更值得怀疑 Bayer Pattern 或 RAW 数据格式。 三、Bayer Pattern 为什么会不匹配？3.1 Sensor 实际输出与 ISP 配置不一致这是最直接的情况：Sensor 当前模式实际输出一种排列，而 ISP 按另一种排列解码。需要分别确认：text Sensor 当前实际输出 Pattern驱动向平台声明的 PatternISP 当前采用的 Pattern 三者必须一致。不能只看 Sensor 数据手册中的默认值，还要考虑当前模式、窗口裁剪和读出方向是否改变了有效排列。3.2 驱动中的 mbus_code 或格式声明错误在使用 Media Bus 格式描述 Sensor 输出的平台上，驱动中的 mbus_code 往往同时包含位宽和 Bayer 排列信息。例如，同样是 RAW10，不同 Bayer Pattern 通常对应不同的格式定义。如果驱动声明与 Sensor 实际输出不一致，下游模块就可能按照错误方式处理 RAW 数据。排查时不能只确认“RAW10/RAW12 是否一致”，还要确认：• 位宽；• Bayer 排列；• 数据打包方式；• 当前 Sensor 模式；• ISP 接收到的实际格式。本文不提供具体宏名或枚举值，因为不同内核、SDK 和平台的定义可能不同，应以当前工程头文件和驱动接口为准。3.3 Mirror/Flip 改变了有效 Bayer Pattern水平镜像和垂直翻转会改变像素的读出方向。对于某些 Sensor，有效 Bayer Pattern 会随之变化。以一个 RGGB 的 2×2 单元为例：text 原始 RGGBR GG B 如果只从排列关系理解，进行不同方向翻转后，左上角 2×2 的有效顺序可能转化为其他 Pattern。实际对应关系还要结合 Sensor 的读出起点、裁剪和驱动实现确认，不能脱离具体设备直接写死。工程中常见的问题是：text Sensor 端已经执行 Mirror/Flip ↓RAW 有效排列随之变化 ↓ISP 仍使用翻转前的 Bayer 配置 ↓画面反色、偏紫或出现彩色纹理 所以每次修改 Mirror/Flip，都应该同步验证：• Sensor 寄存器是否生效；• 输出尺寸和裁剪起点是否变化；• 驱动声明是否更新；• ISP Bayer 配置是否更新；• 四种翻转组合是否都测试过。3.4 裁剪起点或像素偏移改变Bayer Pattern 是周期性的 2×2 排列。如果 RAW 图像的有效起点在水平方向或垂直方向偏移一个像素，左上角的颜色身份就可能改变。因此，在修改以下内容后也要重新确认 Bayer 排列：• Sensor ROI；• 数字裁剪起点；• ISP 输入裁剪；• 黑边去除；• 拼接或图像搬运偏移；• 有效图像起始坐标。并不是所有裁剪都会改变 Pattern。关键在于裁剪起点相对原始阵列是否发生奇数像素偏移。3.5 RAW 数据位宽、打包或字节顺序错误有些异常虽然看起来像 Bayer Pattern 错误，实际根因可能是：• RAW10/RAW12 位宽配置不一致；• MIPI RAW 打包解释错误；• 字节顺序错误；• 行长度或 stride 错误；• 数据对齐错误；• 丢字节或行起点错位。这类问题往往不只影响颜色，还可能伴随亮度异常、周期纹理、撕裂或图像结构错误。不能只在四种 Bayer Pattern 之间轮流尝试，然后选择“看起来最好”的一种。 四、解决：如何一步一步确认配置？4.1 第一步：固定测试条件准备一个同时包含红、绿、蓝、白、灰和黑的稳定场景，并尽量固定：• 光源；• 曝光和增益；• AWB 状态；• Sensor 模式；• 分辨率和帧率；• Mirror/Flip；• ISP 参数版本。每次只改变一个变量，避免同时修改 Bayer Pattern、AWB、CCM 和 Mirror/Flip。4.2 第二步：确认 Sensor 当前模式的实际输出查看并交叉验证：1. Sensor 数据手册；2. 当前模式寄存器表；3. Sensor 驱动；4. Mirror/Flip 配置；5. 裁剪起点和输出窗口；6. 平台抓取的 RAW 数据。不能只依据 Sensor 型号推断，因为不同模式、不同窗口或翻转组合可能采用不同的有效排列。4.3 第三步：核对驱动格式声明检查 Sensor 驱动向下游声明的：• RAW 位宽；• Bayer Pattern；• mbus_code 或平台等价字段；• 当前模式索引；• Mirror/Flip 后的格式更新逻辑。建议在日志中同时打印“模式、分辨率、Mirror/Flip、驱动声明 Pattern”，避免只打印一个没有上下文的格式值。4.4 第四步：核对 ISP 当前解码配置确认 ISP 实际生效的配置，而不只是配置文件里写了什么：• ISP 输入格式；• Bayer Pattern；• RAW 位宽；• 当前日夜或场景 Profile；• 参数加载时间；• 是否有其他模块重新覆盖。如果平台支持运行时查询，应把查询结果与 Sensor 驱动声明进行对照。4.5 第五步：分别验证 Mirror/Flip 组合建议至少覆盖：MirrorFlip画面方向有效 Bayer Pattern结果关闭关闭待填写待确认待测试开启关闭待填写待确认待测试关闭开启待填写待确认待测试开启开启待填写待确认待测试不要假设某个平台一定能自动同步 Pattern。应分别确认 Sensor、驱动和 ISP 的行为。4.6 第六步：抓 RAW 建立证据如果条件允许，保存当前 Sensor 模式下的 RAW 数据，并记录：• 分辨率；• 位宽；• 打包格式；• Bayer Pattern；• Mirror/Flip；• 曝光和增益；• 裁剪起点；• 对应的 ISP 输出画面。用 RAW 工具分别按候选 Pattern 解码可以辅助判断，但不能只凭“哪一种看起来更顺眼”下结论，还应结合高饱和色块、像素位置、驱动配置和 Sensor 文档。4.7 第七步：修复后回归验证修正配置后，至少确认：• 红、绿、蓝颜色关系正确；• 白、灰、黑保持中性；• 彩色条纹和边缘伪色消失；• 各个 Sensor 模式均正常；• Mirror/Flip 四种组合符合预期；• 切换分辨率、帧率或 Profile 后不会复发；• 重启后配置仍然生效。修复 Bayer Pattern 后，如果画面仍有轻微色温或饱和度偏差，再进入 AWB、CCM 和其他 IQ 参数调试。 五、进一步判断：偏紫、偏色还可能是什么原因？5.1 先从成像链路分层text 场景光线和镜头 ↓IRCUT / 光学滤片 ↓Sensor 和 RAW 数据 ↓Bayer 解码与 Demosaic ↓AWB、CCM 和其他 ISP 模块 ↓YUV/RGB、编码和显示 偏色可能在每一层产生。Bayer Pattern 错误只是其中一种，而且往往表现为颜色关系的系统性错误。5.2 常见原因对比候选原因常见表现常见触发条件优先验证方法Bayer Pattern 不匹配红蓝反色、整体偏紫、彩色条纹或伪色启动即存在，或 Mirror/Flip 后出现核对 RAW、驱动声明和 ISP PatternRAW 位宽/打包错误颜色、亮度和图像结构同时异常Sensor 模式或接口配置变更后核对 RAW10/12、打包、stride 和行长度IRCUT 未切到红片白天偏红/偏紫，自然光下可能加重日夜切换后或白天强制切换并确认实际滤片位置AWB 异常随光源和场景变化，收敛慢或增益极端光源变化、统计区域变化后锁定 AWB并观察 R/G、B/G 增益CCM/Profile 错误整体色调固定异常，换参数后改变ISP 参数加载或模式切换后核对当前 Profile、CCM 和生效配置镜头/滤片光学问题局部红斑、边角异常、鬼影强光、特定角度或特定光源改变入射角，替换镜头或滤片显示/色彩空间问题RAW/ISP 输出正常，最终画面异常编码或显示阶段对比 RAW、ISP 输出和最终显示这些表现是排查线索，不是绝对判据。两个问题也可能同时存在，例如 Bayer Pattern 配错的同时，AWB 还在错误输入上继续补偿。5.3 Bayer Pattern 和 IRCUT 怎么区分？可以先看两个特征：是否与滤片位置和自然光相关？• 强制切换红片、白片后颜色明显变化，自然光下问题加重：更应关注 IRCUT；• 改变 IRCUT 后红蓝关系仍然固定反转：更应关注 Bayer Pattern。是否从启动开始持续存在？• 从第一帧开始就反色，所有光源下关系类似：更像 Bayer/RAW 配置问题；• 日夜切换后才出现，重新切换滤片后恢复：更像 IRCUT 或切换时序问题。5.4 Bayer Pattern 和 AWB/CCM 怎么区分？• 红蓝关系系统性对调：先查 Bayer Pattern；• 整体轻微偏暖、偏冷，并随光源变化：先观察 AWB；• 色调固定异常，但像素结构和颜色身份基本正确：检查 CCM/Profile；• 偏紫同时伴随周期性彩色纹理：优先检查 Bayer/RAW 数据，再检查 IQ。必要时固定 AE/AWB，对比不同 Pattern 下的 RAW 解码结果。不要通过大幅修改 AWB 增益去“纠正”错误的像素颜色身份。5.5 RAW、ISP 输出和最终画面分层对比text RAW 数据结构已异常 → 查 Sensor、MIPI、位宽、打包、stride 和数据搬运 RAW 数据正确，但按当前 Pattern 解码后反色 → 查 Bayer Pattern、驱动声明和 ISP 输入配置 Demosaic 后颜色关系正确，后续 ISP 输出偏色 → 查 AWB、CCM、Profile 和颜色处理 ISP 输出正常，最终显示偏色 → 查色彩空间、编码、显示和后处理 定位目标不是证明“某个配置看起来不对”，而是确定偏色最早出现在哪个数据节点。 六、让问题更容易复现和定位6.1 分开记录四种 Pattern 状态建议不要只记录一个模糊的 bayer=RGGB，而是分别记录：text Sensor 文档/模式表定义的 Pattern当前寄存器和窗口下的实际 Pattern驱动向下游声明的 PatternISP 当前生效的 Pattern 如果开启 Mirror/Flip，还应记录翻转后的有效 Pattern。6.2 推荐日志字段text Sensor 型号和模式输出分辨率和帧率RAW 位宽和打包格式窗口起点和裁剪范围Mirror 状态Flip 状态驱动声明的 mbus_code/格式ISP 当前输入格式ISP 当前 Bayer PatternISP Profile 和版本 示例：text [SENSOR] mode=[SENSOR] mirror=[SENSOR] output_pattern=[DRIVER] media_bus_format=[ISP] input_pattern= 占位符需要替换成项目实际值，不能直接作为代码或配置使用。6.3 使用控制变量实验实验只改变的变量主要回答的问题AISP Bayer Pattern哪种解码方式与当前 RAW 一致？BMirror/Flip有效 Pattern 是否随读出方向变化？CSensor 模式是否只有某个分辨率或窗口异常？DAWB 锁定状态AWB 是否在放大或掩盖错误？EIRCUT 状态偏色是否来自光学滤片？F输出节点异常最早出现在哪个处理阶段？每次实验记录输入条件、唯一变量、RAW、输出画面、日志和结论，避免同时修改多项配置后无法判断真正生效的是哪一项。6.4 建立配置同步关系涉及以下操作时，都应重新确认 Bayer Pattern：• 切换 Sensor 模式；• 修改分辨率；• 调整裁剪窗口；• 开启或关闭 Mirror/Flip；• 替换 Sensor；• 修改驱动格式声明；• 切换 ISP 输入通道；• 更新 SDK 或 ISP 参数版本。最好让模式表、驱动格式和 ISP 配置使用统一来源，减少同一信息在多个模块中分别硬编码造成的不一致。 七、常见误区误区 1：看到偏紫就修改 AWB 或 CCM如果 ISP 把像素颜色身份认错，后续颜色参数无法从根本上恢复真实颜色关系。误区 2：轮流尝试四种 Pattern，选一个看起来最好的这种方法可以辅助定位，但不能替代 Sensor 文档、驱动配置和 RAW 数据验证，尤其不能掩盖位宽、打包或行偏移问题。误区 3：Sensor 数据手册写 RGGB，所有模式就一定都是 RGGBMirror/Flip、裁剪起点和读出窗口可能改变有效 Pattern，必须确认当前模式的实际输出。误区 4：只改 ISP，不改驱动声明如果驱动向下游声明的格式仍然错误，模式切换、重启或其他模块重新配置后问题可能复发。误区 5：白色区域正常就排除 Bayer 错误中性色区域对红蓝互换可能不够敏感，应使用高饱和红、绿、蓝目标综合判断。误区 6：把所有条纹都归因于 Bayer Pattern位宽、MIPI 打包、stride、丢字节和行起点错误也可能产生周期性纹理，需要结合 RAW 数据结构判断。 八、故障定位记录表编号检查项目结果1画面是轻微偏色还是红蓝反色待填写2是否伴随条纹、网格或彩边待填写3问题是否从第一帧就存在待填写4Sensor 型号和当前模式待确认5Sensor 实际 Bayer Pattern待确认6RAW 位宽和打包格式待确认7驱动声明的格式/mbus_code待确认8ISP 当前生效 Pattern待确认9Mirror/Flip 状态待填写10裁剪起点是否为奇数偏移待确认11四种 Mirror/Flip 组合是否验证待测试12RAW 数据结构是否正常待验证13锁定 AWB 后现象是否变化待测试14切换 IRCUT 后现象是否变化待测试15ISP 输出和最终显示是否一致待验证16修复后所有模式是否回归通过待验证 九、结论当 Camera 画面出现红蓝反色、整体偏紫，特别是还伴随彩色条纹、网格或边缘伪色时，应优先确认 Sensor 实际输出的 Bayer Pattern 是否与驱动声明和 ISP 解码配置一致。常见根因包括：1. Sensor 输出 Pattern 与 ISP 配置不一致；2. RAW 数据顺序或格式声明错误；3. Sensor 驱动中的 mbus_code 或等价字段配置错误；4. Mirror/Flip 后有效 Bayer Pattern 变化，但 ISP 没有同步；5. 裁剪起点发生奇数像素偏移；6. RAW 位宽、打包、stride 或数据对齐问题被误认为 Bayer 错误。推荐的排查顺序是：text 1. 观察是轻微偏色，还是颜色关系系统性错误2. 确认 Sensor 当前模式、Mirror/Flip 和裁剪窗口3. 确认 Sensor 实际 Bayer Pattern4. 核对驱动格式声明和 mbus_code5. 核对 ISP 当前生效的 Pattern 和 RAW 位宽6. 抓 RAW，检查打包、行长度、起点和数据结构7. 分别验证四种 Mirror/Flip 组合8. 修复后回归所有 Sensor 模式9. Bayer/RAW 正确后，再调 AWB、CCM 和其他 IQ 参数 一句话总结： Bayer Pattern 错误不是普通的颜色风格偏差，而是 ISP 对 RAW 像素颜色身份的理解发生了错误；先把 Sensor、驱动和 ISP 的排列关系对齐，再谈后续 IQ 调优。
T33-大容量 SD 卡格式化慢：discard_max_bytes 过小导致 trim 被拆成海量小段
T33-大容量 SD 卡格式化慢：discard_max_bytes 过小导致 trim 被拆成海量小段适用场景 在 T33 系列平台（本例 T33V）使用大容量 SD 卡（如 512G）时，格式化/写前擦除异常缓慢（十几分钟级）。本文适用于排查这类「大容量卡明显比小容量卡慢」的 discard/trim 性能问题。问题现象 T33V 设备上 512G SD 卡格式化耗时十几分钟，明显异常。同类小容量卡（32G）正常。根因分析 格式化会向块设备下发大范围 discard/trim（例如按 4GB 粒度）。块设备会按队列的 discard_max_bytes（由 max_discard_sectors × 512 导出）把一次大范围请求拆成多段。本例的关键数值差异： • 32G 卡：discard_max_bytes = 10028580864（约 19,587,072 个 512 字节扇区），单次可覆盖大范围。 • 512G 卡：discard_max_bytes = 11264（约 22 个扇区）。 512G 卡的 discard_max_bytes 异常地小，导致同一次大范围 trim 被拆成海量小段，系统调用与下层 IO 次数暴涨，整体耗时激增、出现超时。排查与修复方法 第一步，确认现象与容量相关。对比不同容量卡的格式化耗时与 cat /sys/block/mmc0/queue/discard_max_bytes 取值。 第二步，定位 max_discard 的计算来源。本问题源于 max_discard 由 sdhci 的 default 超时时间 + erase 扇区时间计算，对大容量卡得到过小值。 第三步，改用 SD 卡 erase size 决定 max_discard。使单次 discard 粒度与卡的实际擦除块匹配。 第四步，校验擦除完成。配合读卡等待超时（接近 6S），确保大范围擦除完整完成。 第五步，验证。对大容量卡执行格式化，确认耗时恢复正常、无超时。验证结果 补丁后可正常格式化 512G 卡，代码已入库，工单关闭。使用建议 排查大容量存储卡格式化/trim 慢时，先对比不同容量卡的 discard_max_bytes，关注 max_discard 是否过小导致请求被过度拆分；修复方向是让 discard 粒度与卡的 erase size 匹配，而非简单调大超时。