1. no, you need the gdb stub or hardware debug option for that.

2. not sure what you mean. You can put breakpoints inside functions.

Yes header files are not compiled as units therefore software serial does not manage breakpoints in them.

I suggest moving the function to a .ccp with #include of the header. the prototype can stay in the header.

Look this image please.

HI!

For the serial debugger to start, after having recompiled and uploaded the code, I must unplug and plug in the USB port on the ESP32Wroom card. Even if I do a reset with the switch it doesn't start.
What can be done to solve this problem?

This mis message from Micro Debug Trace:

Launching Debugger...
   - Serial debug will start immediately. WiFi (or gdb) debug will start a few seconds or a short time after the remote device connects to the network.
   - Switch on 'vmicro>debugger>full speed' to prevent debugger message throttling. (read the docs)
   - If 'in-break live watch' is disabled, continue an existing paused debug session by sending the character 'c' to the board using the Serial window.
   - If uploading on WiFi but debug is on Serial then it is possible the cpu will be in debug break when OTA upload is attempting connect. If this is the case then sending char 'c' using the serial/debug terminal will force the mcu to continue (like F5).
   - WiFi debug? Wifi debug is not fully supported yet. Use the vMicro>Debugger menu to set an alternative debug port such as Serial (default speed is 115k)
   - To view debug messages without trace messages use the 'message windows' option on the monitor window.
   - Switch off this message and other Tutorial messages using the 'vMicro>General' menu

Regard,
:Le patenteux

Hi!
The behavior is identical even when fixing all windows.
What is the solution?

Are your breakpoints from setup() or loop().

When the serial monitor shows "connect" in green that means the serial is connected. That and the trace show the debugger is active.

If you are trying to debug code in the setup() it is possible the setup() has happen before the debugger could attach. To prove this you can add a delay(3000) to the start of the setup().

Other notes.

It's not important to have so many windows pinned. In this discussion we just need to see serial monitor, trace. 

Selecting the board option called "Debug: serial" is not related to the serial debugger. That is an esp32 board option that causes the esp core to send verbose internal info to the serial monitor.

Arduino boards usually have a way to force a reboot when the serial monitor connects but the esp32 boards do not have that facility. This means other arduino boards will more easily land in the setup(0 when serial debug starts.

The delay only helps if there are breakpoints in the setup or functions called from setup and is not always required even in those circumstances.

It looks like the breakpoints are not being hit. Are they conditional or on code lines that are "if" statements?

The optimisation settings are for advanced use or for with hardware debugging. 

Leave the optimization on default. The serial debugger works fully optimized.

Please show an image of your solution explorer so we can see the structure of your project code files.