MicroPython Forum (Archive)

Posted: **Sat Mar 27, 2021 1:46 pm**

Hello,

I'm completely new to this and have recently found:

https://www.ebay.co.uk/itm/ESP32-CAM-MB ... 4204150016

which should be the same as:

https://www.amazon.com/Aideepen-ESP32-C ... 578LV?th=1

so I bought it and give it a try. Docs were clear enough and I tried flashing esp32-idf4-20210202-v1.14.bin (and some other images later), but even though flashing it was always successful according to output, I was not able to boot it at all.

Code: Select all

$ esptool.py --chip esp32 --port /dev/ttyUSB0 --before default_reset --after hard_reset erase_flash
esptool.py v3.0
Serial port /dev/ttyUSB0
Connecting.....
Chip is ESP32-D0WDQ6 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 9c:9c:1f:c8:13:f4
Uploading stub...
Running stub...
Stub running...
Erasing flash (this may take a while)...
Chip erase completed successfully in 3.1s
Hard resetting via RTS pin...

(in same cases here I removed the power and then plugged it again)

$ esptool.py --chip esp32 --port /dev/ttyUSB0 --baud 460800 write_flash --verify -z 0x1000 ./esp32-idf4-20210202-v1.14.bin
esptool.py v3.0
Serial port /dev/ttyUSB0
Connecting......
Chip is ESP32-D0WDQ6 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 9c:9c:1f:c8:13:f4
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 460800
Changed.
Configuring flash size...
Compressed 1567824 bytes to 982369...
Wrote 1567824 bytes (982369 compressed) at 0x00001000 in 22.0 seconds (effective 569.3 kbit/s)...
Hash of data verified.

Leaving...
Verifying just-written flash...
(This option is deprecated, flash contents are now always read back after flashing.)
Verifying 0x17ec50 (1567824) bytes @ 0x00001000 in flash against esp32-idf4-20210202-v1.14.bin
-- verify OK (digest matched)
Hard resetting via RTS pin...

Now after flashing it, I found online that one needs to hold the IO0 button (on the USB Programmer) pressed while powering or resetting the ESP32 board so I tried that in multiple combinations and variations, but I never got the prompt. Running $ picocom /dev/ttyUSB0 -b115200 makes it output "Terminal ready" and nothing after.

When I try to read something, I only get:

Code: Select all

$ jpnevulator --ascii --timing-print --tty /dev/ttyUSB0 --read
2021-03-26 23:12:36.138644:
65 74 73 20 4A 75 6E 20 20 38 20 32 30 31 36 20 ets Jun  8 2016 
30 30 3A 32 32 3A 35 37 0D 0A 0D 0A 72 73 74 3A 00:22:57....rst:
30 78 31 20 28 50 4F 57 45 52 4F 4E 5F 52 45 53 0x1 (POWERON_RES
45 54 29 2C 62 6F 6F 74 3A 30 78 31 33 20 28 53 ET),boot:0x13 (S

and note output gets trimmed here, I didn't remove anything.

alternatively I get nothing back or just something random:

Code: Select all

jpnevulator --ascii --timing-print --tty /dev/ttyUSB0 --read
2021-03-27 14:30:41.665467:
92 CD 28 36 5C 55 71 2B 71 70 D1 D0 E0 D2 65 5D ..(6\Uq+qp....e]
1B 6A 91 E9 F9 4A 3D 88 0A                      .j...J=..

Has anyone experience with this? Is it stuck in download mode?

Thanks,
Vedran

Posted: **Sat Mar 27, 2021 2:16 pm**

You only have to push the IO0 button and press reset, if the board does not support the espressif boot loader mechanism. Since the upload worked, all is fine. The, after reset, you should get the REPL prompt at 115200 baud. The start message looks well, so with a simple terminal emulator like picocom or tio you should be able to work.

Posted: **Sat Mar 27, 2021 7:08 pm**

I bought the same board from a different seller at ebay and I have similar issues:
After
esptool --port COM5 --before default_reset --after hard_reset erase_flash
esptool --port COM5 --baud 460800 write_flash --verify -z 0x1000 esp32-idf4-20210202-v1.14.bin

I tried to connect with putty:
putty.exe -serial COM5 -sercfg 115000,8,n,1,N

but without luck. IO0 button + RST Button does not help

Posted: **Sat Mar 27, 2021 7:20 pm**

Did you disable flow control in Putty?

Posted: **Sun Mar 28, 2021 9:07 am**

yes, flow control is disabled. Putty works for me with the same settings with different boards and different MicroPython builds but not with this board...
I just found out that the serial communication works with Arduino Serial Monitor. Does the Serial Monitor send a special character or a control sequence to the serial port?

Posted: **Sun Mar 28, 2021 9:09 am**

Does the Serial Monitor send a special character or a control sequence to the serial port?

No. It does not. Check the Putty settings again, like setting of RTS or DTR, which must be both low or high. Or try for instance TeraTerm.

Posted: **Mon Mar 29, 2021 9:36 am**

I checked the communication with a serial port monitoring ( sudt AccessPort ) and found out that the Arduino Serial Monitor is using a different IOCTL_SERIAL_SET_HANDFLOW setting (with ControlHandShake: 0x0). Putty and pySerial use the same IOCTL_SERIAL_SET_HANDFLOW (with ControlHandShake: > 0x0) and both do not work!
These are the sudt AccessPort log entries:

Code: Select all

#1. Arduino Serial Monitor (only this one works with the board)
7	10:39:00.453	0.00042870	javaw.exe	IOCTL_SERIAL_SET_HANDFLOW           	COM5	SUCCESS	ControlHandShake: 0x0, FlowReplace: 0x80000000, XonLimit: 2048, XoffLimit: 512

# putty
#2. putty setting: N = SER_FLOW_NONE
117	10:56:43.225	0.00025570	putty.exe	IOCTL_SERIAL_SET_HANDFLOW           	COM5	SUCCESS	ControlHandShake: 0x1, FlowReplace: 0x40, XonLimit: 34412, XoffLimit: 8603	
#3. putty setting: X=SER_FLOW_XONXOFF 
127	10:57:32.309	0.00038580	putty.exe	IOCTL_SERIAL_SET_HANDFLOW           	COM5	SUCCESS	ControlHandShake: 0x1, FlowReplace: 0x43, XonLimit: 34412, XoffLimit: 8603	
#4. putty setting: R=SER_FLOW_RTSCTS
136	10:58:48.808	0.00026120	putty.exe	IOCTL_SERIAL_SET_HANDFLOW           	COM5	SUCCESS	ControlHandShake: 0x9, FlowReplace: 0x80, XonLimit: 34412, XoffLimit: 8603	
#5. putty setting: D=SER_FLOW_DSRDTR
145	10:59:14.192	0.00023240	putty.exe	IOCTL_SERIAL_SET_HANDFLOW           	COM5	SUCCESS	ControlHandShake: 0x12, FlowReplace: 0x40, XonLimit: 34412, XoffLimit: 8603	

# pySerial
#6. ser = serial.Serial('COM5', 115200,timeout=2,xonxoff=False,rtscts=False,dsrdtr=False)
225	11:19:09.321	0.00028520	python.exe	IOCTL_SERIAL_SET_HANDFLOW           	COM5	SUCCESS	ControlHandShake: 0x1, FlowReplace: 0x40, XonLimit: 34412, XoffLimit: 8603	
#7. ser = serial.Serial('COM5', 115200,timeout=2,xonxoff=True,rtscts=False,dsrdtr=False)
238	11:20:13.597	0.00033060	python.exe	IOCTL_SERIAL_SET_HANDFLOW           	COM5	SUCCESS	ControlHandShake: 0x1, FlowReplace: 0x43, XonLimit: 34412, XoffLimit: 8603	
#8. ser = serial.Serial('COM5', 115200,timeout=2,xonxoff=False,rtscts=True,dsrdtr=False)
250	11:21:18.122	0.00034140	python.exe	IOCTL_SERIAL_SET_HANDFLOW           	COM5	SUCCESS	ControlHandShake: 0x9, FlowReplace: 0x80, XonLimit: 34412, XoffLimit: 8603	
#9. ser = serial.Serial('COM5', 115200,timeout=2,xonxoff=False,rtscts=False,dsrdtr=True)
262	11:22:07.298	0.00031580	python.exe	IOCTL_SERIAL_SET_HANDFLOW           	COM5	SUCCESS	ControlHandShake: 0x12, FlowReplace: 0x40, XonLimit: 34412, XoffLimit: 8603

Posted: **Tue Mar 30, 2021 6:17 pm**

Hello,

Tried few more things, but no progress. Putty hangs either with nothing on the screen or 1-2 lines of some garbage if I select Flow control: RTS/CTS.

I guess since I'm always able to upload the image (tried ~20x by now), it seems it's stuck in this mode. Would upload fail if it's in the wrong mode?

I see few people here are having issues with the device as well:

https://randomnerdtutorials.com/upload- ... am-mb-usb/

Might be a bad batch. In any case I'll keep my eye on this thread in case someone make some progess.

Regards,
Vedran

Posted: **Tue Mar 30, 2021 6:32 pm**

If the upload via esptool.py works, it indicates that the UART and RTS/DTR setting works. For using Putty, flow control must be switched off.
Otherwise the device may indeed set again to bootloader mode. You could try other terminal emulators like TeraTerm.
If you have a voltmeter, you can check the level at reset and gpio0. They must both be high (~3.3V) for proper operation.
It's a pity that no schematics are available for that board.

Posted: **Wed Apr 07, 2021 3:06 am**

Some flash can't support the QIO mode very well. Consider changing it to qout or dout mode when burning
In addition, the initial voltage of gpio12 affects the power supply voltage of flash. The common module flash is 3.3V, so it is necessary to ensure the gpio12 pull-down at the initial stage of power on, or use espefuse tool to modify the power supply options of flash

MicroPython Forum (Archive)

ESP32-CAM-MB + Development Board CH340G

ESP32-CAM-MB + Development Board CH340G

Re: ESP32-CAM-MB + Development Board CH340G

Re: ESP32-CAM-MB + Development Board CH340G

Re: ESP32-CAM-MB + Development Board CH340G

Re: ESP32-CAM-MB + Development Board CH340G

Re: ESP32-CAM-MB + Development Board CH340G

Re: ESP32-CAM-MB + Development Board CH340G

Re: ESP32-CAM-MB + Development Board CH340G

Re: ESP32-CAM-MB + Development Board CH340G

Re: ESP32-CAM-MB + Development Board CH340G