IS(Image Stabilization) DEBUG SOP¶

REVISION HISTORY¶

Revision No.	Description	Date
1.00	Initial release	12/13/2023
	新增DIS-GYRO模式下，算法错误log的排查说明	08/11/2025

1. 前言¶

该文档主要收录在使用防抖功能时，所遇到常见问题的定位或排查方法。

注意：
- 防抖功能位于MI_LDC 模块中，其中分为DIS-GME（DIS，数字防抖）与DIS-GYRO（EIS，电子防抖）两大类。

2. 问题快速索引清单¶

类别	问题清单
DIS-GME（DIS）模式	3.1 DIS处理流程卡死
	3.2 CMDQ Timeout
	3.3 CVS_R / CVS_W MIU HitAddress or MMU Callback
	3.4 花屏
	3.5 无防抖效果或防抖效果不佳
DIS-GYRO（EIS）模式	4.1 DIS处理流程卡死
	4.2 出现Gyro IS NOT Ready的打印
	4.3 出现GYRO_IOC_CMD_xxxxxxx fail打印
	4.4 花屏
	4.5 无防抖效果或防抖效果不佳
	4.6 算法错误log排查
	4.6.1 出现distor_intensity is too strong的算法log
	4.6.2 出现Undistortion ratio error的算法log
	4.6.3 出现init flow error的算法log
	4.6.4 出现Crop initialization not centered per spec的算法log

3. DIS-GME模式常见问题¶

3.1 DIS处理流程卡死¶

在软件处理流程中，负责防抖处理主要逻辑位于DIS PASS（即为MI_LDC模块中pass0）。

3.1.1 现象¶

在发生该种情况时，一般会伴随着掉帧、无流、刷如下log:

# 情况1：output task卡住
[MI WRN] _MI_SYS_Pass_TryDequeueOutputTaskNoLock[6154]:  [thread:ldc0_P0_MAIN] mod[23] dev[0] pass[0] chn[0] output not finished more than 5000ms；
[MI WRN] _MI_SYS_Pass_DebugDumpOutputTaskFence[371]: [0:c71dbe00 0000000d] fence39
# 情况2：input task卡住
[MI WRN] _MI_SYS_Pass_TryDequeueInputTaskNoLock[3325]:  [thread:ldc0_P0_MAIN] mod[23] dev[0] pass[0] chn[0] inputtask's fence not finished more than 5000ms；
[MI WRN] _MI_SYS_Pass_TryDequeueInputTaskNoLock[3391]:  [thread:ldc0_P0_MAIN] mod[23] dev[0] pass[0] chn[0] inputtask CheckInputTaskStatus failed more than 5000ms,total pending task32；

3.1.2 排查方向¶

STEP1：排查死锁可能性

执行echo show_threads > /proc/mi_modules/mi_ldc/mi_ldc0；
查看log是否有LDC/DIS字样的API一直在等锁或信号量；

STEP2：排查硬件卡住可能性

执行/customer/riux32_r 0x1b24；
查看offset 0x11的值是否过大，如果存在千万以上的值，大概率是硬件卡住；

STEP3：排查软件卡住可能性

执行echo 7 > /proc/mi_modules/mi_ldc/debug_level；
查看ldc log是否存在异常，如重复打印同一句或一种类型的log（处于某种循环）；

STEP4：如果上述步骤无法解决

将上述步骤的执行log收集提供给模块owner；
执行cat /proc/mi_modules/mi_ldc/mi_ldc0，保存log提供给模块owner；
说明客户场景，如帧率、分辨率、模块channel使用情况；

3.2 CMDQ Timeout¶

遇到该问题时，由于可能与硬件或下的指令有关，需请FAE同事抓取log给模块owner进行分析，具体步骤如下。

3.2.1 现象¶

触发该问题时，首先需要确认是否有使用DIS的场景，其次CMDQ ID是否为CVS_TRIG，现象如下：

<3>[CMDQ]cmdq(4)[35m ERR: WAIT_TRIG_TIMEOUT [m(0x00000400)
<3>[CMDQ][35mCmd data = 0x2000 : 0x0000 : 0x0000 : 0xFFFE
<3>[CMDQ][35mCmd:WAIT, dbg:0, adr:000000, dat:0000, mask:fffe
<3>[CMDQ][35mWait command timeout. Trigger_Bus Bit [0] Event [CVS_TRIG]

3.2.2 抓取log步骤¶

STEP1: disable cmdq reset option

执行如下命令，若明确已disable，可直接在触发问题的情况下执行STEP3：

vi /config/modparam.json; # 添加"bEnableCmdqReset":0内容到sys的节点
sync;
reboot; # 或执行echo /config/modparam.json > /proc/mi_modules/mi_common/modparam

STEP2: 重新运行app，待问题复现，保留现场

STEP3: 执行如下命令，抓取log给模块owner

#!/bin/bash
for((i=0;i<5;i+=1));
do
    /customer/riux32_r 0x1038;
    /customer/riux32_r 0x1b24;
    cat /proc/mi_modules/mi_ldc/mi_ldc0;
done

3.3 CVS_R / CVS_W MIU HitAddress or MMU Callback¶

遇到该问题时，由于可能与实际运行的时序有关，需请FAE同事按如下步骤抓取log给模块owner分析。

3.3.1 现象¶

触发该问题时，首先需要确认是否有使用DIS的场景，其次访问ID是否为CVS_R/W，现象如下：

#情况1：MMU Callback
[MI WRN] MI_SYS_Mma_MmuCallback[357]: [MI_SYS_Mma_MmuCallback] Status=0x4, PhyAddr=0x402c20000, ClientId=0x4c,Name=CVS_W      IsWrite=1
[MI WRN] MI_SYS_Mma_MmuCallback[357]: [MI_SYS_Mma_MmuCallback] Status=0x4, PhyAddr=0x402c20000, ClientId=0x4c,Name=CVS_R      IsWrite=1
#情况2：MIU HitAddress
MIU0 Block:1 WR Client:CVS_W      ID:4-12 Hitted_Address(MIU):0x3ffe0000<->0x3ffe000f
MIU0 Block:1 WR Client:CVS_R      ID:4-12 Hitted_Address(MIU):0x3ffe0000<->0x3ffe000f

3.3.2 抓取log步骤¶

STEP1：修改modparam.json，开启debug MMU与disable miuprotect

vi /config/modparam.json; # 添加"debugMmu":1,"g_bEnableMiuProtect":0 内容到sys的节点
sync;
reboot; # 或执行echo /config/modparam.json > /proc/mi_modules/mi_common/modparam

STEP2：执行如下命令，抓取信息提供给模块owner

echo debug_mmu debug_log 1 23 > /proc/mi_modules/mi_sys/mi_sys0;
echo 7 > /proc/mi_modules/mi_ldc/debug_level;

3.4 花屏¶

触发该问题时，需要明确是哪级模块的责任，若怀疑是MI_LDC(DIS)，执行如下步骤：

3.4.1 现象¶

出现该问题时，一般从rtsp拉流可看到画面出现黑边、绿条等现象。

3.4.2 排查方向¶

STEP1: dump MI_LDC的输入和输出，确认是否有问题

# dump input task, dis passid=0, chnid需与客户实际场景确认
# echo dumpinputtask [chnid, passid, cnt, path] > /proc/mi_modules/mi_ldc/mi_ldc0
echo dumpinputtask 0, 0, 2, /mnt > /proc/mi_modules/mi_ldc/mi_ldc0
# dump output task, dis passid=0, chnid需与客户实际场景确认
# echo dumpoutputtask [chnid, passid, cnt, path] > /proc/mi_modules/mi_ldc/mi_ldc0
echo dumpoutputtask 0, 0, 2, /mnt > /proc/mi_modules/mi_ldc/mi_ldc0

STEP2: 若dump 出来的输入已经花屏

可排除MI_LDC的问题，可使用前级的dump命令来进行定位具体模块；

STEP3: 若dump 出来的输入无花屏而输出花屏

可确定是MI_LDC的问题，可将dump的 输入和输出与场景 提供给模块owner进行分析；

STEP4: 若dump 出来的输入输出无花屏

可排除MI_LDC的问题，可使用后级的dump命令来进行定位具体模块；

3.5 无防抖效果或防抖效果不佳¶

该问题可先通过如下的方向进行分析确认，若依旧无效果或无排查方向，可提供如下完整信息给模块owner进行分析：

录制最终的效果视频；
记录运行时的完整log，包括串口和telnet端；
场景说明（如pipeline、通过MI_LDC接口所设定DIS-GME模式的参数（该参数可通过运行时执行cat /proc/mi_module/mi_ldc/mi_ldc0获取））。

3.5.1 排查方向¶

STEP1: 查看输入视频质量和场景

现象	可能的原因及解决办法
输出视频有拖影闪烁	逐帧检查输入的视频是否存在运动模糊，如果有运动模糊需要调IQ消除运动模糊
输出视频不防抖或有扭曲	1. 查看输入视频中的场景是否缺少特征（极低照度、大物体遮挡等原因均有可能导致缺少特征） 2. 查看输入视频中前景和背景是否具有明显深度差异（大视差） 3. 查看输入的抖动视频中是否有大运动前景 4. 查看输入的视频是否有明显rolling shutter

STEP2: 查看镜头是否有明显的畸变

视频畸变对DIS效果也存在影响，建议使用畸变尽量小的镜头，或进行畸变校正，以消除视频畸变对DIS效果的影响。如下图所示为畸变校正前后：

畸变的视频帧

畸变校正后的视频帧

STEP3: 查看镜头是否存在较大视差

具有较大视差（即前景和背景具有明显深度差异）的场景，可能会造成DIS输出的视频扭曲。因此，不建议DIS应用在视差大的场景。

视差大的视频帧

STEP4: 查看场景是否为低照度场景

在一定的暗光范围内，DIS仍可正常工作。但是在极低照度环境下，DIS会检测不到特征点，导致效果变差。因此，不建议DIS应用在极低照度环境，如下图：

极低照度的视频帧

注意：

在串流开始时，ISP 模块会收敛，默认会丢掉10张图片，该过程正是从暗到亮的过程，若收敛次数不够，可能也会导致送给DIS模块的图片亮度信息在变化（有可能依旧很暗），如下图：

ISP收敛过程极低照度的视频帧

ISP收敛过程低照度的视频帧

4. DIS-GYRO模式常见问题¶

4.1 DIS处理流程卡死¶

在软件处理流程中，负责防抖处理主要逻辑位于DIS PASS（即为MI_LDC模块中pass0）。

4.1.1 现象¶

在发生该情况时，一般会伴随掉帧、无流、刷如下log:

# 情况1：output task卡住
[MI WRN] _MI_SYS_Pass_TryDequeueOutputTaskNoLock[6154]:  [thread:ldc0_P0_MAIN] mod[23] dev[0] pass[0] chn[0] output not finished more than 5000ms；
[MI WRN] _MI_SYS_Pass_DebugDumpOutputTaskFence[371]: [0:c71dbe00 0000000d] fence39
# 情况2：input task卡住
[MI WRN] _MI_SYS_Pass_TryDequeueInputTaskNoLock[3325]:  [thread:ldc0_P0_MAIN] mod[23] dev[0] pass[0] chn[0] inputtask's fence not finished more than 5000ms；
[MI WRN] _MI_SYS_Pass_TryDequeueInputTaskNoLock[3391]:  [thread:ldc0_P0_MAIN] mod[23] dev[0] pass[0] chn[0] inputtask CheckInputTaskStatus failed more than 5000ms,total pending task32；

4.1.2 排查方向¶

STEP1：排查死锁可能性

执行echo show_threads > /proc/mi_modules/mi_ldc/mi_ldc0；
查看log是否有LDC/DIS字样的API一直在等锁或信号量；

STEP2：排查软件卡住可能性

执行echo 7 > /proc/mi_modules/mi_ldc/debug_level；
查看ldc log是否存在异常，如重复打印同一句或一种类型的log（处于某种循环）；

STEP3：如果上述步骤无法解决

将上述步骤的执行log收集提供给模块owner；
执行cat /proc/mi_modules/mi_ldc/mi_ldc0，保存log提供给模块owner；
说明客户场景，如帧率、分辨率、模块channel使用情况；

4.2 出现Gyro IS NOT Ready的打印¶

4.2.1 现象¶

出现该现象，表示从GYRO外设中拿到的FIFO DATA（GYRO会根据采样率的设定在固定时间间隔中往FIFO BUFFER写入固定的数据量）已经满了：

[Warn]：Gyro not ready!!!!

注意：
- 在APP一开始跑起来会刷大概6条该log，此现象为正常，不需要进行下述步骤来排查问题；
- 若发现连续不断刷或间隔时间段刷该log，则需进行排查。

4.2.2 排查方向¶

STEP1：排查是否存在掉帧或帧率过低的情况

由于GYRO会根据采样率的设定在固定时间间隔中往GYRO FIFO BUFFER写入固定的数据量，假设帧率下降太多，来不及从GYRO FIFO BUFFER中取数据，会导致数据堆积。

执行cat /proc/mi_modules/mi_ldc/mi_ldc0，查看此时MI_LDC的整体帧率，如下图：

STEP2：排查是否由于杜邦线连接松动导致传输得到的数据为默认最大值

重新拔插杜邦线，再跑APP尝试；

STEP3：如果上述步骤无法解决

将上述步骤的执行log收集提供给模块owner；
执行cat /proc/mi_modules/mi_ldc/mi_ldc0，保存log提供给模块owner；
说明客户场景，如帧率、分辨率、模块channel使用情况；

4.3 出现GYRO_IOC_CMD_xxxxxxx fail打印¶

4.3.1 现象¶

在发生该种情况时，一般会伴随着无流、刷如下log:

# 情况1：获取加速度传感器信息fail
[MI ERR ]: _LDC_DISALGO_GYRO_Register[102]: {GYRO_IOC_CMD_GET_ACCEL_SENSITIVIVT} fail， ret:-1
[MI ERR ]: _LDC_DISALGO_GYRO_Register[102]: Gyro Get Sensitivity Fail

4.3.2 排查方向¶

STEP1：排查是否是杜邦线连接错误导致

检查GYRO的杜邦线连接。由于客户所使用的GYRO Sensor板与Chip Board可能与公版不一致，故需与客户确认，最好拿到GYRO Sensor的原理图与实际板端连线图进行确认。

STEP2：排查是否为杜邦线本身就存在断路或脱焊

可尝试更换杜邦线后重新运行，或使用万用表测试杜邦线的导通情况；
可尝试加焊后重新运行；
连接LA（逻辑分析仪），查看波形。

STEP3：如果上述步骤无法解决

将上述步骤的执行log收集提供给模块owner；
将客户的dts配置、gyro型号与gyro移植代码提供给模块owner；
如果可以，可将整个设备寄送给模块owner分析；

4.4 花屏¶

4.4.1 现象¶

出现该问题时，一般从rtsp拉流可看到画面出现黑边、绿条等现象。

4.4.2 排查方向¶

STEP1: dump MI_LDC的输入和输出，确认是否有问题

# dump input task,dis passid=0
# echo dumpinputtask [chnid, passid, cnt, path] > /proc/mi_modules/mi_ldc/mi_ldc0
echo dumpinputtask 0, 0, 2, /mnt > /proc/mi_modules/mi_ldc/mi_ldc0
# dump output task
# echo dumpoutputtask [chnid, passid, cnt, path] > /proc/mi_modules/mi_ldc/mi_ldc0
echo dumpoutputtask 0, 0, 2, /mnt > /proc/mi_modules/mi_ldc/mi_ldc0

STEP2: 若dump 出来的输入已经花屏

可排除MI_LDC的问题，可使用前级的dump命令来进行定位具体模块；

STEP3: 若dump 出来的输入无花屏而输出花屏

可确定是MI_LDC的问题，可将dump的**输入和输出与场景**提供给模块owner进行分析；

STEP4: 若dump 出来的输入输出无花屏

可排除MI_LDC的问题，可使用后级的dump命令来进行定位具体模块；

4.5 无防抖效果或防抖效果不佳¶

4.5.1 排查方向¶

该问题可先通过如下的方向进行分析确认，若依旧无效果或无排查方向，可提供如下完整信息给模块owner进行分析：

录制最终的效果视频；
记录运行时的完整log，包括串口和telnet端；
场景说明（如pipeline、通过MI_LDC接口所设定DIS-GYRO模式的参数（该参数可通过运行时执行cat /proc/mi_module/mi_ldc/mi_ldc0获取））。

STEP1: 查看GYRO外设是否正常功能

查看串口/telnet是否有下述问题中的打印：

4.2 出现Gyro IS NOT Ready的打印
4.3 出现GYRO_IOC_CMD_xxxxxxx fail打印

STEP2: 查看DISAttr的参数设定是否符合要求

可打开[IS用户指南]查看 as32RotationMatrix、 u32FocalLengthX与u32FocalLengthY 参数设定是否符合规则。

4.6 算法错误log排查¶

出现算法错误log，优先按对应log的章节进行排查，若按对应章节内容分析无果，可按如下统一步骤分析：

STEP1: 排查镜头和Image Sensor与实际配置不对应的可能性

参考[IS用户指南]查看 u32FocalLengthX与u32FocalLengthY 参数设定是否符合规则；
检查**s32FisheyeRadius**参数是否符合此计算规则（广角镜头）：s32FisheyeRadius = (sqrt(active_full_size_width^2 + active_full_size_height^2))/2；
检查标定文件Lenspec.dat的参数是否与实际使用镜头一致，检查方法：

检查第一行基本配置与实际使用镜头是否一致

Angle	需配置为0
real_height	需配置为0
reference_height	需配置为0
xc	为image_width/2
yc	为image_height/2
radius	广角镜头下，按公式计算(sqrt(image_width^2 + image_height^2))/2
FOV	按实际镜头配置，如下示例为107.9，保留一位小数即可
image_width	按sensor datasheet中最大有效的width填写（部分手册称为active full size），如下示例为4032
image_height	按sensor datasheet中最大有效的height填写（部分手册称为active full size），如下示例为3024

</td>

检查剩余行的畸变数据与对应镜头的畸变表是否一致

畸变表：提供每个angle对应的real_height与ref_height。此时与lenspec.dat中对应的angle、real_height与ref_height检查即可
畸变表：提供Image Height、Optical distortion与FOV的。需按如下公式进行转换后检查： - angle=FOV/2; - real_height=Image Height; - ref_height=real_height/(Optical distortion/100 + 1)，若Optical distortion以实际值提供（非百分比），则不需除100。

STEP2：如果上述步骤无法解决

提供如下资料给owner分析。

官方手册：镜头的Spec file和Image Sensor的Datasheet；
标定相关文件：Lenspec.dat以及CalibPoly_new.bin；
出问题时配置的参数值：MI_LDC_ChnDISAttr_t与MI_LDC_ChnLDCAttr_t；
出问题时的log：若问题出现在调用MI_LDC_StartChannel前，则如下b的log无需提供 a. proc信息：运行时执行cat /proc/mi_modules/mi_ldc/mi_ldcX, X为devid; b. 算法log：在调用MI_LDC_StartChannel后执行echo calib_loglv chn_id 18 > /proc/mi_modules/mi_ldc/mi_ldcX，chn_id与X按实际场景配置； c. APP运行log：执行echo 7 > /proc/mi_modules/mi_ldc/debug_level抓取。

4.6.1 出现distor_intensity is too strong的算法log¶

4.6.1.1 现象¶

在发生该种情况时，一般会伴随着一开始参数配置失败断流或动态调整参数失败的情况。完整错误log如下：

distor_intensity is too strong and cannot be suppored, please reduce !!!
ERR func: xxxxxx

4.6.1.2 排查方向¶

STEP1: 排查畸变矫正强度过大可能性

上述log表示畸变矫正时，算法对多个参数进行综合性判断发现当前的矫正强度过大无法支持，故可优先降低s32DistortionRatio参数值。

确认此时s32DistortionRatio参数是否为零，若为零则不需进入2调整，直接进行STEP2；
将s32DistortionRatio参数按步进值1或2逐步降低进行配置；

STEP2: 其他排查方法

按统一步骤进行排查。

4.6.2 出现Undistortion ratio error的算法log¶

4.6.2.1 现象¶

在发生该种情况时，一般会伴随着一开始参数配置失败断流或动态调整参数失败的情况。完整错误log如下：

Undistortion ratio error， please check binning ratio
[MI ERR]: xxxx

4.6.2.2 排查方向¶

STEP1: 排查SensorDriver的binning_mode参数配置错误的可能性

上述log表示畸变率与实际sensor不符合，需检查binnig参数配置。

检查对应的SensorDriver中resolution的binnig_mode是否与datasheet一致，如使用的2x2的binning mode，则对应resolution的binnning_mode配置为CUS_SEN_BINNING_2x2。

STEP2: 其他排查方法

上述STEP确认后依旧有问题，按统一步骤进行排查。

4.6.3 出现init flow error的算法log¶

4.6.3.1 现象¶

在发生该种情况时，一般会伴随着一开始参数配置失败断流或动态调整参数失败的情况。完整错误log如下：

ERROR: init flow error, please call the get_boundary_function first !!!
[MI ERR]: xxxx

4.6.3.2 排查方向¶

STEP1: 直接按统一方法排查

按统一步骤进行排查。

4.6.4 出现Crop initialization not centered per spec的算法log¶

4.6.4.1 现象¶

在发生该种情况时，一般会伴随一开始参数配置失败断流。完整错误log如下：

[eis_algo_crop_size_check] Crop initialization not centered per spec. sensor height: x
[MI ERR]: xxxx

4.6.4.2 排查方向¶

STEP1: 排查SensorDriver对应resolution是否居中裁剪

上述log表示根据SensorDriver的参数计算出目前图像在sensor crop时未居中裁剪，需检查对应配置。

检查对应resolution是否有正确居中裁剪，若无请与厂商调整SensorDriver驱动，进行居中裁剪，若有则进行下一步；
确认Sensor Crop为居中后，检查对应SensorDriver的w_x、h_y、ori_w以及ori_h是否按[IS用户指南]的要求进行配置。

STEP2: 其他排查方法

上述STEP确认后依旧有问题，按统一步骤的STEP2进行排查。

IS(Image Stabilization) DEBUG SOP¶

REVISION HISTORY¶

1. 前言¶

2. 问题快速索引清单¶

3. DIS-GME模式常见问题¶

3.1 DIS处理流程卡死¶

3.1.1 现象¶

3.1.2 排查方向¶

3.2 CMDQ Timeout¶

3.2.1 现象¶

3.2.2 抓取log步骤¶

3.3 CVS_R / CVS_W MIU HitAddress or MMU Callback¶

3.3.1 现象¶

3.3.2 抓取log步骤¶

3.4 花屏¶

3.4.1 现象¶

3.4.2 排查方向¶

3.5 无防抖效果 或 防抖效果不佳¶

3.5.1 排查方向¶

4. DIS-GYRO模式常见问题¶

4.1 DIS处理流程卡死¶

4.1.1 现象¶

4.1.2 排查方向¶

4.2 出现Gyro IS NOT Ready的打印¶

4.2.1 现象¶

4.2.2 排查方向¶

4.3 出现GYRO_IOC_CMD_xxxxxxx fail打印¶

4.3.1 现象¶

4.3.2 排查方向¶

4.4 花屏¶

4.4.1 现象¶

4.4.2 排查方向¶

4.5 无防抖效果 或 防抖效果不佳¶

4.5.1 排查方向¶

4.6 算法错误log排查¶

4.6.1 出现distor_intensity is too strong的算法log¶

4.6.1.1 现象¶

4.6.1.2 排查方向¶

4.6.2 出现Undistortion ratio error的算法log¶

4.6.2.1 现象¶

4.6.2.2 排查方向¶

4.6.3 出现init flow error的算法log¶

4.6.3.1 现象¶

4.6.3.2 排查方向¶

4.6.4 出现Crop initialization not centered per spec的算法log¶

4.6.4.1 现象¶

4.6.4.2 排查方向¶

3.5 无防抖效果或防抖效果不佳¶

4.5 无防抖效果或防抖效果不佳¶