ESP12F - how to correctly set up I2C on GPIO 5/14
Posted: Mon Jun 03, 2019 2:25 pmWe have some serious trouble setting up our custom PCB/assembly with the ESP8266 ESP-12F on it, and I really really hope someone can give us some hints on this.
Briefly, we were working in iterations of a board and what we did was creating a single I2C bus with a BNO055 and an MPL3115A2 which connect to GPIO2 (SDA) and GPIO14 (SCL) of an ESP-12F, all of the sensors and the ESP powered up simultaneously on applying VDD. In iteration #1 that was actually working flawlessly - we were able to flash the board and boot the software and also retrieving data worked. Btw, we used expressif@1.8 and the wire library to drive the I2C, plus some additional code for BNO and MPL.
In iteration #2 we kept everything the same and changed some wiring elsewhere, however, now we are completely stuck. It seems that the powering of the sensors brings GPIO2 into a state that neither allows booting nor flashing (we did not see this behaviour in iteration #1, thus we also did not realize the conceptual flaw). Just now we learned that using GPIO2 is a BAD idea.
Ok, on applying power, we can actively see the sensors sending data over I2C (using an oscilloscope) - just as it should be and GPIO2 seems to be the I2C master (?) - however, obviously the boot process crashes constantly with "Fatal Exception". To move forward and actively flash the board, we had to physically cut the I2C data bus to GPIO2 to get the board into flash/boot mode at all. As expected, the ESP then behaves as it should, but the bus is cut obviously, so no data. Now, here's what we tried given GPIO2 was cut:
1) cut power to the sensors, reestablish GPIO2 connection, establish power to sensors after booting, and use Wire.begin(2,14) as before. The result: there is no data sent over I2C. We clear the bus and we run into "SDA data line held low" with no chance to get out of this any more...
2) just rewire the SDA to GPIO5, and change the pin in the software with Wire.begin(5,14). The result: I2C does not come up, same problem with "SDA data line held low" as with GPIO2, no way to recover from this any more... (well, at least the board boots and does not get stuck in the fatal exception).
The big question is - why does it supposably work on GPIO2 causing the boot race condition, but does not work if we use GPIO5? We have read LOTS of forum entries and other comments with respect to the I2C and ESP12. Some pages say you can Quote "use pretty much any pin for I2C", however, after playing around with reset/clean/startup writes/reads from the new SDA pin 5, we are out of ideas, so any help on how to correctly set up the I2C bus given a booted board would be highly appreciated.
Briefly, we were working in iterations of a board and what we did was creating a single I2C bus with a BNO055 and an MPL3115A2 which connect to GPIO2 (SDA) and GPIO14 (SCL) of an ESP-12F, all of the sensors and the ESP powered up simultaneously on applying VDD. In iteration #1 that was actually working flawlessly - we were able to flash the board and boot the software and also retrieving data worked. Btw, we used expressif@1.8 and the wire library to drive the I2C, plus some additional code for BNO and MPL.
In iteration #2 we kept everything the same and changed some wiring elsewhere, however, now we are completely stuck. It seems that the powering of the sensors brings GPIO2 into a state that neither allows booting nor flashing (we did not see this behaviour in iteration #1, thus we also did not realize the conceptual flaw). Just now we learned that using GPIO2 is a BAD idea.
Ok, on applying power, we can actively see the sensors sending data over I2C (using an oscilloscope) - just as it should be and GPIO2 seems to be the I2C master (?) - however, obviously the boot process crashes constantly with "Fatal Exception". To move forward and actively flash the board, we had to physically cut the I2C data bus to GPIO2 to get the board into flash/boot mode at all. As expected, the ESP then behaves as it should, but the bus is cut obviously, so no data. Now, here's what we tried given GPIO2 was cut:
1) cut power to the sensors, reestablish GPIO2 connection, establish power to sensors after booting, and use Wire.begin(2,14) as before. The result: there is no data sent over I2C. We clear the bus and we run into "SDA data line held low" with no chance to get out of this any more...
2) just rewire the SDA to GPIO5, and change the pin in the software with Wire.begin(5,14). The result: I2C does not come up, same problem with "SDA data line held low" as with GPIO2, no way to recover from this any more... (well, at least the board boots and does not get stuck in the fatal exception).
The big question is - why does it supposably work on GPIO2 causing the boot race condition, but does not work if we use GPIO5? We have read LOTS of forum entries and other comments with respect to the I2C and ESP12. Some pages say you can Quote "use pretty much any pin for I2C", however, after playing around with reset/clean/startup writes/reads from the new SDA pin 5, we are out of ideas, so any help on how to correctly set up the I2C bus given a booted board would be highly appreciated.