Milk-V Duo 256M camera test locking up device

Hello,

I’m getting a weird behavior with my brand new Milk-V Duo 256M with the camera module (CAM-GC2083). I followed the instructions available on the official docs ( CAM-GC2083 | Milk-V) but the whole device stops working as soon as the last line of output is printed to the terminal (wdrLEOnly:1).

The blue blinking light stops immediately, as well as the ssh connection. I have to unplug and replug the USB cable to force it to reboot.

Here are the logs generated from the camera-test.sh command:

[root@milkv-duo]~# camera-test.sh 
[SAMPLE_COMM_SNS_ParseIni]-1950: Parse /mnt/data/sensor_cfg.ini
[parse_source_devnum]-1605: devNum =  1
[parse_sensor_name]-1686: sensor =  GCORE_GC2083_MIPI_2M_30FPS_10BIT
[parse_sensor_busid]-1714: bus_id =  2
[parse_sensor_i2caddr]-1725: sns_i2c_addr =  37
[parse_sensor_mipidev]-1736: mipi_dev =  0
[parse_sensor_laneid]-1747: Lane_id =  1, 0, 2, -1, -1
[parse_sensor_pnswap]-1758: pn_swap =  0, 0, 0, 0, 0
MMF Version:7e0cc6a08-musl_riscv64
Create VBPool[0], size: (3110400 * 3) = 9331200 bytes
Create VBPool[1], size: (3110400 * 3) = 9331200 bytes
Create VBPool[2], size: (2764800 * 1) = 2764800 bytes
Total memory of VB pool: 21427200 bytes
Initialize SYS and VB
Initialize VI
ISP Vipipe(0) Allocate pa(0x8c771000) va(0x0x3fe1c04000) size(291120)
stSnsrMode.u16Width 1920 stSnsrMode.u16Height 1080 25.000000 wdrMode 0 pstSnsObj 0x3fe2739400
[SAMPLE_COMM_VI_StartMIPI]-483: sensor 0 stDevAttr.devno 0
awbInit ver 6.8@2021500
0 R:1400 B:3100 CT:2850
1 R:1500 B:2500 CT:3900
2 R:2300 B:1600 CT:6500
Golden 1024 1024 1024
WB Quadratic:0
isWdr:0
ViPipe:0,===GC2083 1080P 30fps 10bit LINE Init OK!===
********************************************************************************
cvi_bin_isp message
gerritId:      36403          commitId:      c69c5863e      
md5:           cab880835a2ad5184de5ed7762404b84
sensorNum      1              
sensorName0    2083           

PQBIN message
gerritId:      80171          commitId:      5c9d8fc5d      
md5:           ba5a510e093ad42db6788e6c2d13169e
sensorNum      3              
sensorName0    2053           

author:        wanqiang.he    desc:          思博慧CV1812H_GC2083_RGB_mode_V1.0.0
createTime:    2023-08-04 16:48:08version:       V1.1           
tool Version:       v3.0.5.24           mode:      
********************************************************************************
sensorName(0) mismatch, mwSns:2083 != pqBinSns:2053
[SAMPLE_COMM_ISP_Thread]-95: ISP Dev 0 running!
Initialize VPSS
---------VPSS[0]---------
Input size: (1920x1080)
Input format: (19)
VPSS physical device number: 1
Src Frame Rate: -1
Dst Frame Rate: -1
    --------CHN[0]-------
    Output size: (1920x1080)
    Depth: 1
    Do normalization: 0
        Src Frame Rate: -1
        Dst Frame Rate: -1
    ----------------------
    --------CHN[1]-------
    Output size: (1920x1080)
    Depth: 1
    Do normalization: 0
        Src Frame Rate: -1
        Dst Frame Rate: -1
    ----------------------
------------------------
Bind VI with VPSS Grp(0), Chn(0)
Attach VBPool(0) to VPSS Grp(0) Chn(0)
Attach VBPool(1) to VPSS Grp(0) Chn(1)
Initialize VENC
venc codec: h264
venc frame size: 1920x1080
Initialize RTSP
rtsp://192.168.99.114/h264
prio:0
version: 1.4.0
scrfd768432 Build at 2023-12-25 01:21:44 For platform cv181x
Max SharedMem size:1658880
anchor:-8,-8,8,8
anchor:-16,-16,16,16
bbox:bbox_8_Conv_dequant
landmark:kps_8_Conv_dequant
score:score_8_Sigmoid_dequant
anchor:-32,-32,32,32
anchor:-64,-64,64,64
bbox:bbox_16_Conv_dequant
landmark:kps_16_Conv_dequant
score:score_16_Sigmoid_dequant
anchor:-128,-128,128,128
anchor:-256,-256,256,256
bbox:bbox_32_Conv_dequant
landmark:kps_32_Conv_dequant
score:score_32_Sigmoid_dequant
Enter TDL thread
Enter encoder thread
0 R:1165 B:3087 CT:2688
1 R:1464 B:2327 CT:3937
2 R:1974 B:1613 CT:7225
Golden 1464 1024 2327
wdrLEOnly:1

I’m running the latest firmware / buildroot SDK (v1.0.8) available from GitHub here: Releases · milkv-duo/duo-buildroot-sdk · GitHub

Any ideas on what could be causing this, or how to fix it?

1 Like

Same issue for me to - did you find a solution for this?

Same issue for me, this is really annoying that they cannot solve it for over two months

For me it turns out the video stream was working. The process hadn’t locked up the device, it was simply waiting for a client to connect. I connected to the stream from another machine and everything worked as expected