Posts made by stoney

@ajb2k3

Huh ?

192.168.4.1/jpg_stream

Does not work

Then next post you say it works ? You are being confusing lol, you can edit the posts if you want..

@ajb2k3

ohhhh...

you have a typo in your "faulty post" , I thought you meant is was messy soldering but works.

I must have recieved a faulty unit. the led next to the camera does light up

@ajb2k3

the schematic can be found on this page https://github.com/m5stack/M5Stack-UserGuide/blob/master/ESP32CAM.md

The empty footprints are bottom left of page 2, the MPU60x0 (gyro ) and SPQ2410HR5H which appears to be a microphone. I might try fitting an electret later and connecting it to pad 4, gain might be an issue though.
I have seen old ads for them listed with the extra parts fitted for 3 times the price of this module, I think now sold out.
The flux is normal and no big deal, if the LED works then it is not shorted by solder blobs, mine did not come with a lens cover either, the price for the entire module with ESP32 is cheaper than what I can buy the camera for, not expecting gold class here :)

oh, the "demo" software as mentioned by jeff above sets it up in access point mode and then you can open either 192.168.4.1/jpg for a single image grab or 192.168.4.1/jpg_stream for a live feed

the firmware is also on the page I linked, the page was branched from a previous demo by igrr and nothing has been edited so it does not properly explain either the hardware setup or the firmware, ie .. there is no ascii image output..

finally have some time to continue on with this, I tried the esp32 download tool with exactly the parameters above and the demo files and I am getting an error in the CMD window of ..

"imageIsOk()" failed at ....\src\msw\bitmap.cpp(922) in wxBitmap::CreateFromImage(): invalid image

even if I only select the bootloader.bin section or any single part. odd .. so I looked at using the esptool.py supplied and copied the loader script from the flash.sh (made for linux), that works but I get exactly the same failed to connect as I do with platformio and also the same timing looking at pulseview, not surprising since both methods rely on esptool.

So I ended up adding a 100nF between the B-E of VT1, oddly enough I cannot see any improvement in the timing on pulseview but it programmed first attempt and every one thereafter so I am leaving it in place. perhaps the timing the ESP sees is a little different to what my salaea clone probe is showing.

I have been looking a bit closer at this and trying to make sense of it with and I think there is a simple design error but it should still work.

this is the WROVER kit control logic ..

and this is the M5CAMs

so it looks like VT2 is reversed but it should still work regardless, it might be affecting the timing perhaps ?

Using platformio with no mods and the WROVER kit board selected a close look at the reset timing shows that the EN line is always taken high (by about 500nS) after GPIO0 is also taken high, hence it never enters boot mode. I think I can get around it by hacking the esptool.py .. but its late now, 4am, so it can wait till tomorrow.

a failed program attempt ..

and a close up of one of the edges shows GPIO0 always going high about 500nS-1uS before EN goes high.

Hi people, sorry for the messy post, I am not sure how to format here yet. I am sure this wont be my last post.
I have recompiled the M5CAM_demo in atom/platformio after a few hiccups and am getting the following error (verbose upload)

*CURRENT: upload_protocol = esptool
MethodWrapper(["upload"], [".pioenvs\esp-wrover-kit\firmware.bin"])
Auto-detected: COM40
"c:\users\col.platformio\penv\scripts\python.exe" "C:\Users\Col.platformio\packages\tool-esptoolpy\esptool.py" --chip esp32 --port "COM40" --baud 921600 --before default_reset --after hard_reset writ
e_flash -z --flash_mode dio --flash_freq 40m --flash_size detect 0x1000 C:\Users\Col\Documents\PlatformIO\Projects\M5CAM_demo.pioenvs\esp-wrover-kit\bootloader.bin 0x8000 C:\Users\Col\Documents\Platfo
rmIO\Projects\M5CAM_demo.pioenvs\esp-wrover-kit\partitions.bin 0x10000 .pioenvs\esp-wrover-kit\firmware.bin
Serial port COM40
Connecting......................................_____

A fatal error occurred: Failed to connect to ESP32: Timed out waiting for packet header
*** [upload] Error 2*

The autodetected port is correct, opening it in realterm and toggling camera power.

ets Jun 8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:5780
load:0x40078000,len:0
load:0x40078000,len:15412
entry 0x40078630
I (28) boot: ESP-IDF v3.1-dev-1101-g1f7b41e2-dirty 2nd stage bootloader[
0m
I (28) boot: compile time 10:53:23

This is my first time attempting to reprogram this and a search has not brought up anything useful, is there a trick to programming these ? It looks to me that perhaps the reset method is unsuccessful, tried holding the power button down, tried with a lithium cell connected/disconnected. The M5CAM uses the same program method as the wrover-kit so far as I can see from the schematics.

Any ideas for things to try ?
A little trickier to add jumpers to toggle pins with these boards.