[買到就上手] ESP32-CAM-MB

相信大家都曾接觸過或至少聽過 ESP32-CAM 這個具備超高性價比的 ESP32 視訊開發平台，話說原廠 Ai-Thinker 為了兼顧開發與產品化及成本等各方面的考慮，一開始就採用主板與燒錄器分開的設計。可以理解其設計理念，但是在燒錄時必須要自行接線，對於新手在開發實驗時還是有點困擾，因此就有它廠仿效這個主板又加上了一個燒錄器底座的設計，在進行燒錄韌體時就會方便許多。

不過我們建議在實際使用時必須要留意一些眉角...

確認已經安裝了 CH340 的驅動程式

近年來的開發板追求價廉物美，很多都採用 CH340 作為 USB 轉 UART 通訊、燒錄介面的晶片，驅動程式可以透過 http://www.wch.cn/download/ch341ser_exe.html 下載，支援了大多數常見的開發平台。

更新：最近我們發現不知道是缺料？改版？還是山寨晶片的緣故，有些燒錄底座上的 CH340 晶片沒有料號絲印，兩個版本行為似乎有點不一樣。以後會再行驗證...

Ai-Thinker 原廠鏡頭主板標準燒錄過程

如果你手上的鏡頭主板是 Ai-Thinker 原廠生產的版本，其 pinout 應該是如下示意圖。

在ㄦ燒錄時需要外掛一個 USB 轉 TTL UART 轉接板作燒錄器，採用如下接線方式

那個 IO0 (也可以稱為 BOOT)，是用來控制 MCU 是否進入燒錄模式的判斷依據，使用方式為按住 BOOT 鍵後再按 RST (Reset) 鍵，這是在很多 MCU 的 DFU (Device Firmware Upgrade) 設計中經常會運用到的一種機制。MCU 在重置時會透過讀取某個 BOOT pin 的狀態，以判斷是否進入下載/燒錄模式、還是運行既有的韌體。

至於進行下載燒錄時需要的操作大概如下：首先在 PC host 端先啟動 IDE 燒錄動作或是運行燒錄工具，此時 PC host 端會進入等待燒錄裝置回應，其實就是等待使用者按下 ESP32 的 RST 進入 DFU，因為這時 IO0 已經被接到 GND 了，reset 後的 ESP32 執行 BOOTROM 時就判斷要進入燒錄模式，會透過 UART 去回應 PC host 端燒錄請求，進而下載 PC host 端的新版韌體逕行燒錄。燒錄完後會立即運行新版韌體，使用者隨即檢驗韌體程式是否如預期行為。

如果燒錄後使用者需要再次運行已經燒錄進去的韌體，此時需要拔掉 IO0 與 GND 之間的跳線帽、再按 RST 重置，否則就會不斷地進入燒錄模式。

ESP32 Series Datasheet Page 21 歸納了 ESP32 在 power-on-reset 時用到所謂 Strapping Pins 的設計。

During the chip’s system reset release (power-on-reset, RTC watchdog reset and brownout reset), the latches of the strapping pins sample the voltage level as strapping bits of ”0” or ”1”, and hold these bits until the chip is powered down or shut down.

也就是在 ESP32 在 reset 被拉起的當下會把這些 pins 的值在 GPIO_STRAPPING 裏面，Table 5 則詳細列舉這些 pins 在 power on reset 時的確切作用。

新手或懶人救星 ESP32-CAM-MB

因為新手和懶人經常會對上述接線及操作順序感到困惑、過於繁瑣，因此就有它廠廠商進行改良，讓使用者不必煩惱接線，而且將燒錄動作自動化，可以直接在 PC host 端掌控一切燒錄動作，就弄出來了 ESP32-CAM-MB。

思路是由於 PC host 端會透過 USB 轉 UART 轉接器發出燒錄請求，所以可以弄一個小硬體過濾這個燒錄請求，自動拉低 IO0 然後再自動拉低 RST 一下，不就省得使用者動手了嗎？

不過原廠並沒有把 RST 訊號拉出來以供外部控制，所以廠商就在既有的設計上修改了一個算是多餘的 GND 的線路如下圖，副廠的 ESP32-CAM 標示 GND/R 的那根 pin 其實就是拉出來的 RST 控制線

這樣一來，燒錄座就能接管 IO0 和 RST，在 PC host 端自動操作燒錄所必備的一系列動作了！

不過因為是利用現成便宜的 USB 轉 UART 晶片，無法程式化去掌控每一個細節動作。所以有一些需要使用者特別留意、或是自行設法排除的小瑕疵貨問題，列舉如下列幾項：

以 ESP32-CAM-MB 燒錄器去燒錄 Ai-Thinker 原廠主板時需要特殊按鍵

手動方式是：在 PC host 端燒錄工具等待回應時，先按住 ESP32-CAM-MB 本身的 IO0 按鈕，然後再按一下 ESP32-CAM 鏡頭主板（注意是鏡頭主板、不是燒錄器）上的 RESET 按鈕，這樣就能夠順利燒錄。原因在先前已經解釋過，這是原廠模組的線路設計限制。

透過 USB 連線模擬 UART 功能時可能需要特別設定

再透過一些終端機模擬工具監看輸出訊息時，發現訊息會有卡住或是亂碼的狀況，而在 Arduino IDE 中卻不會有這種怪現象。結果爬文發現這些無法正常運作的終端機模擬工具應該是動到了 USB 轉 UART 通訊晶片上的 RTS 與 DTR，必須要保持 DTR 與 RTS 拉低才可以正常工作，以 picocom 為例：

1picocom --b 115200 --lower-dtr --lower-rts /dev/cu.wchusbserial14320  

因為 ESP32-CAM-MB 燒錄器偷偷在 USB 轉 UART 傳輸動作上做了手腳，這個部分又涉及到 PC host 端的通訊軟體設定，必須要實際測試在開發環境中是否能夠正常工作。

目前發現就是 Arduino IDE 中的 Serial Monitor 工具似乎能夠通吃，所以必要時可以派它上陣應急，否則就得花點時間調整序列通訊工具的設定囉！

修改 ampy 工具

如果你為了配合 CircuitPython 或 MicroPython 使用，有用到了 adafruit-ampy 這個配套工具，但是發現有無法傳輸的問題，可以參考下列 patch 修改 ampy 源碼，再手動安裝修正過的 ampy，就能夠順利與 ESP32-CAM-MB 通訊：

 1diff --git a/ampy/pyboard.py b/ampy/pyboard.py
 2index 0a9ed95..afb8340 100644
 3--- a/ampy/pyboard.py
 4+++ b/ampy/pyboard.py
 5@@ -131,6 +131,8 @@ class Pyboard:
 6             for attempt in range(wait + 1):
 7                 try:
 8                     self.serial = serial.Serial(device, baudrate=baudrate, interCharTimeout=1)
 9+                    self.serial.rts = False
10+                    self.serial.dtr = False
11                     break
12                 except (OSError, IOError): # Py2 and Py3 have different errors
13                     if wait == 0:

燒錄器 POR (Power-On-Reset) 行為

ESP32-CAM-MB 的設計目標與價值是便利的燒錄器，讓使用者在開發階段調適 code，或是大量燒錄鏡頭模組主板韌體以供量產使用，為了簡省成本採用了現成的 USB 轉 UART 晶片。而 ESP32-CAM 鏡頭主板的設計目標是用來作為系統目標板上的影像輸入模組或 IOT 裝置的主控制器，預設情境是使用者不會把燒錄器安裝到最終產品上去，畢竟鏡頭主板只要有 5V 供電就可以動，最常見的是拿鏡頭主板搭載鋰電池供電的行動式裝置設計。

不過有一位使用者回報說想直接把燒錄器用於產品中作為供電使用時發現，部分轉接板在 USB 上電後不會自動執行使用者韌體，需要按 RST 按鍵後才會運行。我們隨機拿手邊的模組測試，上電後以三用電錶量測後發現 IO0 與 RST 維持 HIGH，目前猜想是燒錄器 USB 晶片上電後會把 RST 拉高，但當時 IO0 尚未拉高，所以 ESP32 根據前面講過的 Strapping Pins 檢查 IO0 狀態時判斷需要進入等待下載模式，因此不會去跑使用者已經燒錄的韌體。

因為對這個行為有點感興趣，因此又拿邏輯分析儀測量了一下。

ESP32-CAM 鏡頭主板插在底座上的波形如下，可以看到 RST 訊號拉起來時 IO0 已經先被拉起，但是依然進入下載燒錄模式。這裡應該有其他原因，容後再敘。

再測試了只上電 5V/GND 不接燒錄底座，此次 ESP32-CAM 的鏡頭主板上的訊號則為下圖，上電產生 3.3V 後幾乎同時，IO0 就被拉起，接著就會運行使用者程式。

後來又量測了一下不接鏡頭主板的底座，發現 USB 上電後，底座上的 IO0 與 RST 持續保持低態，與上面兩張圖做個比對，暫時假設 USB 轉 UART 晶片在上電後並未試圖去控制 IO0 或 RST，而是靠 ESP32-CAM 鏡頭主板上電後主動去拉那兩根訊號，或許底座電路板上 IO0 有較大電容拉升較慢，以至於被 ESP32 晶片判定應該進入下載燒錄模式。

因為既然作為開發燒錄用途，燒錄器並不會特別去定義這個 PoR (Power-on Reset) 行為。但是如果真有必要將燒錄器作為產品之一部分，可以參考 ESP32-CAM Product Specification 將 IO0 hanging 懸空即可（剪斷或彎折）以便開機時就能具備明確的輸入訊號，避免被誤導進入下載燒錄狀態的機會。總之，產品化前應該要確認所有 PoR 行為都被明確定義或安排妥當，避免換料時總會發生奇怪的意外狀況。

結論

ESP32-CAM-MB 在燒錄使用上堪稱方便，不過因為偷偷利用一些 CH340 通訊的特別技巧去拉扯 IO0 和 RST 達到自動化燒錄的便利性，在欠缺公開文件說明時可能會造成不便和睏惹，因此特別我們搜集資料與實驗來撰寫本篇短文以供同好們參考。

另外，如果您想在系統的目標板上燒錄與調適 code，透過上述解析之後，應該就會知道要如何拉哪幾根線到燒錄器上，就可以完成你自己的 on board 自動燒錄器啦！（其實就是右排 GPIO0, GND, GPIO3, GPIO1, 及 GND/R，並留意避免燒錄底座和目標板上的電源互相衝突）

圖片來源

All images in this article are credited to Random Nerd Tutorials

參考資料

• How to Program / Upload Code to ESP32-CAM AI-Thinker (Arduino IDE)
• Upload Code to ESP32-CAM AI-Thinker using ESP32-CAM-MB USB Programmer (easiest way)
• ESP32-CAM Troubleshooting Guide: Most Common Problems Fixed

有意購買者可至下列賣場選購

• 露天拍賣
• 蝦皮拍賣