TTGO T-Camera v1.6 with MIC - boot loops #405
Comments
|
Hi there. I have the same issue with new TTGO Cameras boards. It is occuring with the TTGO Camera With Microphone. The GPIO pinout is completly different from the regular TTGO Cam (without microphone). I confirm the configuration to be as follow : The PIR and I2C parts are working fine. The GPIO for the PIR is wrongly adverstised as 33 by the sellers while it is 19 indeed. As soon as the camera definition is added the board boot loops. Also on compilation I have the following warning message : It seems that the driver has an issue with the board as I have checked 10 times the GPIO pinout and it seems to be correct. I've found more info including the detailed board schematics here : https://github.com/lewisxhe/esp32-camera-series |
|
I got it working with the following conf except that I get constant disconnections from the Esphome API. As the esp32_camera relies upon the esphome api it is pretty unusable so far : |
|
Confirming, code boots successfully and executes as expected so long as esp32_camera is not defined in the YAML. :( |
|
Did not mean to close the issue. Hope to work with others to resolve this obvious pin assignment / definition issue with these boards. Confirming GPIO19 is correct assignment for PIR sensor and NOT GPIO33. |
|
Other boards work fine with ESP32 Camera - So to me it sounds like it is an issue with pin numbers indeed. |
|
Lewis Xhe also provided an updated electrical schematic for this 20190228 OV2640_V1.6 board. Page 5 of 6 details the OV2640 connections: |
|
So sorry to again accidentally close this research issue. Re-opening until correct pin assignments are verified. |
|
FYI, the silk-screened PCB ID for this camera is OV2640_V1.6 20190228 SIO_CLK=IO23 We know the photo/graphic on the board case is incorrect, specifically for the PIR sensor. It appears all the pins for the LED display are correct. Could the silkscreen on the PCB be incorrect, as well? |
|
Began to wonder if the boards were defective, so decided to load Lewis Xhe's demonstration program tailored for this board. It works perfectly. https://github.com/lewisxhe/esp32-camera-series These are the pinout definitions from his INO sketch source file, which seem to agree with our assignments. I suspect his comments regarding conflicting libraries and patching them may be the answer to this issue. |
Could you link to that? |
Doh! Certainly. Lewis's comments seem to be more about the Adafruit BME280 library, which should not impact this board. Although he does have comments regarding I2C, they're not specifically about conflicts. I checked the arduino-esp32 page, and they still have not yet added this specific board to their list. Looks like I may have to start with the recent TTGO T-Camera change, alter it for this v1.6 board, and then submit it to the arduino-esp32 project: Or it could be related to Fix #2744 Thank you, Otto, for your support while we figure this one out! :) |
The board selection is not related to this issue - board only changes some basic things like memory size/pin aliases. |
keith721
changed the title
|
Checking this patch from Kevin Hester and wondering if this might be the case for this board? |
|
Added the right push-button as a GPIO binary sensor, along with the PIR sensor. They both initialize properly, then the boot loop begins. This configuration finally halted. It still appears Core 1 is the culprit, if that helps any. I was reading other threads and web pages today regarding ESP32 multi-core coding. Rather a touchy thing, depending on how your code is assigned to one core or the other, and whether they attempt to share areas of code and/or data. |
|
@OttoWinter I'm willing to use VSCode, PlatformIO, and anything else necessary to attempt debugging on WIndows 10 with this board. My first attempt yesterday did not go well :( but I'm very willing to try again. Any hints, tips, or suggestions would be greatly appreciated. Thank you! |
|
Hi Keith I manage to get these working using 1.13.3 It is stil very weird. The board sometimes goes into OTA, sometimes sends a panic, sometimes bootloops. The weirdest thing is that it can get to work after 3 or 4 hard reset by unplugging replugging the USB. Once it is properly started I can see them in Home Assistant, get the PIR and the Camera. I have no idea why rebooting it a number of times changes something but I suppose it sends the board into a specific mode... Anyhow, it is not likely a board defect, or at least not a single one, as I have 2 of these and they behalve similarly. I have tried to erase flash using esptool and also I have to unplug and replug them several times in order for the flash erase to succeed. I must add that I have not been able to start them properly using 1.13.4 or 1.13.5 no matter how many times I reboot them. My YAML is as follow : I am quite certain that the GPIO pins are correct for this board. You can try without the video part and it should work just fine for PIR and I2C. Also I have confirmed that from time to time I can get a proper picture in Home Assistant. It looks like something rather low level is triggering a bad reboot most of the time. The most common error I grab is : Hope this can help finding out the solution... |
|
This may be interesting : |
|
I suspect the esp-cam code to cause an issue while trying to acces the PSRAM through I2C. [esp32-hal-psram.c:47] psramInit(): PSRAM enabled This line only appears when the camera is declared in the YAML and it should be adressed through i2c_pins: |
|
I'm guessing it's this code in src/esphome/components/esp32_camera/esp32_camera.cpp that attempts to pin the camera task to Core 1, which is what's faulting. Seriously, just a guess. Noting one significant difference between this TTGO T-Camera and the diymore.cc variants of the original ESP32CAM, this TTGO T-Camera has an earlier version of the ESP32 processor: whereas the diymore.cc ESP32CAM is this processor: |
|
I believe the only difference between Q5 and Q6 is the package. |
|
@keith721 No, that's probably not it - yes the task is pinned to core 1 but the code in the created task is properly protected with mutexes. (And if that were the issue, it would fail with all ESP32 camera boards) |
|
@OttoWinter I sent email to you this week. If you're willing, I'll send one of these camera boards to you for research. |
|
I took another look at Lewis Xhe's Arduino sketch (which has supporting CPP source files) and saw a second use of the TTGO_OV2640_V16 macro I did not previously notice. Could this be part of the issue?
|
|
I inserted those two pinMode commands for GPIO13 and GPIO14 into the beginning of the /config/esphome/ttgo_cam01/src/main.cpp source code file, and can now successfully compile, load, and run using this TTGO T-Camera V1.6 w/MIC board. X^D Still a bit of instability after this, so added same pinMode call for GPIO15 as well. So far, so good. WIll continue testing and reporting back here. |
|
Great work Keith. I'll try this now... |
|
Yes I confirm a signicative improvement. My cams are much more stable and are able to reboot every time which was my main concern as I had plug/unplug them several times in order for them to connect. Since I applied your patch, I can unplug them and they will come back to life everytime, and show their sensors in HA. Great job ! |
|
Following this up, the wifi performance is still a bit unstable. Checking the other low-order GPIO pins used, I'll add GPIO12 to that list, and see if it gets better. Worst thing that can happen is no change. No real change. OTA updates still fail consistently. :( |
|
I confirm that your changes in the file "/ttgo_cam01/src/main.cpp":
do solve the problem for me. I'm located close to my wifi router though so cannot confirm the signal problems, even OTA updates work without any problems for me and there are no errors in the log. This is my configuration.yaml Keep us posted about future improvements but at least the camera is usable now. |
|
Re: wifi performance and OTA updates, I suspect the PCB trace antenna on my board is not connected. I'll need to visually confirm this because there is no U.FL connector socket there. |
There is no U.FL connector on my board (with mic) either, however a small printed camera connected through two golden pins appears to be soldered to the ESP32, should be ok. |
|
The RF output of the ESP32 chip appears to be connected to the R15 PCB trace antenna. The zero-ohm jumper is so ridiculously tiny it's almost impossible to see. |
|
Since we've identified and corrected the source of this camera board's crash, AND identified the proper pin for the PIR sensor, I believe it best to close the thread. A HUGE thank you to @OttoWinter for his fantastic ESPhome package and patience with allowing users of this TTGO T-Camera board to figure it out here. Good luck to everyone! |
Operating environment/Installation (Hass.io/Docker/pip/etc.):
Intel Core i3 NUC, Debian Server, Docker, Hass.IO
Linux hassio 4.9.0-6-amd64 #1 SMP Debian 4.9.88-1+deb9u1 (2018-05-07) x86_64
Docker version 18.09.1, build 4c52b90
Home Assistant 0.93.2
ESP (ESP32/ESP8266, Board/Sonoff):
ESP32, TTGO T-Camera
https://www.amazon.com/gp/product/B07RY29WM6/
TTGO Micro-32 V2.0 Wifi wireless Bluetooth Module ESP32 PICO-D4 IPEX
FYI, the silk-screened PCB ID for this camera is OV2640_V1.6 20190228
Affected component:
https://esphome.io/components/esp32_camera.html
Description of problem:
Upon download of firmware.bin to ESP32, board repeatedly fails to boot, falling back to safe boot mode. At this time, it successfully inits wifi and waits for OTA download.
Problem-relevant YAML-configuration entries:
Traceback (if applicable):
Additional information and things you've tried:
Disabled I2C, disabled I2C display, minimized the YAML to only esp32_camera configuration. Double-checked pin assignments.
Tried multiple 5VDC power supplies.
Failure occurs with two separate TTGO T-Camera boards.
The text was updated successfully, but these errors were encountered: