ESP32's internal boot ROM and UART1

[SomeCallMeTim]

Hello -

According to this post - viewtopic.php?f=12&t=297&p=1323#p1323 - UART1 can be utilized for bootstrapping the processor. Is this correct? The datasheet does not mention which UARTs are available for the ROM bootloader, but clues in the esp-idf library seem to indicate it's possible to use UART1 - for instance, the documentation around uart_buff_switch(...):

Code: Select all

/**
  * @brief Switch message exchange channel for UART download booting.
  *        Please do not call this function in SDK.
  *
  * @param  uint8_t uart_no : 0 for UART0, 1 for UART1.
  *
  * @return None
  */
void uart_buff_switch(uint8_t uart_no);

If this is truly a supported use case, it'd be good to update the documentation about the boot process to indicate UART0/UART1 are both available to boot the ROM code from. We've done some testing with a devkit based on the ESP-WROOM-S2 part, and it appears we can utilize the esptool.py to talk to the ROM code on UART1 (including uploading the stub bootloader), but since the flash technically uses these lines we did not attempt to program flash over this.

Additionally, the datasheet for the ESP32-D2WD indicates the pins for UART1 RX/TX are not utilized and that the SD card interface must be at 1.8V for the internal flash on this part. Does this mean that we could, with the ESP32-D2WD, utilize UART1 at 1.8V logic to program the flash on the ESP32-D2WD part? Will the ESP32-D2WD always utilize 1.8V logic for the internal flash on the part?

Thanks,
Tim

[hassan789]

Does this mean that we could, with the ESP32-D2WD, utilize UART1 at 1.8V logic to program the flash on the ESP32-D2WD part?

Very good question.
I am also interested to know the answer to this.

[SomeCallMeTim]

Ping.

[ESP_Angus]

Hi Tim,

Sorry for the slow reply.

According to this post - viewtopic.php?f=12&t=297&p=1323#p1323 - UART1 can be utilized for bootstrapping the processor. Is this correct?

Yes, this is correct. Note that the default UART1 pins (GPIO 9 & 10) are also used for SPI flash WP# and HOLD signals, so you can't enable Quad I/O flash modes while anything else is connected to UART1 - use dio or dout instead. (I think you could probably still use quad SPI flash modes while running if you isolated the serial connection when not flashing, but you'd need to take some care in the design.)

If this is truly a supported use case, it'd be good to update the documentation about the boot process to indicate UART0/UART1 are both available to boot the ROM code from. We've done some testing with a devkit based on the ESP-WROOM-S2 part, and it appears we can utilize the esptool.py to talk to the ROM code on UART1 (including uploading the stub bootloader), but since the flash technically uses these lines we did not attempt to program flash over this.

This should work as long as you don't try to boot in quad modes. You also need to disable the bootloader stub, as it currently only uses UART0. You can pass the "--no-stub" option to esptool.py for this.

I've opened an issue in esptool.py for full UART1 support: https://github.com/espressif/esptool/issues/235

Additionally, the datasheet for the ESP32-D2WD indicates the pins for UART1 RX/TX are not utilized and that the SD card interface must be at 1.8V for the internal flash on this part. Does this mean that we could, with the ESP32-D2WD, utilize UART1 at 1.8V logic to program the flash on the ESP32-D2WD part? Will the ESP32-D2WD always utilize 1.8V logic for the internal flash on the part?

Yes... and no.

Yes, GPIOs 9 & 10 are not connected to flash on this part so it should be possible to have a UART permanently connected here and also run the flash in Quad I/O modes.

However, using esptool.py with ESP32-D2WD requires the bootloader stub to work with UART1 before it can be used, as esptool.py in non-stub mode doesn't currently talk to the embedded flash chip.

GPIOs 9 & 10 are part of the VDD_SDIO power domain so they will always have the voltage of VDD_SDIO. You are correct that this should always be 1.8V when using ESP32-D2WD. This is also the case for ESP32-WROVER modules. Consult appendix C.4 in the ESP32 Datasheet or Section 4.8 of the ESP32 Technical Reference Manual for the full list of pins & power domains.


Angus