Load MicroPython on ESP32-CAM (ESP32-D0WD-V3)

[moferreira]

I am trying to load MicroPython on a ESP32-CAM board (Winbond - ESP32-D0WD-V3). I just don't care about the camera featuers as what I want is to use the board that also have an SD slot. Following the standard instructions, I did:

esptool.py --chip esp32 --port /dev/ttyUSB0 erase_flash
esptool.py --chip esp32 --port /dev/ttyUSB0 write_flash 0x1000 ESP32_GENERIC-20240602-v1.23.0.bin

However, it does not show the REPL prompt. If I load Tasmota on the board, it works.
Can anyone give me a hint on how to do it?

[davefes]

My erase-flash command is slightly different, maybe worth trying:

esptool.py --chip esp32 --port /dev/ttyUSB0 --baud 460800 write_flash -z 0x1000 ESP32_GENERIC-20240602-v1.23.0.bin

Are you using a FTDI programmer on UOR and UOT??

[moferreira]

I also tried before your suggestion, but did not work. This board has a "hat" so called ESP32-CAM-MB that has a UART to USB interface. That is the way I am loading MicroPython (and others like Tasmota).

[shariltumin]

You can try to detect the ESP32-CAM board from the "downloader" board. Connect the CAM board to a USB to TTL serial adapter set to 5V. Connect the 5V and GND of the TTL serial adapter to the 5V and GND of the CAM board. Connect the TXD of the TTL serial adapter to U0R of the ESP32-CAM, the RXD of the TTL serial adapter to U0T of the ESP32-CAM.

[moferreira]

I don't believe the problem is communication... For example, I can get info about the ESP if I run esptool.py --port /dev/ttyUSB0 chip_info; I can flash erase it. So it must be something else. If MicroPython has it REPL set to UART0, then I should get if the firmware is working ok.

[shariltumin]

If you have 4 male-to-female Dupont wires you can use your "downloader" board. You have to connect 5V, GND, U0R and U0T one-to-one to your ESP32-CAM. Be careful not to cross the 5V and GND. The problem is that while the ESP32-CAM is mounted to the "downloader" board the GPIO00 is held low. When the GPIO00 is low the ESP32-CAM is in download mode. The esptool.py works while GPIO00 is low.

[moferreira]

That is a good hint, thank you! As I have more then one hat (downloader), I will see how to cut the GPIO00 connection that makes it down. Then I will post here the results. As it may take a while, I kindly ask the community to wait for the results.

[moferreira]

Not a solution. The hat board I have keeps GPIO00 on (up). It will go down when I press the "IO0" switch on the hat board.

[moferreira]

For those wiling to help... Tasmota and ESP-IDF are ESP32-D0WD aware. MicroPython does not seems to be.

git clone https://github.com/micropython/micropython.git
git clone https://github.com/arendst/Tasmota.git
git clone https://github.com/espressif/esp-idf.git
grep -Rnw . -e 'D0WD'
./Tasmota/tasmota/tasmota.ino:411:    if (pkg_version <= 3) {   // D0WD, S0WD, D2WD
./Tasmota/tasmota/tasmota_support/support_esp32.ino:774:          else if (rev3)   { return F("ESP32-D0WD-V3"); }    // Max 240MHz, Dual core, QFN 5*5, ESP32-WROOM-32E, ESP32_WROVER-E, ESP32-DevKitC
./Tasmota/tasmota/tasmota_support/support_esp32.ino:775:          else {             return F("ESP32-D0WD"); }       // Max 240MHz, Dual core, QFN 5*5, ESP32-WROOM-32D, ESP32_WROVER-B, ESP32-DevKitC
./Tasmota/tasmota/tasmota_support/support_esp32.ino:779:          else {             return F("ESP32-D0WD-OEM"); }   // Max 240MHz, Dual core, QFN 5*5
./esp-idf/components/esp_psram/esp32/esp_psram_impl_quad.c:893:        ESP_EARLY_LOGI(TAG, "This chip is ESP32-D0WD");

[davefes]

I don't know if ES32-DOWDQ6 fits the requirements. This is what I get for a generic ESP32-WROOM. I have seen some (revision v3.0) chips.

dave@davef:~$ esptool.py  --chip esp32 chip_id
esptool.py v4.7.0
Found 33 serial ports
Serial port /dev/ttyUSB0
Connecting....
Chip is ESP32-D0WDQ6 (revision v1.0)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 40:91:51:9b:b2:fc
Uploading stub...
Running stub...
Stub running...
Warning: ESP32 has no Chip ID. Reading MAC instead.
MAC: 40:91:51:9b:b2:fc
Hard resetting via RTS pin...

[moferreira]

esptool.py  --chip esp32 chip_id
esptool.py v3.3.4-dev
Found 2 serial ports
Serial port /dev/ttyUSB0
Connecting.....
Chip is ESP32-D0WD-V3 (revision v3.1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: e4:65:b8:70:98:78
Uploading stub...
Running stub...
Stub running...
Warning: ESP32 has no Chip ID. Reading MAC instead.
MAC: e4:65:b8:70:98:78
Hard resetting via RTS pin...

[davefes]

So,can we say that Micropython is DOWD aware?

[moferreira]

Not sure... The reality is that I can load Tasmota and it will work. When I load MicroPython it doesn't. I am struggling to find a solution as this board has a low cost while it includes an SD adapter. I have a project where I would like to save data locally to a SD card and send the data via MQTT to another machine, in this case a Homeassistant.

[scruss]

I am trying to load MicroPython on a ESP32-CAM board (Winbond - ESP32-D0WD-V3).

If your ESP32-CAM board has SPIRAM (most of them do), you'll likely want to use the SPIRAM version of the binary, rather than than the generic one.

[moferreira]

I guess I found what the problem is. You can read at https://docs.espressif.com/projects/esp-idf/en/latest/esp32/get-started/establish-serial-connection.html:
For some serial port wiring configurations, the serial RTS & DTR pins need to be disabled in the terminal program before the ESP32 booting and producing serial output. This depends on the hardware itself, most development boards (including all Espressif boards) do not have this issue. The issue is present if RTS & DTR are wired directly to the EN & GPIO0 pins. See the esptool documentation for more details.

The problem is that the ESP32-CAM-MB (USB module for ESP32-CAM) has diodes connected to DTR/RTS of the CH430C. Tasmota code prevent them from being low when booting. I "guess" (let me repeat "I guess") that MicroPython do not care about it and then the ESP32-CAM, using ESP32-COM-MB, will always enter into flashing mode when it boots.

I will test it using a standard FTDI based adapter and see if it works.

[shariltumin]

What you wrote above is correct. The "downloader" or hat will prevent MicroPython REPL from running. This is why I suggest trying to detach the ESP32-CAM form it and use 4 wires to connect to it instead.

However, I have found a workable solution for this.

Here is a simple reset script you can try "reset_board.py":

import argparse

parser = argparse.ArgumentParser()
parser.add_argument('port')
args = vars(parser.parse_args())

from esptool.loader import ESPLoader
from esptool.reset import (
    CustomReset,
)

u = ESPLoader(args['port'])
rst = CustomReset(u._port, "R0|D0|W0.5|D1|W0.1|D0|R0") # reset to DTR high state
rst()
u._port.close()

Now open a terminal and run

tio /dev/ttyUSB0

or

mpremote u0

and from another terminal you run the script

python3 reset_board.py /dev/ttyUSB0

You will see a poweron reset messages and MicroPython REPL.

[moferreira]

Thank you! You solved the problem, using your script I can gain access to the Python prompt.
I am not sure if it is possible but the MicroPython source code should include this to avoid such cases.
For the general knowledge, please find below the ESP32-CAM-MB.