Loosing printf output during DEBUG. (ESP32-S3-DevKitC-1-N8R2, Native USB, single USB cable)


While debugging the DevKit on the native USB interface (without a second UART cable) using HWCDC on the "Serial" object (DARDUINO_USB_CDC_ON_BOOT=1 / DARDUINO_USB_MODE=1), if I leave the code to run without breakpoints, I get all the Serial Monitor output correctly (upload_port = COM34 / monitor_port = COM34). (Thanks sivar2311 for all the help!).

But if I add a breakpoint in the SETUP and in the LOOP routine (and resume with the PLAY button each time it stops) the printf’s are almost lost completely. Sometimes I get a burst with the last 4 or 5 lines, but that is rare.
First I thought I needed to add a Serial.flush() before the breakpoint but the problem persisted, if I recall correctly.

I have been reading the Espressif documentation regarding DEBUG but haven’t found any conclusive info.

In my platformio.ini file I have:

board = esp32-s3-devkitc-1-n8r2

In my esp32-s3-devkitc-1-n8r2.json file I have:

  "debug": {
    "default_tool": "esp-builtin",
    "onboard_tools": [
    "openocd_target": "esp32s3.cfg"

If I check at C:\Users\tmagdahl\.platformio\packages\tool-openocd-esp32\share\openocd\scripts\target\esp32s3.cfg,
inside of the file there is only one “find” statement referencing a CFG file, which is “source [find target/esp_common.cfg]

And inside esp_common.cfg no other CFG file is referenced.

To understand these files better I have been reading
where it is being recommended to set at least:

set remote hardware-watchpoint-limit 2

The first “set” seems to apply when the non USB JTAG is used (not my case for now, because I am using native USB) so that the strap pin related to MDTI is at the correct setting at boot time, so that the correct voltage is used for the SPI memories. Of course only N16R8V and N32R8V require 1.8V.
The second “set” seems to be necessary because the ESP32-S3 has only 2 hardware breakpoints and if you use more than 2, it will not warn you and ignore them.
As a matter of fact, only if you have one breakpoint of both used, you will be able to STEP correctly, as it requires to use the second breakpoint for that feature (if I am not mistaken).

What is confusing me is that on this folder
you have a file that seemed to be necessary for my case (Builtin JTAG) named
esp32s3-builtin.cfg to tell the environment that that’s my case, but I am not sure if it is being used, maybe as a side effect of another directive in json or cfg file? Of course my builtin USB is working (exept the printf) so I assume I am on the right side, but I am wondering if esp32s3-builtin.cfg contains something needed for solving my lost printf’s while debugging?

I have no idea in what file I have to add my eventual “set” statements, in case I want to try them out?

The Tips and Quirks page states “If you are using a board not listed here, you need to specify both the interface configuration file and target configuration file.” which is something you can see, is being done in esp32s3-builtin.cfg, but I do not know where I tell the system (INI or CFG file) to use such a file (or a custom file I made). Maybe platformio.ini is doing this already for me?

Well, the main problem is to get the printf’s to work during interactive debuging.