I’m trying to use a lilygo t-encoder with i2c and the only pins I have left are 2, 4, 14, 15, which are all strapping pins and the boot fails.
Is there something I can change in the configuration or hardware to use i2c on these pins?
GPIO 0
GPIO 2
GPIO 4
GPIO 5 (must be HIGH during boot)
GPIO 12 (must be LOW during boot)
GPIO 15 (must be HIGH during boot)
Hmmmm that is different to what it says here ESP32 Pinout Reference: Which GPIO pins should you use? | Random Nerd Tutorials
It’s actually the same page I got the code block info from.
It says:
However, if you have peripherals connected to those pins, you may have trouble trying to upload new code, flashing the ESP32 with new firmware, or resetting the board. If you have some peripherals connected to the strapping pins and you are getting trouble uploading code or flashing the ESP32, it may be because those peripherals are preventing the ESP32 from entering the right mode. Read the Boot Mode Selection documentation to guide you in the right direction. After resetting, flashing, or booting, those pins work as expected.
The ESP refuses to boot when it’s positioned in the holder.
Currently I have UART on GPIO 12 and 13 (not currently connected on image).
Then white cables are SCL and green SDA which is connected on 14 and 15.
I had to solder on the “wrong side” due to I need an exact height from underside to top, and cables on the underside will be uneven.
(even though the soldering looks like crap now after a few replacements of the cables there are no connections between the pins, I tested with a multimeter)
Since it’s only GPIO 15 that is strapping pin I tried to make the pin high on boot with:
i2c:
sda: GPIO15
scl: GPIO14
scan: true
id: bus_a
binary_sensor:
- platform: gpio
pin:
number: GPIO15
inverted: true
mode: INPUT_PULLUP
name: "dummy"
and forcing it high. But that didn’t work either.
The problem is that I2C only tries to function on boot, if that fails then it just gives up.
I could perhaps try and use these two pins for UART instead.
Why did Lilygo only expose the crappy pins?
I have troubleshoot it some more now.
I had and idea to move the i2c to the pins that is not strapping pins and make sure i2c works.
Then I could put UART on the strapping pins and either optocoupler the data pins or the VCC to turn it on after a few seconds after boot.
I tested my idea by using the cables that was included with the Nextion, had UART on GPIO 2 and 15 (strapping pins) left the VCC of and booted up. Worked.
Hooked up the VCC and the screen turned on and ESP connected UART. Great!
I even tried hooking up the VCC and rebooted and it worked fine too.
So I soldered all the wires to the new configuration UART to Nextion on 2 and 15, i2c on 12 and 13 and it fails to boot again.
Yet again I check the pins so that I have not messed up the soldering and shorted two, no… each pin is only connected to itself.
I connected the ESP to the computer to read the logs via cable and I get this repeating message:
rst:0x10 (RTCWDT_RTC_RESET),boot:0x3b (SPI_FAST_FLASH_BOOT)
invalid header: 0xffffffff
invalid header: 0xffffffff
invalid header: 0xffffffff
invalid header: 0xffffffff
invalid header: 0xffffffff
invalid header: 0xffffffff
invalid header: 0xffffffff
ets Jul 29 2019 12:21:46
Searching for invalid header 0xffffffff I got a few forum posts with the same issue and in short the issue was resolved with:
In summary for other people with this issue,
Make sure Pin 8 is pulled high, pin 9 is connected to boot, and I recommend using an esp32 with the module removed to program a esp32C module if you are having issues programming your board.
I don’t even have pin 8 or 9 exposed.
I have no ideas, but I am interested in the board. Does it have any advantages over an ordinary rotary encoder + esp?
It’s combined so smaller.
Apart from that, no.
Since I bought it and I needed a rotary encoder and ESP for this project I figured I would give it a chance.
Thanks, it does look nice (and before someone corrects me, it also has leds and a buzzer).
Yes, two LEDS and buzzer and incorrect datasheets.
All images of it has the pins in the wrong place.
Edit, and the pins are slightly the wrong distance so you need to force it down on breadboards.
Sorry to revive an old thread but I have exactly the same problem.
I have a SCD30 soldered to an ESP32 2102 (pinout) but I just realised that I’ve connected the I2C pins to the strapping pins (GPIO15 and 2). So now I’m getting a bunch of errors on start up:
[C][i2c.arduino:092]: Recovery: failed, SDA is held low on the bus
[I][i2c.arduino:096]: Results from i2c bus scan:
[E][i2c.arduino:104]: Unknown error at address 0x08
[E][i2c.arduino:104]: Unknown error at address 0x09
[E][i2c.arduino:104]: Unknown error at address 0x0A
...
Is there a way to make this setup work? FWIW a similar setup on another board works with just different GPIO pins.
One idea I have is to delay the I2C bus scan or the SCD30 sensor setup until after the boot up as I assume the strapping pins are only pulled at the start up. But I can’t seem to find any ways of doing this from the EPSHome docs. I also tried to set scan to false on the i2c config but I still got the same error:
[W][scd30:131]: Unable to read sensor firmware version
[E][component:082]: Component scd30.sensor is marked FAILED
I’d appreciate any help on this.
You should re-do your soldering to other pins.
Fair. I didn’t want to use wires so I just soldered them together using single row pin header. This doesn’t seem like it should be fundamentally impossible but probably just easier to re-do the soldering. Thanks!
Next time you order more components online, i’d suggest you order some patience as well… Slow down and test your setup on a breadboard first. You’ll eliminate most if not all mistakes like this. The log tells you in plain, simple english what the problem is and delaying the i2c scan and your other ideas arent going to make a difference because they dont even attempt fixing the gpio pulled LOW problem
If you use that patience and read the i2c documentation, it tells you in the first paragraph that SDA & SCL are pulled HIGH automatically with the internal pull-ups.
Your sensor/s you wired to the i2c bus is pulling SDA LOW or perhaps you’ve got a short to Gnd pulling it.
Always read the documentation first and especially if your following someones guide they posted online. People tend to put complete trust in online guides and follow them blindly. Thats a bad idea…
While I agree with your sentiment for more testing, there’s probably no need for the snarky comment…
I did carefully check the soldering using a multimeter and I’m pretty confident the SDA line wasn’t shorted to GND. After desoldering the sensor from the board, and reconnecting it to different pins on the same board (using dupont cables this time), it did manage to work. So I doubt the problem was with the soldering or the sensor itself. (I even tried connecting the pins to a different ESP32 board before desoldering and managed to get that to work too.)
As for why the SDA was held low, my guess is that according to this reference
D2 must be LOW during boot and also connected to the on-board LED
So I’m assuming some template code pulls down GPIO2 on boot. I tried to find it in the repo but didn’t manage to (eg. here’s where the strapping pins are defined) so maybe this is coming from some arduino code. Note that GPIO2 can be pulled up after boot (tested using multimeter) by doing something like
on_boot:
- priority: 700
then:
- output.turn_on: sda
But in any case, I agree I should’ve done more testing. I made a similar setup on another board about a year ago and I was just trying to replicate it without noticing the dev board was slightly different this time. In the end I just connected it to a M5Stack Atom Lite and called it a day.