terminal terminates and idf_monitor runs wrong baud rate

[geedotk]

I have VSCode with esp-idf extension v1.6.2 and recently have a problem when if I try to do a Build, Flash, and Monitor on the Blink example, it builds and flashes without any issues. The problem is when it tries to monitor, I usually (but not always) get a popup window that says "The terminal process "C:\WINDOWS\System32\WindowsPowerShell\v1.0\powershell.exe" terminated with exit code 1." It then starts the monitor, but it sets the baud rate to 460800 instead of the 115200 that is specified in sdkconfig.

The terminal window shows the following:

PS C:\Users\myname\Documents\Projects\wifi_audio_sync\code\esp32\idf5.0\blink> set IDF_PATH=C:\Users\myname\esp\esp-idf
PS C:\Users\myname\Documents\Projects\wifi_audio_sync\code\esp32\idf5.0\blink> C:\Users\myname\.espressif\python_env\idf5.0_py3.8_env\Scripts\python.exe C:\Users\myname\esp\esp-idf\tools\idf_monitor.py -p COM18 -b 460800 --toolchain-prefix xtensa-esp32s3-elf- --target esp32s3 c:\Users\myname\Documents\Projects\wifi_audio_sync\code\esp32\idf5.0\blink\build\blink.elf
--- WARNING: GDB cannot open serial ports accessed as COMx
--- Using \\.\COM18 instead...
--- idf_monitor on \\.\COM18 460800 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
xx�xxxx��x��x��x��x�x�xx�������x��xx�������x�����������x�x�xxx��x�x�x��x�xx�x���������������x�x�x��x�x�x���x��xx��xxxxx�x��x�x�xx�x�x�x�x���x��x��xxx�xx�xx�xxxx�x�xx�x�xx�x�x�xxx�xx�x��xxx�xxxx����xxxxx��xx�x�x�xxx��x��x�xx��x�x�xxxx��x��x�x��x�x�x�x�xx�x���x����xxxx���x��x�xxx�x���x��������x�x�x�xx�x���x�������x�������x�xxx�x���xxxx�x�x�x�xx�x���x�������xx����x�xxx�x���x���x���x��xx�x�x�x�x�x��x�������x��x�

It is displaying garbage because the blink program outputs at 115200. If I stop that monitor and type "idf.py -p COM18 monitor" at the prompt, it will start at 115200 and display the correct readable output.

Why do I usually get the window that indicates that powershell terminated?

Why does idf_monitor start at 460800 baud? I don't see 460800 anywhere in the project directory and it starts properly if I don't specify the baud rate?

I should also say that this was working about a month ago. I don't know what has changed during that time.

I hope someone can help with this issue.

[abgironne]

I have the same exact issue. Need to open the monitor manually with pySerial: "pyserial-miniterm.exe COM8 115200"

[dTiago]

Hello!
Add in .vscode/settings.json:

Code: Select all

"idf.monitorBaudRate": "115200"

and try again.

[geedotk]

Ok. Adding

Code: Select all

"idf.monitorBaudRate": "115200"

to .vscode/settings.json fixed the problem! I can now do a Build, Flash, and Monitor and see the output correctly at 115200. I wonder why I now have to do this since I didn't have to do this before. It seems to be ignoring the

Code: Select all

CONFIG_ESP_CONSOLE_UART_BAUDRATE=115200

line in sdkconfig. Anybody know why?

Thank you dTiago for giving me a solution that gets me around this issue for now!

[zliudr]

I haven't used IDF for quite some time and just started using it again today. Installing the plugin was the easy part that used to be quite hard.

I guess to answer your question why the monitor setting in the sdkconfig wasn't taken instead, it's just different developers. The sdkconfig setting is meant for an IDF project and everything coming from official IDF stuff. But this VSCode plugin may have been made by a different developer group that doesn't have knowledge of what's included in sdkconfig, so it assumes some weird baud rate and only reads the .vscode folder for a different baud otherwise. It's like this developer is coming from a vscode toolchain developer point of view and may not even understand what IDF stands for, let alone investigate a little time understand what IDF developers use sdkconfig for.

It's probably the same for flashing with weird 460800 baud instead of trying it according to max rate that works with the UART IC, such as 1.5Mbaud in case of FT231X or CP2102N (been using this rate for years, effective rate is a bit less but still over twice 460800. It's very useful if you have a large project like I used to have).

460800 works for the old CP2102, not the new ones with an N. But who cares in the software industry what hardware developers care about, right? 460800 was probably taken by the VSCode plugin developer as a magic number and applied everywhere a baud rate is needed.