Thanks for the report.

The ESP8266 GDB Stub only supports a single breakpoint at a time, so once you stop on one, you have to remove it to accurately set the next one. If you do set > 1 breakpoint it may show "Unknown Stopping Event" and not stop where you expect.

The limitation of one breakpoint, and one watchpoint is a limitation of the GDBStub itself (see Git Notes)

Does this help?

Additional info

I connect my oscilloscope on the RX line of my ESP, I can see the data coming in from the debugger but if I put a breakpoints into my code while the code is running nothing pass through the serial port at first but after 1 minutes data came in from the debugger and the code break but not in the good place some ware like "random" in esp library code.

Sylvain Bissonnette

Sorry we missed your posts. 

Frame not in module can happen if you try to step into core code that is distributed as an  archive or pre built loibrary that does not provide the source code. Optimization settings can also cause this but changing optimization settings should be done carefully as some cores and libraries are not designed for certain settings. That is out of our hands and for reference you should read about the core or libraries you are using.

Visual Micro is responsible for building, uploading the code and showing data in the serial monitor, not for how the GDB stub works which is an open source library that you have installed. 

Hardware debuggers and GDB stub make complex use of interrupts as does the wifi and other background tasks of the ESP devices. I wish we could be more helpful but I have to suggest that you direct any questions about how GDB Stub plays alongisde ESP8266 and your code usage of WiFi/Timers and Interrupts etc.

Visual Micro launches the Microsoft GDB debugger which then controls Visual Studio and manages breakpoints etc. Visual Micro does not have any interaction with the debugger after it has launched. If the author of the GDb Stub library has any questions then it might be possible to switch on some of the ms gdb logging although that isn't great. 

One suggestion would be to use the "vMicro > Show/Hide Hidden Files" so that the underlying core and library sources appear in the project. This might make setting a breakpoint in the correct location possible but you do need to be careful of how you step. Clicking the little green arrow that appears left of each code line during debug when the mouse is hovered over the code line is often the safest way to jump to a bit of code without needing a breakpoint.

As Simon stated previously having only a single breakpoint to work with is a feature of the GDB stub library you are using and it does make life quite tricky. I would try to run without breakpoint and use the little green arrow instead. That effectively sets a breakpoint in background but in a softer way the gdb stuff might be happier with. This is certainly true for hardware debuggers.

I know the Visual Micro serial/wifi debugger isnt ideal for library and core sources but it is recommended whenever possible because it provides unlimited (limited only by memory) break/trace points and avoids using mcu menory for trace message.

Sorry can't be more help. Simon might have some extra insight next week but I suspect that GDB Stub on an ESP8266 needs very careful use. If there was an alternative solution we would support it.