bugfix(uart + i2c): fix signal glitch on tx , i2c sda and i2c scl pin

[ESP32DE]

see #1061

[stickbreaker]

@ESP32DE look at my comments in your pull request on my repo stickbreaker/arduino-esp32 Pull 19.

If you make the same changes to this pull, it will solve the I2C begin Glitch also.

Chuck.

[lonerzzz]

Good find. Is this something worth pushing to the IDF folks in case it has not been addressed there?

[stickbreaker]

@lonerzzz I looked at the IDF code, maybe here?
IDF driver/i2c.c

gpio_set_direction(scl_io, GPIO_MODE_OUTPUT_OD);
gpio_set_direction(sda_io, GPIO_MODE_OUTPUT_OD);

Maybe mode should be: GPIO_MODE_DEF_OD instead of GPIO_MODE_OUTPUT_OD?

I can't test it because I don't use IDF directly.

Chuck.

[lonerzzz]

I don't use the IDF directly either so it may be just a matter of creating an issue and telling them how it is solved in Arduino I2C based on your findings. They should be back next week so you could tag @me-no-dev to get his input on passing it along.

[ESP32DE]

@stickbreaker
@lonerzzz
stickbreaker#19

i did optional order the setup for digitalWrite (edit not pinMode), cause in older version
of arduino esp32 core the order after open drain setup is successfull but not before.
and in actually version the order must come before open drain setup.

interesting is the second found, to setup the open drain as "OPEN_DRAIN" instead "OUTPUT_OPEN_DRAIN" nice found! i will check this in the esp-idf too
cause we have in esp-idf in i2c a problem :) .. let me check on weekend, so i have more time for this.
txs!
best wishes
rudi ;-)

[ESP32DE]

cross thinking
a I²C master did clk the slaves
make it a different if we set the clk pin on master as "OUTPUT_OPEN_DRAIN"
and on the slaves we set clk pin as "OPEN_DRAIN"
did you test this way too @stickbreaker ?
( i wil check this way on esp-idf )

i think for sda we need "OPEN_DRAIN"
cause the ACK is read ( no OUTPUT_OPEN_DRAIN ) by master on this
so "OPEN_DRAIN" makes sence here, good found 👍

best wishes
rudi ;-)

[negativekelvin]

@stickbreaker @ESP32DE no I don't think that is a problem in IDF driver/i2c.c because that is inside bus clear function and at the end i2c_set_pin gets called which sets GPIO_MODE_INPUT_OUTPUT_OD

[stickbreaker]

@ESP32DE

cross thinking
a I²C master did clk the slaves
make it a different if we set the clk pin on master as "OUTPUT_OPEN_DRAIN"
and on the slaves we set clk pin as "OPEN_DRAIN"
did you test this way too @stickbreaker ?
( i wil check this way on esp-idf )

The glitch seems to be created when the output driver is assigned to the pin. Inside cores/esp32/esp32-hal-gpio.c the OPEN_DRAIN option is the last configuration set. I think this ordering is causing the problem.

But, I do not understand the thought process/functional sequence for configuring the pin/port mux hardware on the ESP32. I am very Leary about changing something that is so fundamental. I do not know why that OPEN_DRAIN is configured as the last step.

Another unexplored issue: What are the ramifications of assigning a pin that has been previously configured? This sequence works from a reset condition. I have not tried setting either pin to another mode(input/output/adc) before assigning it to the I2C peripheral.

I do not yet have a functional SLAVE mode ESP32 operational yet, so I haven't done any testing as a slave. Both SCL and SDA are input/output. SCL can be driven by Slave I2c devices to pause communications. (SCL clock Stretching). I do not see any benefit using OUTPUT_OPEN_DRAIN on SCL. The OUTPUT option causes the glitch.

Chuck.

[me-no-dev]

yes let's fix this in the source instead. @stickbreaker there is no logic behind why OPEN_DRAIN is last step. I did not expect the order to actually cause an issue. Different bits in different registers are set, so unless the ESP somehow overwrites certain registers on change, the order should not matter.
Can you test adjusting that in the hal driver?

@ESP32DE I will close this request and move towards fixing in the pinMode source :)

[stickbreaker]

@me-no-dev Where can I find documentation of the GPIO matrix?

esp32\tools\sdk\include\soc\soc\gpio_struct.h

is the only thing I can find.

Chuck.