Request for review - ESP32-C3 Wroom Custom Board

[girishv]

I am developing a custom board using ESP32-C3-WROOM-02-N4 module.

The application needs two UART ports. So, I am planning to use the USB for download and debug.

It is my understanding that one needs to pull down the GPIO9 to put ESP32-C3 into USB download mode. So, I have provided the switch, SW2, to pulldown the GPIO9. Please correct me if I am wrong.

I am sharing the screenshot of the hierarchical sheet of ESP32-C3 module here.

Will this schematic work?

[tooki]

I haven’t used the C3, but have used the older ESP32’s a lot, so what I’m about to say may not apply 100% (but shouldn’t hurt), but I did look at the ESP32-C3-devkitC-02 schematic.

- provide a second footprint for an additional cap in parallel with C21, should it be necessary. When using traditional UART programming via the USB-serial chip, this cap’s purpose is to keep EN low long enough for the USB-serial bridge to set the bootstrap pin (IO9 here) before EN goes high, so that programming mode can be entered automatically. In traditional ESP32 boards, the 1uF is often insufficient, causing unreliable auto programming. (Meaning you’d have to press the EN and BOOT buttons in the correct sequence to enter programming mode.) A larger cap fixes this. I don’t know whether the USB programming in the C3 relies on this cap for that behavior or not, so I’d consider adding an extra cap footprint just in case.

- remove C24. I don’t know what purpose it would serve, and is not present in the devkit.

- remove C16 and C17. Capacitance is something you want to keep low on USB data lines. (And when you lay out the PCB, configure the data lines as a 90 ohm differential pair.)

- add ESD protection diodes/TVS to the USB data and power lines. See the devkit schematic.

- UART0 outputs debug messages on power up, so if you use UART0 for something other than programming, you might have unwanted messages going to a UART device. If this is a problem, you can remap most peripherals to almost any GPIO once it’s started up, so in your code, you can then initialize UART0 onto pins other than the default pins. (Both UARTs can be mapped to any GPIO pins.) It does look like in the C3, you can set efuses to disable the startup messages.

- you have a pull-up on IO2 (SCL), but not on IO3 (SDA). Both need one. Use the I2C specifications (or similar guidance) to calculate the optimal pull-up value. The I2C pull-up will also take care of the datasheet recommendation to have IO2 pulled high on reset to ensure it boots and programs properly.

Carefully review https://www.studiopieters.nl/esp32-c3-pinout/ -  it documents different GPIOs’ states during startup. Make sure that those states won’t cause problems with whatever hardware you have attached to the different GPIOs.

[girishv]

- provide a second footprint for an additional cap in parallel with C21, should it be necessary. When using traditional UART programming via the USB-serial chip, this cap’s purpose is to keep EN low long enough for the USB-serial bridge to set the bootstrap pin (IO9 here) before EN goes high, so that programming mode can be entered automatically. In traditional ESP32 boards, the 1uF is often insufficient, causing unreliable auto programming. (Meaning you’d have to press the EN and BOOT buttons in the correct sequence to enter programming mode.) A larger cap fixes this. I don’t know whether the USB programming in the C3 relies on this cap for that behavior or not, so I’d consider adding an extra cap footprint just in case.

I have one more cap C23, with switch SW1 in parallel to C21. I can change the footprint to 0805 for easy replacement.

- remove C24. I don’t know what purpose it would serve, and is not present in the devkit.

In ESP32-C3 devkit there is a cap in between GPIO9 and GND. So, I have two, one closer to pad on module and another closer to button. I will populate if and when I need one.

- add ESD protection diodes/TVS to the USB data and power lines. See the devkit schematic.

I do have ESD protection for USB data and power lines. They are on different hierarchical sheets.

- UART0 outputs debug messages on power up, so if you use UART0 for something other than programming, you might have unwanted messages going to a UART device. If this is a problem, you can remap most peripherals to almost any GPIO once it’s started up, so in your code, you can then initialize UART0 onto pins other than the default pins. (Both UARTs can be mapped to any GPIO pins.) It does look like in the C3, you can set efuses to disable the startup messages.

The unwanted messages on UART0 will not hurt. The other end validates data using a specific start and end bytes.

- you have a pull-up on IO2 (SCL), but not on IO3 (SDA). Both need one. Use the I2C specifications (or similar guidance) to calculate the optimal pull-up value. The I2C pull-up will also take care of the datasheet recommendation to have IO2 pulled high on reset to ensure it boots and programs properly.

Thank you for catching this. I will add one.

Carefully review https://www.studiopieters.nl/esp32-c3-pinout/ -  it documents different GPIOs’ states during startup. Make sure that those states won’t cause problems with whatever hardware you have attached to the different GPIOs.

I will review the above link. Thank you for sharing.

[tooki]

- remove C24. I don’t know what purpose it would serve, and is not present in the devkit.

In ESP32-C3 devkit there is a cap in between GPIO9 and GND. So, I have two, one closer to pad on module and another closer to button. I will populate if and when I need one.

The devkit has ONE, equivalent to your C25. I’m not talking about that, I’m talking about the 1uF C24 you added. There’s no need for it, and the devkit does not have that. Mark spare component footprints as DNP (do not populate) if you’re asking people to review a board — we cannot read your mind, we can only go by what you give us to look at.

[girishv]

- remove C24. I don’t know what purpose it would serve, and is not present in the devkit.

In ESP32-C3 devkit there is a cap in between GPIO9 and GND. So, I have two, one closer to pad on module and another closer to button. I will populate if and when I need one.

The devkit has ONE, equivalent to your C25. I’m not talking about that, I’m talking about the 1uF C24 you added. There’s no need for it, and the devkit does not have that. Mark spare component footprints as DNP (do not populate) if you’re asking people to review a board — we cannot read your mind, we can only go by what you give us to look at.

I got it. I am very sorry. It is my bad. I should have marked it as DNP.  I will watch out in future.

[xvr]

I do have ESD protection for USB data and power lines. They are on different hierarchical sheets.

Schema is wrong - see 'simplified schematic' on first page of DS

[girishv]

I do have ESD protection for USB data and power lines. They are on different hierarchical sheets.

Schema is wrong - see 'simplified schematic' on first page of DS

I messed up badly. Tons of thanks for catching it. Here is the revised schematic with a different ESD protection device.