單元 6 · Sensor Bring-up 與除錯

6.1 上電時序（OV5647 需求）

6.2 PLL：從 XCLK 到位元流（位元級）

OV5647 由 XCLK（典型 24 MHz）經內部 PLL 產生主時脈。關鍵 register：

6.3 MIPI 介面 register

lane 數若與 DT overlay 宣告不一致 → 串流失敗。這是「驅動 vs 硬體」不一致的典型。

6.4 media 管線完整走查

- entity 3: ov5647 0-0036 (1 pad, 1 link)
    type V4L2 subdev
    pad0: Source [fmt:SGBRG10_1X10/2592x1944]

- entity 6: unicam (1 pad, 1 link)
    type V4L2 subdev
    pad0: Sink [fmt:SGBRG10_1X10/2592x1944]

看到感測器 pad 的格式 → 管線已設定。格式不匹配（source 與 sink）→ 串流失敗。

6.5 「相機沒畫面」完整決策樹

1. rpicam-hello --list-cameras
   ├─ 空 ───────────────────────────────→ 步驟 A
   └─ 有 ─┐
2. i2cdetect -y 22 看到 0x36？
   ├─ 無 ─→ 步驟 B
   └─ 有 ─┐
3. 讀 0x300A/B = 0x56/0x47？
   ├─ 錯 ─→ 步驟 C
   └─ 對 ─┐
4. rpicam-hello 預覽
   ├─ 黑 ─→ 曝光 0？AE 關？鏡頭蓋？→ 單元 10
   └─ 有畫面 ── 基本 bring-up ✅

步驟 A（list 不到）：dmesg | grep -i -E "ov5647|unicam|error"
   ├─ probe failure → 電源/clock/位址（檢查 DT）
   └─ 排線/連接器 → 重插、換排線

步驟 B（無 0x36）：上電？RESET？位址（7-bit vs 8-bit）？匯流排對嗎（22/10）？

步驟 C（ID 錯）：是別顆感測器？I2C 位址衝突？換過板子？

6.6 Register dump 完整範例

for r in 0x300a 0x300b 0x3034 0x3035 0x3036 0x3037          0x3500 0x3501 0x3502 0x3503 0x350a 0x350b; do
  h=${r:2:2}; l=${r:4:2}
  printf "%s: " "$r"; sudo i2ctransfer -y 22 w2@0x36 0x$h 0x$l r1
done

6.7 dmesg 關鍵訊號

6.8 深入：OV5647 的完整 init sequence 概念

感測器開機後不是「能用」，而是需要驅動寫入一整串 init register（時序、解析度、增益、AWB…）。ov5647.c 內含 ov5647_2lane_480Mbps 等表格，就是這份 init。

6.9 深入：幀率與曝光行數的關係

曝光時間（行數）不能超過幀總行數（frame length）。若設的曝光 > 幀長，感測器會「卡在曝光」→ 幀率掉或全黑。

# 讀曝光 register
sudo i2ctransfer -y 22 w2@0x36 0x35 0x01 r1
sudo i2ctransfer -y 22 w2@0x36 0x35 0x02 r1
# 讀 frame length（0x380E/0x380F）
sudo i2ctransfer -y 22 w2@0x36 0x38 0x0e r1

6.10 練習：完整 Bring-up 演練

1. 拔掉排線 → list-cameras，記錄「空」。
2. 插回排線 → list-cameras，確認「有」。
3. i2cdetect 讀 ID，確認 0x5647。
4. rpicam-hello 預覽，確認畫面。
5. 把每一步的 dmesg 記錄下來。

進階真實情境 Worked Example：從零開始的完整 Bring-up 除錯流程

場景：你拿到一塊新的 OV5647 客製板，接上 RPi5 後 list-cameras 為空。需要從零開始走完整決策樹。

# === 步驟 1：確認 overlay 是否載入 ===
sudo dtoverlay -a | grep ov5647
# 若空 → 加入 /boot/firmware/config.txt：
#   dtoverlay=ov5647
# 重開機

# === 步驟 2：dmesg 看 probe 狀態 ===
dmesg | grep -i -E "ov5647|unicam|error" | tail -20
# 預期看到 "ov5647 0-0036: Probing"
# 若看到 "probe failed" → 進入步驟 3

# === 步驟 3：I2C 掃描 ===
sudo i2cdetect -y 22
# 看到 0x36 → I2C 通
# 全空 → 檢查排線/電源

# === 步驟 4：讀 sensor ID ===
sudo i2ctransfer -y 22 w2@0x36 0x30 0x0a r1  # 應回 0x56
sudo i2ctransfer -y 22 w2@0x36 0x30 0x0b r1  # 應回 0x47

# === 步驟 5：PLL 暫存器快照 ===
for r in 0x3034 0x3035 0x3036 0x3037; do
  h=${r:2:2}; l=${r:4:2}
  printf "%s: " "$r"
  sudo i2ctransfer -y 22 w2@0x36 0x$h 0x$l r1
done

# === 步驟 6：出圖驗證 ===
rpicam-hello --list-cameras
rpicam-still --raw -o test.dng --shutter 20000 --gain 1

深入原理擴充：OV5647 的 PLL 與 MIPI data rate 計算

OV5647 的 PLL 暫存器決定了 pixel clock 與 MIPI data rate，兩者不匹配會導致串流失敗：

• PLL 公式：PLL_out = XCLK × multiplier / (pre-divider × divider)。假設 XCLK=24MHz、multiplier=0x69(105)、pre-divider=0x18(24)、divider=0x31(49)：PLL_out = 24M × 105 / (24 × 49) ≈ 2.14 MHz（此為示意，實際值依 mode 而異）。
• MIPI data rate：pixel clock × bits_per_pixel / lane數。2592×1944@30fps 需要 ~180Mbps/lane（2-lane），RPi5 最高支援 ~1.5Gbps/lane——綽綽有餘，但 PLL 配錯會差幾個數量級。
• frame length：total_lines = VTS（Vertical Total Size），曝光行數上限不能超過 VTS。OV5647 的 VTS 在 2592×1944 模式下約 1968 行。

診斷式疑難排解表

進階挑戰題

1. 設計一個「自動 bring-up 測試」腳本：依序執行 overlay 確認 → I2C 掃描 → ID 讀取 → PLL dump → list-cameras → RAW 拍攝，每步驟若失敗即中斷並報告根因。
2. 若 OV5647 的 XCLK 從 24MHz 改為 6MHz，PLL 暫存器需要如何調整？推導新的 multiplier/divider 組合。
3. 研究 libcamera 的 ov5647.c 驅動中 ov5647_2lane_480Mbps init table 的每一行暫存器的作用，畫出「暫存器 → 功能」對照表。

延伸閱讀

• 下一篇：單元 7 · ISP 管線深入。
• RPi 疑難排解
• 學習路線：複習全站

專案級端到端 Worked Example：一鍵自動化 bring-up 專案

場景：生產線要驗證每塊客製板，不能靠人肉一步步打指令。本專案把單元 6 的決策樹寫成自動化腳本：依序驗證 overlay → I2C → ID → PLL → 出圖，任何一步失敗立即中斷並報出根因。整合單元 6（決策樹）、3（I2C）、4（overlay）、5（出圖）。

#!/bin/bash
set -e
BUS=22; ADDR=0x36
fail() { echo "✗ FAIL: $1"; exit 1; }
pass() { echo "✓ $1"; }

# 步驟 1：overlay 就緒
dtoverlay -a | grep -q ov5647 && pass "overlay 就緒" || fail "無 ov5647 overlay"

# 步驟 2：I2C 有回應
sudo i2cdetect -y $BUS | grep -q 36 && pass "I2C 0x36 回應" || fail "I2C 無回應"

# 步驟 3：讀感測器 ID
HI=$(sudo i2ctransfer -y $BUS w2@$ADDR 0x30 0x0a r1)
LO=$(sudo i2ctransfer -y $BUS w2@$ADDR 0x30 0x0b r1)
[ "$HI$LO" = "0x560x47" ] && pass "ID=$HI$LO" || fail "ID 錯誤=$HI$LO"

# 步驟 4：PLL 快照（記錄於 log）
for r in 3034 3035 3036 3037; do
  printf "PLL %s=%s\n" "$r" "$(sudo i2ctransfer -y $BUS w2@$ADDR 0x${r:0:2} 0x${r:2:2} r1)"
done

# 步驟 5：出圖驗證
rpicam-hello --list-cameras | grep -q ov5647 && pass "libcamera 偵測" || fail "list-cameras 空"
rpicam-still --raw --shutter 20000 --gain 1 -o /tmp/bringup.dng && pass "出圖 OK"
echo "=== bring-up 全部通過 ==="

量測/驗證 SOP：Bring-up 驗證

1. 確認上電時序（AVDD→DOVDD→DVDD→XCLK→RESET）由 overlay 正確管理。
2. 跑 autobringup.sh，逐項通過才放行。
3. 手動檢查 dmesg：ov5647: Probing 與 Chip ID 訊息。
4. 讀 PLL 四 register，與 ov5647.c init table 對照。
5. 確認 MIPI lane 設定（0x4741=0x00 為 2-lane）與 DT data-lanes 一致。
6. 存 bring-up log（含 PLL 快照與出圖 RAW 的 hash）。

平台間對照：上電時序與 PLL

互動式檢核清單

• - [ ] 能背出 OV5647 上電時序六步。
• - [ ] 已建立並驗證 autobringup.sh。
• - [ ] 能解釋 PLL 四 register 的作用與檢查方法。
• - [ ] 能說出 MIPI lane 設定一致性的檢查點。
• - [ ] 能在 30 秒內用決策樹定位「相機沒畫面」。
• - [ ] 已保存一份完整 bring-up log。

第 3 輪深度加深

① Register 位元級完整工作流：OV5647 診斷性暫存器 dump

② 多層疑難排解決策樹

決策樹 A：I2C scan 找不到感測器

I2C 找不到
├─ 檢查 A：GPIO 供電是否正常
│  ├─ cam0_reg/cam1_reg = 0V → 電源 IC 異常 / overlay 未設定 power GPIO
│  └─ 供電正常 → 繼續
├─ 檢查 B：排線方向與位置
│  ├─ 排線反插 → 重插正確方向
│  └─ 正確 → 繼續
├─ 檢查 C：I2C pull-up 是否存在
│  ├─ 無 pull-up → SCL/SDA 處於 floating → 加 2.2kΩ pull-up to 3.3V
│  └─ 有 pull-up → 繼續
└─ 檢查 D：嘗試另一個 I2C bus（GPIO 0/1 vs GPIO 2/3）
   ├─ 另一個 bus 有回應 → overlay 指定了錯誤的 I2C bus
   └─ 都無回應 → 排線 / 感測器硬體問題

決策樹 B：影像有嚴重 color cast

Color cast
├─ 檢查 A：AWB 是否啟用
│  ├─ 未啟用 → tuning 檔案中 AWB 模組關閉
│  └─ 已啟用 → 繼續
├─ 檢查 B：CCM (Color Correction Matrix) 是否為 identity
│  ├─ 是 → 需設定正確 CCM 係數
│  └─ 否 → 繼續
├─ 檢查 C：光源色溫是否在 AWB 覆蓋範圍
│  ├─ 不在 → AWB 演算法收斂失敗 → 加入該色溫範圍
│  └─ 在範圍內 → 繼續
└─ 檢查 D：感測器 IR filter 是否正確
   ├─ 無 IR filter → 近紅外光干擾 → 加 IR cut filter
   └─ 有 IR filter → CCM 矩陣需針對實際光源校正

③ 量測驗證完整 SOP：系統性 Register 掃描

1. 工具：RPi5 + i2c-tools + Python script
2. 步驟：
   a. dump 全部暫存器（0x0000-0x6xxx）存為 CSV
   b. 載入已知 good register map（CSV）
   c. diff 兩份 CSV，列出所有差異位元
   d. 對每個差異，標註暫存器功能（參考 datasheet）
3. 判讀：0-5 個差異 = 正常（版本差異）；>10 個差異 = 可能有初始化不完整
4. 常見偏差：部分暫存器在不同 lighting mode 下值不同 → 非異常

④ 四平台終極對照

⑤ 完整 Bring-up 專案 Checklist

• - [ ] 建立「已知 good register map」CSV 檔案
• - [ ] 撰寫自動化 register dump script
• - [ ] 完成首次全 register 掃描並比對
• - [ ] 逐一排查差異暫存器
• - [ ] 測試不同 power-on sequence 對 probe 的影響
• - [ ] 記錄所有 I2C 通信失敗案例與解法
• - [ ] 整理除錯 checklist 供團隊複用
• - [ ] 將完整 dump 歸入版本控制