CONFIG_CONSOLE_UART_NONE - UART Disable

[Rx-365]

Quick question about the setting in make menuconfig. I use UART2 to communicate with a peripheral device. This UART is configured and set up within application code. However, I do not want the normal ESP Log Messages to be sent out over any UART. I set CONFIG_CONSOLE_UART_NONE within make menuconfig and built/programmed the bootloader, partition table and application.

At this point UART2 no longer functions. Why does CONFIG_CONSOLE_UART_NONE kill all uart capabilities and not simply the ESP console output? What is the better way to achieve this?

[Ritesh]

Quick question about the setting in make menuconfig. I use UART2 to communicate with a peripheral device. This UART is configured and set up within application code. However, I do not want the normal ESP Log Messages to be sent out over any UART. I set CONFIG_CONSOLE_UART_NONE within make menuconfig and built/programmed the bootloader, partition table and application.

At this point UART2 no longer functions. Why does CONFIG_CONSOLE_UART_NONE kill all uart capabilities and not simply the ESP console output? What is the better way to achieve this?

Hi,

Which ESP32 IDF you are using? And we are also using UART1 and UART2 as per our requirement.

So, Why you want to disable debug logs on console UART? And I believe that CONFIG Console UART None will just disable console UART.

Please share you sample code as well.

[Rx-365]

The issue is also described here: https://github.com/espressif/esp-idf/issues/2013. I am disabling the console output because I do not want to any of the information on it to be visible to any probing.

I imagine that the setting should simply leave UART0 uninitialized or disable UART0. I don't understand why it currently disables all UARTs (0,1,2) and does not allow application code to utilize them.The IDF version is 3.2, however I believe that this will be present across all earlier versions due to the above issue.

At this point I don't understand whether this is a bug or the intended operation of the setting.

[Ritesh]

The issue is also described here: https://github.com/espressif/esp-idf/issues/2013. I am disabling the console output because I do not want to any of the information on it to be visible to any probing.

I imagine that the setting should simply leave UART0 uninitialized or disable UART0. I don't understand why it currently disables all UARTs (0,1,2) and does not allow application code to utilize them.The IDF version is 3.2, however I believe that this will be present across all earlier versions due to the above issue.

At this point I don't understand whether this is a bug or the intended operation of the setting.

Ok. Let me check by disabling Debug Console UART and see it will create any impact to UART1 and UART2 or not.

If it is really issue then it might be fixed earlier. Still, ESP32 SDK developers can also confirm for same.

[akashkalghatgi]

Posting for someone who still needs help on this topic.
[Note: I'm using IDFv4.4 dev]

Step1: got to menuconfig -> component config -> esp system settings -> channel for console output
Set to - Custom UART
Come one level behind and you'll find new options: UART peripheral to use for console output
Set this to UART1
You may also change the pins for UART0/1 that you are using now, by writing them in "UART Tx in GPIO# " option,
if you want to use UART0 pins (Tx-GPIO1 & Rx-GPIO3) for other purposes or simply change their respective pins to somewhere more convenient while designing a complex PCB.

Now, save and quit menuconfig -> flash operation is always done through UART0 (GPIO 1&3) but monitoring can now be done through UART1
However, on every reset (POWER_ON/SW_RESET/WDT_RESET, etc.) the UART0 pins will output bootloader logs even-though they are supposed to be printed through UART1. For this, I tried setting BOOTLOADER and LOGOUTPUT to NONE in menuconfig, but it only stopped printing the respective logs on UART1 (coz. we had set it that way).
The real solution is to pulldown GPIO15 so that even those bootup logs at UART0 can be stopped and now you're free to use the GPIO 1&3 for I/O operations.

[Ritesh]

Posting for someone who still needs help on this topic.
[Note: I'm using IDFv4.4 dev]

Step1: got to menuconfig -> component config -> esp system settings -> channel for console output
Set to - Custom UART
Come one level behind and you'll find new options: UART peripheral to use for console output
Set this to UART1
You may also change the pins for UART0/1 that you are using now, by writing them in "UART Tx in GPIO# " option,
if you want to use UART0 pins (Tx-GPIO1 & Rx-GPIO3) for other purposes or simply change their respective pins to somewhere more convenient while designing a complex PCB.

Now, save and quit menuconfig -> flash operation is always done through UART0 (GPIO 1&3) but monitoring can now be done through UART1
However, on every reset (POWER_ON/SW_RESET/WDT_RESET, etc.) the UART0 pins will output bootloader logs even-though they are supposed to be printed through UART1. For this, I tried setting BOOTLOADER and LOGOUTPUT to NONE in menuconfig, but it only stopped printing the respective logs on UART1 (coz. we had set it that way).
The real solution is to pulldown GPIO15 so that even those bootup logs at UART0 can be stopped and now you're free to use the GPIO 1&3 for I/O operations.

Thanks for providing details with clear understanding for the same.

Here issue is some what different which user has explained that he can't use other UART like UART1 and UART2 after disabling UART0

[felipe]

I confirm that pulling down GPIO15 stops the bootloader from sending logs to UART0 (GPIO 1 & 3).

[Ritesh]

I confirm that pulling down GPIO15 stops the bootloader from sending logs to UART0 (GPIO 1 & 3).

Good Work and Information for the same.

[Jabo0p]

Which board are you using, guessing the ESP32? What is the equivalent Pin that would need to be pulled down on the ESP32-S3 to prevent logs to UART0 (GPIO 43 & 44)?

[ESP_Sprite]

Check the datasheet ('strapping pins'). If memory serves, you need to burn some eFuses to configure if the console output is enabled, disabled, or controlled by a GPIO.