Hi, I am trying to debug an ESP32-S3-DevKitC-1-N8R2 on the native USB connector and have failed miserably. Spent 3 full working days with GEMINI with no success. Half a day with ChatGPT today and no results too.
I do not want to resort to printf debugging.
Not sure if the issue is related to PIOarduino which I am using now or that it would happen under PlatformIO too?
I had endless problems with PIOarduino, I would suggest uninstalling the extension, ensuring the PIO extension is updated, restart the PC then download and open one of my ESP32-S3 projects from here, which will build and debug for a Seeed Xiao but should be easily adaptable to any ESP32-S3.
Hi Steven,
Thanks for your recommendation and code.
To be 100% sure I understood well, you suggest getting rid of PIOarduino and go back to the latest PlatformIO plugin?
Regards,
Thomas
Hi Thomas,
I was tempted to try PIOarduino as it included an MCU I wanted to use i.e. ESP32-C6 which is not currently supported by PlatformIO. I donât remember the details but my recollection is that I had many problems, not necessarily with the C6 environment but general bugginess and unreliability e.g. debugging would work but not every time. I formed to opinion that it is more experimental than mature. I stress this is only my opinion and I am fully supporting the project, which Iâm sure is a moving target and will only get better in the future. I canât rule out that part of the problem is the ESP32-C6 itself as being a RISC V CPU the debugging system is not as mature as the Dual-core 32-bit Tensilica Xtensa LX7 based ESP32-S3.
Another problem I had is that PIOarduino seems to take over an existing PlatformIO extension, even to the extent of changing the extension icon! So it does not seem possible to have both extensions in VSCode and switch between them as e.g. I often do between PlatformIO and Microchipâs MPLAB. The choice seems to be between a pure PlatformIO extension, or a merged PIO/PIOarduino system - messy.
But as someone who can not cope with anything less than total reliability I went back to PlatformIO. Also as an ESP32-S3 does not cost much more than an ESP32-C6 and is a much better MCU whatâs the point fighting an unnecessary battle?
If you want to try PIOarduino it is possible to install VSCode as a single, or multiple, portable version, as well as a normal fully installed version; in this way you could try PIOarduino in a portable version of VSCode without messing up your normal installation.
Ask Google Gemini how to install VSCode in a portable way.
Good luck.
Steve
Hi Steven,
Thanks for the input. I will try it and will come back with the results, but it will take one or two days as I am dealing with another issue right now.
Regards
Thomas
Hi Steven,
I uninstalled VSC and then removed the â.vscodeâ and â.platformioâ folders.
Installed VSC from scratch and installed the PlatformIO plugin.
I went to the project you linked and this is my platformio.ini file using your file as template.
[env:DEBUG]
platform = espressif32
board = esp32-s3-devkitc1-n8r2-dts
framework = arduino
; Debug build settings
build_type = debug
build_unflags = -Os
build_flags =
-Og ; Optimize for debugging
-g3 ; Maximum debug info
-DARDUINO_USB_CDC_ON_BOOT=1 ; Enable USB CDC
-DDEBUG_SETUP ; Enable setup() breakpoint spin loop
; Debug tool configuration
debug_tool = esp-builtin
debug_speed = 5000
; Initialize debugger at setup
debug_init_break = tbreak setup
; Extra debug commands
debug_extra_cmds =
set complaints 0
set print pretty on
mon reset halt
; Upload settings
upload_speed = 921600
It did not work (Spent two days trying to get some help from Gemini AI which sucks). Easily more than 100 runs with the most bizarre commands and flags changes running in circles.
The problem is that the debugger starts dumping its endless lines and halts at PC=0x40000400
But the GUI is completely lost:
The CALL STACK has the message âPaused on exceptionâ and nothing else, not even plain adresses of different stack levels (probably because it is stuck at the start of the code). At least it is consistent with the DEBUG LOG.
The DEBUG toolbox is âlost in spaceâ with the PAUSE button enabled (despite the processor being halted) having no clue the processor is stopped.
The DEBUG console at the bottom is as lost as the DEBUG toolbox and will not accept any command other than an âinterruptâ and only then both DEBUG toolbox and DEBUG console will be consistent with the debugger state, and the DEBUG console will accept other commands. But because we are still at the entrypoint, no source code can be highlighted.
This is the tail of the DEBUG LOG with my âinterruptâ command and a final âcontinueâ that never reaches my Setup() function.
Info : [esp32s3.cpu0] Target halted, PC=0x40000400, debug_reason=00000000
Info : [esp32s3.cpu1] Debug controller was reset.
Info : [esp32s3.cpu1] Core was reset.
[esp32s3.cpu0] Target halted, PC=0x40000400, debug_reason=00000000
[esp32s3.cpu1] Debug controller was reset.
[esp32s3.cpu1] Core was reset.
Info : [esp32s3.cpu1] Target halted, PC=0x40000400, debug_reason=00000000
[esp32s3.cpu1] Target halted, PC=0x40000400, debug_reason=00000000
PlatformIO: Initialization completed
PlatformIO: Resume the execution to debug_init_break = tbreak setup
PlatformIO: More configuration options â
Note: automatically using hardware breakpoints for read-only addresses.
interrupt
{âtokenâ:12,âoutOfBandRecordâ:
,âresultRecordsâ:{âresultClassâ:âdoneâ,âresultsâ:
}}
Info : [esp32s3.cpu0] Target halted, PC=0x40041A76, debug_reason=00000000
Info : Set GDB target to âesp32s3.cpu0â
[esp32s3.cpu0] Target halted, PC=0x40041A76, debug_reason=00000000
Set GDB target to âesp32s3.cpu0â
Info : [esp32s3.cpu1] Target halted, PC=0x40043A40, debug_reason=00000000
[esp32s3.cpu1] Target halted, PC=0x40043A40, debug_reason=00000000
Program
received signal SIGINT, Interrupt.
0x40041a76 in ?? ()
continue
Continuing.
{âtokenâ:16,âoutOfBandRecordâ:
,âresultRecordsâ:{âresultClassâ:ârunningâ,âresultsâ:
}}
I am showing you this so you get the feedback I promised to post, when I had the time to test it and not that you try to find out the problem.
I can not believe that being the ESP32-S3 already 5 years old, I am having so much trouble getting the USB-JTAG interface working for a DEBUG session. Clearly from your experience it is not everybodies problem.
Could this be solved paying for support? I doubt it!
Thanks for your code example. I am wondering if my ESP32-S3-DevKitC-1-N8R2 might be faulty?
Frustrating as hell. I really regret having chosen ESP32-S3-WROOM for the 10 prototype boards that are already in the manufacturing process (a 6 sided PCB with more than 570 components each and a lot of money spent).
Sorry for the rant!
Hi Thomas,
If your module is 5 years old it may be the first version of the S3 and that could cause some issues.
I think you have two many possible issues, possible faulty module, PlatformIO on VSCode not working, possible code faults and even some USB cables donât work well. Your module has 2 x USBC connectors, I assume you have the USB cable plugged into the USB port on the module and not the COM port? I suggest you diagnose it step by step i.e.
1: Do you have another newer module to try, if not buy a known good quality Xiao board from: Seeed XIAO ESP32S3 - The Pi Hut
2: The Xiao only has one USBC connector so plug it into your computer then look in Device Manager. You should see a COM port in the Ports section called USB JTAG/serial debug unit (Interface 0) COMx and also a USB JTAG/serial debug unit in the Universal Serial Bus Devices section. Both of these should dissappear when the module is unplugged. If you donât see both these interfaces use Zadig (https://zadig.akeo.ie/) to install the correct USB drivers, again Gemini or any AI will explain the procedure.
3: Assuming you can see both interfaces then create the simplest PlatformIO project using the Xiao ESP32-S3 board and the Arduino framework.
4: INI file:
[env:seeed_xiao_esp32s3]
platform = espressif32
board = seeed_xiao_esp32s3
framework = arduino
; â Serial Upload Configuration â
upload_protocol = esptool
upload_port = COM4 ; change to your Xiao COM port
upload_speed = 921600
; â Debugging remains via Internal JTAG â
debug_tool = esp-builtin
debug_init_break = tbreak setup
5: main.cpp file:
#include <Arduino.h>
// XIAO ESP32-S3 Hardware Note: Onboard User LED is connected to GPIO21
const int ledPin = 21;
void setup() {
// Configure GPIO21 as a digital output
pinMode(ledPin, OUTPUT);
}
void loop() {
// Set GPIO21 High (LED ON)
digitalWrite(ledPin, HIGH);
delay(100); // 100ms pause
// Set GPIO21 Low (LED OFF)
digitalWrite(ledPin, LOW);
delay(100); // 100ms pause
}
6: Build the code and if no errors then upload the code and the orange LED should blink quickly
7: Set a couple of breakpoints at the two digitalWrite lines (16 and 20)
8: Press F5 to start debugging and after about 30 seconds the debugger should stop at a breakpoint. Donât be concerned if it does not stp at SETUP or the first breakpoint as the S3 can execute lots of instructions before the debugger takes control. To fix this insert some asm(ânopâ); with a breakpoint to force the debugger to stop.
9: If you canât get it working with a âcleanâ installation of VSCode and PIO, a new Xiao module and the simple code above the you may have corrupted software on your computer and you might have to wipe the machine and reinstall Windows.
10: Gemini and other AIs really can be very helpful but maybe try asking your questions in a different way. One thing I find astonishing is that simply copying an error message into an AI wil often produce a detailed solution - that works!
11: Good luck and let me know how you get on.
Hi Thomas, this is further to my previous post about trying a Xiao ESP32-S3 and probably not want you want to hear, but I have tried just about every MCU and Debug method and if you want to use PlatformIO with its Arduino framework then in my opinion the best combination is an ARM MCU e.g. STM32F103C8 with a J-Link debug probe. It provides a rock solid debug experience, itâs fast to start debugging and the debug behaves how it should e.g. it stops in setup() and breakpoints just work.
Genuine J-Link probes are expensive ÂŁ80 to some hundreds but the Chinese clones work well; if you want to try one look at these links that will cost around ÂŁ10 in total:
J-Link OB = https://www.aliexpress.com/item/1005008849268813.html
STM32F103C8 = https://www.aliexpress.com/item/1005007459081585.html
I like Segger J-Link debug probes because of the great suite of supporting software described here: J-Link Software and which can be downloaded from here: SEGGER - The Embedded Experts - Downloads - J-Link / J-Trace
Unfortunately the ESP32-S3 debug using the JTAG-BUILTIN hardware is the opposite, slow to start debug, stops where it wants in your loop() and never in setup() and is very slow to move from one breakpoint to the next. The best one can say is that it works, just about, and no more. Now this could be the PlatformIO ESP32-S3 environment, or it could be the S3 itself, I have no way of knowing, but either way the debug experience in a production environment will be frustrating to say the least. Espressif would tell you to use the ESP-IDF development environment, which may well be better for debugging, but you loose all the ease and familiarity of the Arduino framework and the vast number of off-the-shelf libraries.
Another alternative that should work just as well is an STM32Fxxxxx module with an ST-LINK debug probe, of which their are many clones e.g. https://www.aliexpress.com/item/1005007096805623.html
If you need any more info let me know.
I was having the same issues. I was able to debug properly for very small code yesterday without any code in platformio.ini. Seems Itr was the problem. Started a new project and it worked on the spot. I did install the drivers with zadig on the communica te 0 channel before. This is extremely complicated and I am a former prg analyst that did c and c++ programming all day long! i will go very gently and add the tbreak line so it does not stop with itâs internal version of the setup and loop and hope for the best. So different board and user and same behavior! Hope this helps!
I am looking for a stm32 board but cheap with the jlink as you described. I am wondering at the huge difference of ram between the esp32-s3 and the spe32.I donât write big programs for the time being relying on serial print for debugging when the serial actually works. I am looking at a external debugger for the s3 and currently waiting on a couple of c3 to play with. But i like the experience of the stm32 you just described. I wnated to order one to see the experience but did not to shell out the $$$ for the big stm32.
The esp32-s3 is a nice device but the builtin jtag debug is painful, you could use pogo pins to connect a debug probe to the pinless pads on the bottom but I think an STM ARM module with an SWD connected Jlink is much better. There are many STM modules available for little cost e.g., the STM32F103 BluePill module, with a V9 Jlink from AliExpress will cost around ÂŁ10 total. Forget serial comms, jlink has RTT a much better way to get data off the MCU without the overhead of a USB COM software stack.
How fast is the debugging compared to what I am seeing for the s3 which is painfully slow? Letâs say a small program 300 or 400 lines of code plus library, that fits very easily in the S3 what about the stm32, does it really matter, as it is compressed a lot
Hi Steven,
I was finally able to get VSC/PlatformIO to debug my ESP32-S3-DevKitC-1 board on the native USB-JTAG interface (The board with the Neopixel RGB LED on pin 38 and two micro-USB connectors).
It was inspired by this post https://github.com/platformio/platform-espressif32/issues/651#issuecomment-1086863280 to be fair!
Using that information to guide âGemini AIâ to explain and solve one issue at a time, I reached a solution. It is not a neat solution as you do not stop at the start of setup(), but a couple of lines into it. The debugger will hand me the GUI with a CALL STACK reporting âPaused on exceptionâ (weird and incorrect imho), despite the DEBUG toolbox offering me the PAUSE button. I press PAUSE and land into an assembler waiti routine and then I press CONTINUE and I land in my break point a couple of lines into setup(). The solution is even compatible with the PIO serial monitor and would even print output into it while running and while stepping, not loosing a single message on the Serial Monitor.
It seems the debugger is too slow to negotiate with W11 the USB shared channel, and by that time the cpu has already executed the RTOS init code, and passed beyond setup()âs entry point.
The solution not only involves the INI file settings but some code at the start of the setup() function. That code is obviously not related to your target application, so the first viable and reasonable break point will be located after that code, which is not an issue, at least to me.
I was going to post the INI file and code, but when doing a paste into the posting textbox, all indentations are gone, and I am not willing to re-indent the text again, especially with long lines wrapping around. I searched the FAQ and google but could not find a way to solve this, so if anybody can explain on how to overcome that, I will try my best to post the complete solution.
I agree the debugger is slow and I do not know either if it is related to the environment or the chip itself, but I guess it is the former. Anyway, when you debug code trying to discover an issue with your logic or algorithm, your brain is carefully processing the states and values and to wait a couple of seconds to reach the next breakpoint or step into the code still outperforms printf debugging by far.
I am already committed to ESP32-S3-WROOM-1 as the PCBâs are already in production and it suits my needs perfectly and any redesign would have jeopardized the project I am involved in. I faced these debug difficulties just a couple of days before sending the PCB into production so I was still able to throw the footprint of a JTAG interface connector (for ESP-PROG), in case a debug dead-end would be the case, which happily was not the final outcome.
This is 25% of the board where my ESP32-S3 has to fit in (Lowrez images sent by the fabricator).
Hi Thomas,
Great news that you can now debug your code. Your PCB looks impressive so I understand why you wouldnât want to change module. With PlatformIO and ESP32-S3 modules it seems to be a constant battle to get the debugger to do what you want. I did get the debugger to stop in setup() using a spin loop like this:
#include <Arduino.h>
// Use volatile to prevent the compiler from optimizing this out
volatile bool hold = true;
void setup() {
// Spin loop to catch the debugger
// Once the debugger is attached, use the 'Watch' or 'Variables' window
// to change 'hold' to false (0) to continue execution.
while (hold) {
delay(10);
}
// Your initialisation code follows
Serial.begin(115200);
// ...
}
void loop() {
// Main execution
}
Other things to try are adding assembler NOPs at key places e.g.
asm("nop");
Also optimising the build settings to disable aggressive optimisation can help, as follows:
; Debug build settings
build_type = debug
build_unflags = -Os
build_flags =
-Og ; Optimize for debugging
-g3 ; Maximum debug info
-DARDUINO_USB_CDC_ON_BOOT=1 ; Enable USB CDC
; Debug tool configuration
debug_tool = esp-builtin
debug_speed = 5000
I got the same message: CALL STACK reporting âPaused on exceptionâ, which didnât cause any problems, Gemini suggested several possible causes such as the watchdog timer, which can be disabled. Good luck with your project.
Hi Steven,
All what you mention is included in some way in my solution (my is an euphemism 
)
I have a very complete INI/CPP/H set of files for the blink example that implements the solution, but it is to long to redo all the indentations that get lost when I paste the code.
Not sure why it is doing it (some change in my PC that got migrated to W11 or the configuration of this textbox in which I am writing changed), because in the past I did not need to do that?
It is stripping the trailing TABS and spaces which makes the code almost unreadable.
Am I the only one experiencing this?
Regards
Hi Steven,
Figured out how to change the editor mode with the first icon on the top at the left of the BOLD button. Some of the code got colors only 
I kow you do not need these upcomming instructions, but I will add them for anyone willing to try this.
platformio.ini
[env]
platform = espressif32
board = esp32-s3-devkitc1-n8r2
framework = arduino
lib_deps = adafruit/Adafruit NeoPixel@^1.15.4
monitor_speed = 115200
; --- NORMAL RUNNING (Release) ---
[env:release]
build_type = release
build_flags =
-Os
-DARDUINO_USB_CDC_ON_BOOT=1
-DARDUINO_USB_MODE=1
-DNDEBUG ; Disables assert() macros for speed
-fno-exceptions ; Reduces binary size if not using C++ exceptions
; --- DEBUGGING (Stable Config) ---
[env:DEBUG]
build_type = debug
; Flags to help Windows 11 keep the USB stack stable
build_flags =
-O0
-g3
-DDEBUG
-DARDUINO_USB_CDC_ON_BOOT=1
-DARDUINO_USB_DFU_ON_BOOT=1
-DARDUINO_USB_MODE=0 ; Use "Hardware CDC and JTAG"
-DCORE_DEBUG_LEVEL=4 ; Sets log level to Verbose (adjust as needed)
debug_tool = esp-builtin
upload_protocol = esp-builtin
debug_speed = 10000
debug_load_mode = manual
debug_init_break = tbreak setup
; When we start the Serial Monitor we do not want a COM port reset that afects the debugger
monitor_dtr = 0
monitor_rts = 0
; Remove 'monitor reset halt', it is likely what's crashing the W11 driver
debug_extra_cmds =
set remotetimeout 20
flushregs
main.cpp
#include <Adafruit_NeoPixel.h>
#include <debug_log.h>
#include <esp_task_wdt.h>
#include "rom/ets_sys.h"
#define PIN 38 // GPIO 38 for most DevKitC-1 boards (be sure to check as some boards use 48 or 21)
#define NUMPIXELS 1 // The onboard RGB LED is a single pixel
Adafruit_NeoPixel pixels(NUMPIXELS, PIN, NEO_GRB + NEO_KHZ800);
int loop_counter = 1;
unsigned long previousMicros;
unsigned long currentMicros;
long micros_interval = 10;
void u_delay(long u_length) {
}
// Helper function modified for ESP32-S3 (Xtensa)
bool dw_is_debugger_attached() {
uint32_t dsr;
// Read the Xtensa Debug Status Register (SREG 233)
asm volatile("rsr %0, 233" : "=a" (dsr));
// Bit 0 (RunSt) is 0 when the target is halted by a debugger
// However, usually checking if the JTAG is connected involves
// checking if the debug interrupt is enabled.
// If dsr is non-zero, it means a debugger has performed
// an operation or is currently halting the core.
// return (dsr & (1 << 4)); // FOR SOME REASON THIS DID NOT WORK
return (dsr);
}
void setup() {
int k = 0;
Serial.begin(115200);
// Only execute this wait if we are in a DEBUG build
#ifdef DEBUG
// We do this only when we deubug, to avoid any possible wd reset while stopped at a breakpoint
esp_task_wdt_init(30, false); // 30-second timeout, and do NOT reset on trigger
// Force the chip to wait here until the JTAG debugger is active
micros_interval = 10; // Let us wait 10 microseconds at a time
previousMicros = micros();
while (!dw_is_debugger_attached()) {
// Start of microseconds delay
do {
currentMicros = micros();
}
while (currentMicros - previousMicros < micros_interval);
previousMicros = currentMicros;
// End of microseconds delay
k++; // In case you want to know how many delays where required for the debugger to attach
}
#endif
// Instead of while(!Serial)
// This gives the JTAG controller "gaps" to breathe
micros_interval = 100; // Let us wait 100 microseconds at a time
previousMicros = micros();
for (int i = 0; i < 1000; i++) {
if (Serial) break;
// Start of microseconds delay
do {
currentMicros = micros();
}
while (currentMicros - previousMicros < 100);
previousMicros = currentMicros;
// End of microseconds delay
}
// After this comment you put your first break point. After this dummy assignment your real setup() function starts
previousMicros = micros();
#ifdef DEBUG
my_simple_log("ESP32-S3 source code debugging started!");
#else
my_simple_log("ESP32-S3 printf scheme debugging started!");
#endif
// Once your code is finished and you do not need any printf debugging or source code debugging anymore, you can get rid
// of all code from this line up. The same holds for any other app different than LED blink, regardless of its complexity.
pixels.begin();
}
void loop() {
// In loop() we will use regular milliseconds delays
my_flexible_log("Alive %d!", loop_counter);
pixels.clear();
pixels.setPixelColor(0, pixels.Color(0, 0, 5)); // Set single LED color to Green (R, G, B)
pixels.show(); // Show the LED ON
delay(500); // Keep it on for half a second
pixels.clear(); // Set the LED to OFF
pixels.show(); // Show the LED OFF
delay(500); // Keep it off for half a second
loop_counter++;
}
debug_log.h
#ifndef DEBUG_LOG_H
#define DEBUG_LOG_H
// Only one argument that will get a carriage return at the end
void my_simple_log(const char* message);
// Allows you to use it with variable arguments
void my_flexible_log(const char* format, ...);
#endif
debug_log.cpp
#include "debug_log.h"
#include <Arduino.h>
#include <stdarg.h>
#include "rom/ets_sys.h"
void my_simple_log(const char* message) {
#ifdef DEBUG
ets_printf("%s\n", message);
#else
Serial.println(message);
#endif
}
void my_flexible_log(const char* format, ...) {
char buffer[128]; // Adjust size as needed
va_list args;
va_start(args, format);
vsnprintf(buffer, sizeof(buffer), format, args);
va_end(args);
#ifdef DEBUG
ets_printf("%s\n", buffer);
#else
Serial.println(buffer);
#endif
}
esp32-s3-devkitc1-n8r2.json
{
"build": {
"arduino": {
"partitions": "default_8MB.csv",
"memory_type": "qio_qspi"
},
"core": "esp32",
"extra_flags": [
"-DARDUINO_ESP32S3_DEV",
"-DARDUINO_RUNNING_CORE=1",
"-DARDUINO_EVENT_RUNNING_CORE=1",
"-DBOARD_HAS_PSRAM"
],
"f_cpu": "240000000L",
"f_flash": "80000000L",
"flash_mode": "qio",
"psram_type": "qio",
"hwids": [
[
"0x303A",
"0x1001"
]
],
"mcu": "esp32s3",
"variant": "esp32s3"
},
"connectivity": [
"wifi",
"bluetooth"
],
"debug": {
"default_tool": "esp-builtin",
"onboard_tools": [
"esp-builtin"
],
"openocd_target": "esp32s3.cfg"
},
"frameworks": [
"arduino",
"espidf"
],
"platforms": [
"espressif32"
],
"name": "Espressif ESP32-S3-DevKitC-1-N8R2 (8 MB Flash Quad, 2 MB PSRAM quad)",
"upload": {
"flash_size": "8MB",
"maximum_ram_size": 327680,
"maximum_size": 8388608,
"require_upload_port": true,
"speed": 921600
},
"url": "https://docs.espressif.com/projects/esp-idf/en/latest/esp32s3/hw-reference/esp32s3/user-guide-devkitc-1.html",
"vendor": "Espressif"
}
The INI file defines the âreleaseâ and the âDEBUGâ environments.
You select acording to what you want to do.
For DEBUG you:
0) Put a breakpoint in the setup() function at line 73 (if you make a verbatim copy of this code). The code on that line is "previousMicros = micros();", which is a dummy instruction you can change later.
1) Compile and upload the code (arrow to the right). Ignore this message "Error: libusb_open() failed with LIBUSB_ERROR_NOT_SUPPORTED"
2) Start your serial monitor (plug icon)
3) Select in the leftmost panel of VSC the DEBUG icon (Triangle with a small bug on it)
4) At the top of the DEBUG panel, on the dropdown menu at the right of the green triangle, select "PIO Debug (without uploading), because your code is already running in an infinite loop somwhere :upside_down_face:
5) Press the green triangle to debug without uploading
6) Wait a couple of seconds for the DEBUG toolbox to appear, that should only have the PAUSE, RESTART and STOP buttons active. Depress the PAUSE button.
The DEBUG CONSOLE should show these two lines at the end:
....
esp32s3.cpu1: Debug controller was reset.
esp32s3.cpu1: Core was reset.
7) In my case it is stopping at a waiti assembler routine that I recall is a delay function maybe?
8) Now you have all the buttons enabled on the DEBUG toolbox (CONTINUE, STEP OVER, STEP INTO, STEP OUT, RESTART and STOP). Press CONTINUE and the debugger should stop at your breakpoint in the setup() function.
If you want to get a private class on how to manage the WATCH window or understand the CALL STACK window, you can ask GEMINI or the AI of your choice.
For sure there are configurations and settings that might be not essential for this to work, but I think it is imho a viable start point from were you can improve either by knowledge or try and error.
Feel free to point out any misconception or improvement that can be done, as we all will benefit from it.
Regards!
Hi Thomas,
thanks for all the code, lots of useful stuff there. Is it formatting in VSCode that you are having problems with? Formatting in VSCode does not seem to work without some adjustments. It took me ages with Gemini and ChatGPT to find a workable solution; try the following:
To complete the transition to the Allman style code formatting (braces on new lines), a small adjustment to the settings string is required.
Applying the Allman StylePress Ctrl , to access VSCode settings and replace the text in the C_Cpp: Clang_format_fallback Style box with the following line:
{ BasedOnStyle: LLVM, UseTab: Never, IndentWidth: 4, TabWidth: 4, BreakBeforeBraces: Allman }
main.cpp and press Shift + Alt + F.void loop()
{
counter++;
if (counter > 10)
{
Serial1.println("Resetting...");
}
}
Hi, Steven,
Thanks, very usefull, will implement it!