Power supply and UART Connection for ESP-WROOM-32D

[WiFive]

Yes, as long as your mcu does not drive the tx line at same time as pc.

Use a different pin for CS

Uart0 is always configured for flash download by the ROM bootloader when you boot in download mode with gpio0/2 low. Always.

[FCT_IOT]

Yes, as long as your mcu does not drive the tx line at same time as pc.

Use a different pin for CS

Uart0 is always configured for flash download by the ROM bootloader when you boot in download mode with gpio0/2 low. Always.

Dear @WiFive,

Based on GPIO Muxing, We can assign CS Pin to any free GPIO (For Example: GPIO 27). I read that connecting GPIO pins to peripherals through GPIO Mux will result in APB clock (80MHz) tick delay. By assigning CS Pin only through GPIO Mux and rest other HSPI Signals through the IO_Mux will it have any effect on flash operation.

Since MTDO Pin has an internal pull up (to enable to room boot logs to display on UART-0 Terminal), The following link has an option to disable the pullup. (https://github.com/espressif/esp-idf/bl ... ver/gpio.h). Can we disable the pullup automatically or is connecting to MCU and driving it low the only option to disable the boot logs..?.

When ESP-WROOM-32D is in uart download mode, will there be any boot logs printed on Uart-0, before the firmware download process is initiated.

Thank you

[WiFive]

Cs pin only through gpio matrix should be ok and/or can be worked around

You have to drive it low or use external pulldown

Yes, but MTDO low may prevent these

I think it is time for you to get some dev boards and experiment, you will figure all these things out.

[FCT_IOT]

Cs pin only through gpio matrix should be ok and/or can be worked around

You have to drive it low or use external pulldown

Yes, but MTDO low may prevent these

I think it is time for you to get some dev boards and experiment, you will figure all these things out.

Dear @WiFive,

I have ordered the EVM.

I would like to know if it is okay to connect a pull down externally to MTDO. Since, it is internally pulled up will it not act as a voltage divider.

Will it be okay if i connect MTDO with a pull down and also to the External flash chip select. Due to the external pull down the boot logs will not be displayed and after bootup i can use the same pin as a chip select to external flash. Is this feasible.

Thank you

[WiFive]

It has weak internal pull so external pull 10k or less should be fine. Should be ok to use for CS.

[ESP_Angus]

1. AT instruction set document mentions that GPIO16, GPIO17, GPIO14, GPIO15 (UART 2 pins in ESP-WROOM-32D) are used by default for AT Command transfer. The GPIO14, GPIO15 are used to connect to internal SPI Flash. I would like to know if i can disable MTDO (which will disable UART0 to be used for debug purpose) and use UART0 for AT Command transfer, firmware Download through uart. I am interested in using Flow control hence i would like to know the feasibility of using UART0.

Setting MTDO will disable UART0 from early boot log messages, but if you configure the AT firmware (via "make menuconfig") to use UART0 then this will still cause AT output on UART0.

You actually have two options, you can change the UART port number entirely or you can just change the pin assignments in menuconfig for the AT project (with UART2 or with a different UART). You can pick any pins which aren't reserved by the chip/module.

Firmware download via UART is implemented in the boot ROM, as WiFive has explained it requires resetting with certain strapping pins held high/low. Currently only firmware download via UART0 is supported.

2. If i power the ESP-WROOM-32D using a 3V power supply, Will it have any effect on the internal flash module interface and what will be the VDD_SDIO pin voltage. The datasheet of ESP32 mentions that vdd_sdio output voltage is either 1.8 V or the VDD3P3_RTC voltage (Which will be the same as supply voltage (3V)).

Running the ESP-WROOM-32D at 3V should be fine, provided the power supply can supply enough current (we recommend 500mA, ie the same current as would be required at 3.3V).

3. The time taken by the WIFI Module to wakeup from light sleep / modem sleep / deep sleep modes.

I'm not certain about the wake time for light sleep, I will find out. Note that light sleep is currently incompatible with active WiFi (ie WiFi must be disabled to enter light sleep). Light sleep & WiFi coexistence is planned in IDF v3.1.

I don't think we publish a statistic for modem sleep wake times. This will depend on the characteristics of the WiFi network. If you're looking to calculate average power consumption from this data, then this will also depend heavily on the characteristics of the WiFi network.

Waking from deep sleep essentially involves a full reset of the chip, so the boot time will depend on the size of the compiled firmware and the speed/mode settings of the flash chip. It's usually in the order of 100-400 milliseconds depending on these variables.

[FCT_IOT]

1. AT instruction set document mentions that GPIO16, GPIO17, GPIO14, GPIO15 (UART 2 pins in ESP-WROOM-32D) are used by default for AT Command transfer. The GPIO14, GPIO15 are used to connect to internal SPI Flash. I would like to know if i can disable MTDO (which will disable UART0 to be used for debug purpose) and use UART0 for AT Command transfer, firmware Download through uart. I am interested in using Flow control hence i would like to know the feasibility of using UART0.

Setting MTDO will disable UART0 from early boot log messages, but if you configure the AT firmware (via "make menuconfig") to use UART0 then this will still cause AT output on UART0.

You actually have two options, you can change the UART port number entirely or you can just change the pin assignments in menuconfig for the AT project (with UART2 or with a different UART). You can pick any pins which aren't reserved by the chip/module.

Firmware download via UART is implemented in the boot ROM, as WiFive has explained it requires resetting with certain strapping pins held high/low. Currently only firmware download via UART0 is supported.

2. If i power the ESP-WROOM-32D using a 3V power supply, Will it have any effect on the internal flash module interface and what will be the VDD_SDIO pin voltage. The datasheet of ESP32 mentions that vdd_sdio output voltage is either 1.8 V or the VDD3P3_RTC voltage (Which will be the same as supply voltage (3V)).

Running the ESP-WROOM-32D at 3V should be fine, provided the power supply can supply enough current (we recommend 500mA, ie the same current as would be required at 3.3V).

3. The time taken by the WIFI Module to wakeup from light sleep / modem sleep / deep sleep modes.

I'm not certain about the wake time for light sleep, I will find out. Note that light sleep is currently incompatible with active WiFi (ie WiFi must be disabled to enter light sleep). Light sleep & WiFi coexistence is planned in IDF v3.1.

I don't think we publish a statistic for modem sleep wake times. This will depend on the characteristics of the WiFi network. If you're looking to calculate average power consumption from this data, then this will also depend heavily on the characteristics of the WiFi network.

Waking from deep sleep essentially involves a full reset of the chip, so the boot time will depend on the size of the compiled firmware and the speed/mode settings of the flash chip. It's usually in the order of 100-400 milliseconds depending on these variables.

Dear @ ESP_Angus and WiFive,

Thank you for your valuable inputs. I have attached the interfacing schematics used in my application. Request you to provide some inputs if there are any modifications needed.

ESP-WROOM-32D Is supplied with a 3V DC-DC Converter with current rating of 700 mAmp.

# Pin Strapping
1. GPIO 2 has been pulled up, to enable SPI boot by default. (GPIO 0 has also been connected to MCU so that when entering in UART Download mode MCU can drive GPIO 0 LOW).

2. GPIO 2 has been pulled down. (It is also connected to Write Protect of External SPI Flash)

3. MTDO has been pulled down. (It is also connected to Chip select of External SPI Flash)

4. MTDI has been pulled down. (To configure the internal flash supply voltage to 3 V)

5. GPIO 5 has been pulled up. (do i need to connect a pull down instead of pull up...?)

GPIO 34 is connected to MCU. (It is used to wakeup the WIFI Module from light sleep or deep sleep mode).

External SPI Flash (W25Q80DVSNIG from winbond) through the HSPI Interface. The Flash supports both QIO and DIO Mode. Does WIFI Module support QIO Mode, in few posts i had seen that DIO Mode was suggested.

UART-0 has been used to interface with MCU. (Through the makemenu config I will configure the AT Firmware to enable UART-0 for AT Command transfer). Hence, UART-0 will be used for Firmware download and also for AT Command transfer.

During the Firmware download or AT Command transfer, MCU will passthrough the commands from PC to WIFI Module (Appropriate firmware will be implemented to enable the passthrough mode operation).

I would like to know the following

1. If the decoupling capacitors are sufficient to the VCC pin.
2. RC Values to the Enable pin.
3. Internal Pullup or Pull down resistor values used in ESP-WROOM-32D.

If there is anything that i need to incorporate in this schematics please do let me know.

Thanks in advance.

[ESP_Angus]

This looks right to me, at least from a quick look. You can double-check against the "Peripheral Schematics" table in the ESP32-WROOM datasheet, and the "Strapping Pins" section of the ESP32 datasheet.

Note that with MTDO pulled down, as shown, the early boot UART output is disabled. This looks like it's intentional, just wanted to mention it.

1. If the decoupling capacitors are sufficient to the VCC pin.

Yes.

2. RC Values to the Enable pin.

If you're driving the EN pin from your MCU's GPIO output and you have full control over timing, you can probably remove both the capacitor and the pullup. The capacitor recommendation is when a PC UART is driving DTR/RTS to control the chip, and we need to slow the rising edge of the EN pin a little to meet the "auto reset circuit" requirements vs the timing of the DTR/RTS transitions from the host OS.

The pullup will mean that the ESP32 starts booting as soon as power is applied. If you, instead, want to wait for your host MCU to boot and then have it start the ESP32 then you can make this a pulldown resistor instead.

3. Internal Pullup or Pull down resistor values used in ESP-WROOM-32D.

A value isn't specified, but it will be in the 50K-100K range.

External SPI Flash (W25Q80DVSNIG from winbond) through the HSPI Interface. The Flash supports both QIO and DIO Mode. Does WIFI Module support QIO Mode, in few posts i had seen that DIO Mode was suggested.

This is supported. If you compile the project with QIO mode set in menuconfig, then it will suggest you flash with "--flash_mode dio" on the esptool command line. This is correct. The bootloader boots from ROM in DIO mode and then enables QIO mode internally.

What do you plan on using the external HSPI flash for? We don't currently have full driver support for a second concurrently connected flash chip, so the only way to interact with such a chip right now is by sending SPI Flash commands via the SPI driver. It's still possible to do everything with the chip this way, but it won't be as convenient as working with the internal flash. (The other option is to use EFUSEs remap the ESP32 to use HSPI as its main flash chip, instead of in the internal flash.)

[FCT_IOT]

This looks right to me, at least from a quick look. You can double-check against the "Peripheral Schematics" table in the ESP32-WROOM datasheet, and the "Strapping Pins" section of the ESP32 datasheet.

Note that with MTDO pulled down, as shown, the early boot UART output is disabled. This looks like it's intentional, just wanted to mention it.

1. If the decoupling capacitors are sufficient to the VCC pin.

Yes.

2. RC Values to the Enable pin.

If you're driving the EN pin from your MCU's GPIO output and you have full control over timing, you can probably remove both the capacitor and the pullup. The capacitor recommendation is when a PC UART is driving DTR/RTS to control the chip, and we need to slow the rising edge of the EN pin a little to meet the "auto reset circuit" requirements vs the timing of the DTR/RTS transitions from the host OS.

The pullup will mean that the ESP32 starts booting as soon as power is applied. If you, instead, want to wait for your host MCU to boot and then have it start the ESP32 then you can make this a pulldown resistor instead.

3. Internal Pullup or Pull down resistor values used in ESP-WROOM-32D.

A value isn't specified, but it will be in the 50K-100K range.

External SPI Flash (W25Q80DVSNIG from winbond) through the HSPI Interface. The Flash supports both QIO and DIO Mode. Does WIFI Module support QIO Mode, in few posts i had seen that DIO Mode was suggested.

This is supported. If you compile the project with QIO mode set in menuconfig, then it will suggest you flash with "--flash_mode dio" on the esptool command line. This is correct. The bootloader boots from ROM in DIO mode and then enables QIO mode internally.

What do you plan on using the external HSPI flash for? We don't currently have full driver support for a second concurrently connected flash chip, so the only way to interact with such a chip right now is by sending SPI Flash commands via the SPI driver. It's still possible to do everything with the chip this way, but it won't be as convenient as working with the internal flash. (The other option is to use EFUSEs remap the ESP32 to use HSPI as its main flash chip, instead of in the internal flash.)

Dear Angus,

Thank you for your clarification.

Pulldown on MTDO Pin

Few posts had mentioned intial boot log mesages on U0TXD Pin was causing an issue during the UART Download mode. Hence, I connected the MTDO Pin to pull down.

Reason for HSPI Flash:

To have an additional memory interface apart from the internal flash provided.

Thank you

[WiFive]

It's still possible to do everything with the chip this way, but it won't be as convenient as working with the internal flash.

https://github.com/lllucius/esp32_fatflash