LEDC with open drain outputs

[ritsch@algo.mur.at]

What is the best practice to set open drain output ( GPIO_MODE_OUTPUT_OD ) on an LEDC channel ?

Using ESP-IDF framework and trying to set it before or after configure the cledc hannel with "ledc_channel_config()" does not work.

for example after configuration of ledc channel

Code: Select all

#include <driver/ledc.h>
#include <driver/gpio.h>
...
ledc_channel.pin = pin;
ledc_channel_config(&ledc_channel); 

gpio_set_direction(pin, GPIO_MODE_OUTPUT_OD);
...

Doing the same using the Arduino command "pinMode()" function works:

Code: Select all

#include "Arduino.h"
...
ledc_channel.pin = pin;
ledc_channel_config(&ledc_channel); 

pinMode(pwm[j].pin,OUTPUT_OPEN_DRAIN);

Since I do not want to use Arduino framework, how should I set it within ESP-IDF framework ?

mfG
winfried

[ESP_Sprite]

....Your question scares me. Can you explain why you want to have open drain outputs in this specific case? Asking because there is a chance the answer to this doesn't solve your problem.

[ritsch@algo.mur.at]

.... Can you explain why you want to have open drain outputs in this specific case?

Since I want to use PWM to drive a FET with more than 3.3V on input, in this case Vg=5V:

Code: Select all

 * 
 *             +-----+---> + Vcc
 *             |     |
 *       Diode _     3
 *             A     3  solenoid
 *  Vg <-+     |     3
 *       |     |     |
 *       R     +-----
 *       |    _|     
 * GPIO__+__||_    (MOS)-FET/Transistor
 *             |
 *  GND -------+-------- GND

mfg winfried

[ESP_Sprite]

Yeah, I thought you had something like this in mind. Do not do this, please. As the datasheet will tell you, 5V exceeds the acceptable voltage on an ESP32 GPIO. Even if the GPIO survives this, the ESD protection will limit your GPIO voltage to a bit above 3.3V. Suggest you either use a MOSFET that conducts sufficiently at a gate voltage of 3.3V, or use e.g. a BJT as an in-between to pull down the 5V gate voltage.

[ritsch@algo.mur.at]

Thank you very much for the advice.

With the `pinMode(...)` I already did this on en ESP32 quite a time now (a year).

... the ESD protection will limit your GPIO voltage to a bit above 3.3V ...

I could measure 4,85V with my oscilloscope, see snapshot:
- Rpu=10 kOhm on GPIO33 on an ESP32S2 (Olimex board):

PWM pulse Open drain to 5V

pwm_pulse.png (85.44 KiB) Viewed 10496 times

Did I ruin the ESD protection ?

I just found the thread: "Open drain output max voltage" [1] where this is also mentioned.

Since I am curious:

I could not find the specs of the maximum ratings of GPIOs directly or of the ESD protection in the technical reference manual [2] and data sheet [3] for the ESP32-S2 looking to Electrical specifications. So please can you hint me to it ?

But I found in "Reliability Qualifications" at [4]
"Latch-up (Over-voltage test) with 1.5 × VDDmax,

which would be 3.6V*1.5= 5,4V as maximum rating, so I could work with 5V,

I would be nice to know, so I can change safely my design.

mfg
winfried

[1] viewtopic.php?f=12&t=18477&p=68827&hilit=Open+Drain
[2] https://www.espressif.com/sites/default ... ual_en.pdf
[3] https://www.espressif.com/sites/default ... eet_en.pdf
[4] https://www.espressif.com/sites/default ... _en.pdf#40

[ESP_Sprite]

It's under 'DC characteristics':

dcchar.png (49.54 KiB) Viewed 10464 times

[ritsch@algo.mur.at]

Thank you for the hint, now I understand:

The output is always still an input, so we have to use the "input characteristics" for outputs
and therefore there are no output characteristics in the data sheets, which are superseded by them.

open drain is implemented to realize buses with common pull ups not for voltage level jumps, like I am used with ancient uCs.

Using VDD3P3_CPU in my case causes

- max voltage level: with VDD3P3_CPU=3.3V is V_IH=3.6V
- min voltage level: V_IL= -0.3V

ESD circuit with diodes are responsible for the +/-0.3V borders and VDD is default VDD3P3_CPU.

Power supply for GPIO33, GPIO34, GPIO35, GPIO36 and GPIO37 is configurable to be either VDD3P3_CPU (default) or VDD_SPI.

Not allowing to change gpio direction with gpio_set_direction(...) is intended to prevent wrong applications,
but can be done directly in registers like the Arduino-framework does.

Is this correct ?

thanks for information
winfried

PS.:I am just working on a blog on this and don't want to distribute false information.

[ESP_Sprite]

Thank you for the hint, now I understand:

The output is always still an input, so we have to use the "input characteristics" for outputs
and therefore there are no output characteristics in the data sheets, which are superseded by them.

That's one way of looking at it. The other way is that 'open drain' mode effectively switches the pin between output-low and input-only mode. (The other side of the coin is that the datasheet is a bit misleading at this point, as connecting 5V to an input also won't lead to anything good. We should duplicate or move those specs to the 'absolute maximum' table, I'd think.)

open drain is implemented to realize buses with common pull ups not for voltage level jumps, like I am used with ancient uCs.

In the case of the ESP32, open drain is mostly implemented to be able to do wired-AND (what you call 'buses with common pull ups') like I2C. Some microcontrollers (mostly 'ancient' ones, indeed) lack ESD protection on some pins, allowing them to handle higher voltages as well. The ESP32 is not one of those.

Using VDD3P3_CPU in my case causes

- max voltage level: with VDD3P3_CPU=3.3V is V_IH=3.6V
- min voltage level: V_IL= -0.3V

ESD circuit with diodes are responsible for the +/-0.3V borders and VDD is default VDD3P3_CPU.

Power supply for GPIO33, GPIO34, GPIO35, GPIO36 and GPIO37 is configurable to be either VDD3P3_CPU (default) or VDD_SPI.

This is correct.

Not allowing to change gpio direction with gpio_set_direction(...) is intended to prevent wrong applications,
but can be done directly in registers like the Arduino-framework does.

I'm actually not sure why this difference is. The ESP-IDF implementation seems more simpler and the Arduino one a bit more complicated; perhaps the Arduino code has some side effect that makes this work.

[ritsch@algo.mur.at]

Thank you very much for the explanation, it helps much, we will try another FET or FET-driver.

I'm actually not sure why this difference is. The ESP-IDF implementation seems more simpler and the Arduino one a bit more complicated; perhaps the Arduino code has some side effect that makes this work.

I see, anyway I wanted to stick to the ESP-IDF functions, so no problem for me.