ESP-WROOM-32 / GPIO16/17

[jstoezel]

Hi,

Are they restrictions on the use of the GPIO pints 16 and 17 in the ESP-WROOM-32? I thought I had read somewhere that 16 and 17 are reserved for controlling the onboard flash (why would they be available for the user to connect hardware to through the castellated pins).

I used these pins for I2C communications and I am having troubles communicating with a device. I can see some activity on pin 17 when the board bootups (before I even map it to an I2C device)
If these pins cannot be used for I2C communications, what others are good and tested pins to used?

Thanks,
JS

[WiFive]

They are used on wrover and d2wd but not wroom.

[jstoezel]

Thanks for the reply. This is interesting. I have an I2C device connected to the WROOM through pins 16 and 17. As mentioned before I can see activity on one of the pins (I have to identify which one exactly) as the board is programmed and booting.

I've noticed that it is impossible to communicate with the I2C device (timeout errors) when the WiFi is enabled on the board (I am using the Arduino IDE and so I noticed the errors whenever I instantiate a WiFi module). I2C works very well in a project that does not include a WiFi instance.

And so at this point I'm wondering what WiFi does with pins 16/17. Digging into the ESP32 libraries that came with the Arduino port, I can only seem to find a use for pins 16/17 for the UART when UART 2 is configured. Though I have checked that this specific configuration is never invoked in my project.
I did find a WiFi example that made use of UART2, this was for a Telnet example I believe.

I'm about to cut the traces on my custom board to isolate pins 16/17 from the I2C device I am using, so I can use other free pins.
Before I do this, could anybody suggest how to do a dump of the configuration for all the pins? This would help identify if really pins 16/17 are reconfigured whenever I enable WiFi.

Thanks,
JS

[jstoezel]

I'm a bit surprised by the lack of reply here. I will just document my findings, hoping this will help somebody.
To me it appears there is an issue with pin 17 of the ESP-WROOM-32, it is used by some sort of process on the board (my guess is WiFi) and this is not documented.

If you hook up a scope on pin 17 of an ESP-WROOM-32, during programming you will be able to observe instability on the pin. I guess I am ok with this. What is disturbing is that, if you enable WiFi on the Arduino port, then a low level pulse is generated at some random (to me) frequency, sometimes it's train of pulses, sometimes it is just one pulse.
Confirmed this on 2 seperate board, one custom, the other board being the ESP_core_board_v2 completely isolated from any other device (in case somebody wanted to argue the issue was related to the custom board). The issue is visible when a pull up resistor is connected to pin 17.

[ESP_Sprite]

Fwiw, I have never seen this issue before; we also run the PSRAM chip off GPIO16/17, so I'd think that if there were random pulses on that, we'd see that by that chip malfunctioning. Just guessing, but maybe your pull-up is too weak and you're still receiving capacitively coupled signals from other pins?

[WiFive]

The other characteristic of gpio 16/17 is they are part of vdd_sdio power domain which maybe will show first signs of instability if 3.3v rail droops. WiFi and flash programming may cause power spike so might be worth checking your power supply and cables.

[jstoezel]

ESP_Sprite/WiFive:

Thanks for the replies, much appreciated. Both of your replies are of interest.

About power drops, I am currently powering from a USB cable, with a 3.3V LDO regulator AP2112K-3.3V on the custom board. This is good for up to 600mA output. The ESP32 datasheet lists in section 5.2 Table 10 a maximum current consumption of 240mA in transmit mode. I am not sure if the modes are cumulative i.e. the worst case consumption is actually "Transmit 802.11b" + "Receive 802.11" + "Transmit BT/BLE"...
But still it seems it would be contained within the maximum output of the LDO.
I am powering the board from a USB port, which supposedly can deliver more power than the LDO can handle.
The dev board I use has a NCP1117 regulator. It is rated with a higher output current, though I guess I am still powering both boards with the same USB port.
I wonder if the issue is related to powering from USB and/or bad power decoupling.

About the pull ups, I am using external 4.7k resistors, which is standard I believe for this type of application. Looking at the Arduino code though:

Code: Select all

i2c_err_t i2cAttachSDA(i2c_t * i2c, int8_t sda)
{
    if(i2c == NULL){
        return I2C_ERROR_DEV;
    }
    pinMode(sda, OUTPUT_OPEN_DRAIN | PULLUP);
    pinMatrixOutAttach(sda, I2C_SDA_IDX(i2c->num), false, false);
    pinMatrixInAttach(sda, I2C_SDA_IDX(i2c->num), false);
    return I2C_ERROR_OK;
}

It seems the I2C pins are setup to use the internal pullups. I couldn't find the value of the internal pullups in the datasheet. But say it is in the order of 10k like in most microcontrollers, then using an external pullup of 4.7k will result in a lower effective pullup (i.e. stronger...).

Since my last post I did cut the trace going to GPIO17 and rerouted SDA from my device to another pin (GPIO14). I am seeing the same issue.

And so at this point I think the issue is not specific to GPIO17, but rather either power related (requires bigger/better decoupling) or i2c pin configuration.

Thanks,
JS

[Hexman64]

Hello,

looks like I ran into the same problem: My I2C bus stops working some time after the Wifi goes online.

I soldered a board around a Wroom-ESP32 and made three connectors for a Real-Time-Clock, a 4-Digit-LCD (an I2C version of course) and a 20x4LCD behind a 3.3V<->5V converter. These three devices worked for three days and nights during programming without any problem (I left it running overnight).
With Wifi functions included at midnight, the device stopped working around 03:00 in the morning (the 4-digit was stuck at that time). Several tries next evening ended in errors on the I2C bus only after a few minutes or seconds every time.
I have to say that in my flat, Wifi works better during office hours or when people sleep, due to less devices in use I'd say.
Another thing is... I placed the three I2C connectors right next to the ESPs Wifi antenna. They could not be located any closer, I really built the worst case. Two devices are connected using 15cm cables, the RTC is put into its connector directly, standing vertically 10mm next to the Wifi antenna.
I tried removing the LCD (including logic converter) or the 4-Digit, but still the other one stops working or displays nonsense within seconds.

At this time I do not plan any further investigations. I'll just leave Wifi away (it's some kind of alarm clock, no real need to set the alarm via Internet) or add an external connector for another ESP32 which will do the Web-thing and transmit over a serial line. Next time I'll just keep in mind to have the I2C lines far away and shielded from the Wifi antenna.

[mikemoy]

Just wanted you you to know that 4.7k for a pullup on i2c is typical for a 5v rail. It's best to use a 2.2k for 3.3v.
Not saying this will fix your issue, just something to be aware of next time

[Hexman64]

Wow! Even though I have read the thread, I missed that external pullup resistors are a MUST HAVE in an I2C bus.
Several examples for I2C devices just show wires and did work for me, but now that I searched for it, I also found lots of pictures with pullups included.
So I just added two 2.2k resistors (as I'm on 3.3V) and pasted the wifi parts back in again.
It's only running for a few minutes now, but without any problem so far.

I'll hopefully think about updating this once I'm sure it's stable, but wanted to thank you for that important reply!