Before logging an issue, please update to the latest release of Visual Micro from the Downloads Page.

When Logging a Support Issue in the Forum, please ensure you have also:-

  • Enabled vMicro > Compiler > Show Build Properties
  • Re-Compile your program with these settings enabled
 
Save the new Output to a Text File and....
  • Click the Reply button and attach as .txt file OR
  • Click here to Email us with the file attached, and a link to your post
Support requests without the output above may be impossible to answer, so please help us to help you
 
Page Index Toggle Pages: 1 Send TopicPrint
Normal Topic Debugger stops/crashes when serial (Serial.println) routines are used. (Read 1632 times)
Veliferums
Newbies
*
Offline


Posts: 8
Joined: Aug 20th, 2023
Debugger stops/crashes when serial (Serial.println) routines are used.
Aug 20th, 2023 at 3:33pm
Print Post  
Debugger works when no serial routines are used. When it encounters a serial function, it will get stuck inside this serial function. When in the example below the breakpoint is hit and I press F5 (continue) it will reach the breakpoint again (after it processed the loop). I can press F5 again and again and it will work I even see output on the serial monitor. As soon as I press F10 (step over) once and immediately after that press F5 or continue with F10 the program will get stuck on the Serial.println
The same example works fine in Visual Studio Code with Platformio and debugging. 
Sometimes after this problem it's impossible to retry build/upload/debug because an error is displayed that no upload tool is available and I have to restart Visual Studio and/or I have to power down the ESP32 devkit and restart it again.


Example code, breakpoint is at the first line inside loop:

void loop() {
  digitalWrite( 2, HIGH);
  delay( delayTime );
  digitalWrite( 0, HIGH);
  delay( delayTime );
  digitalWrite( 4, HIGH);
  delay( delayTime );
  digitalWrite( 2, LOW);
  delay( delayTime );
  digitalWrite( 0, LOW);
  delay( delayTime );
  digitalWrite( 4, LOW);
  delay( delayTime );
  Serial.println("TSP - This is main.\n");
}


Debugger stops here and can't continue:

void uartWriteBuf(uart_t* uart, const uint8_t * data, size_t len)
{
    if(uart == NULL || data == NULL || !len) {
        return;
    }

    UART_MUTEX_LOCK();
    uart_write_bytes(uart->num, data, len);
    UART_MUTEX_UNLOCK();
}
« Last Edit: Aug 20th, 2023 at 3:36pm by Veliferums »  

Please Register or Login to the Forum to see File Attachments
Back to top
 
IP Logged
 
Tim@Visual Micro
Administrator
*****
Offline


Posts: 12188
Location: United Kingdom
Joined: Apr 10th, 2010
Re: Debugger stops/crashes when serial (Serial.println) routines are used.
Reply #1 - Aug 20th, 2023 at 4:08pm
Print Post  
Thanks for the clear report. We are currently looking into similar issues that affect only with the esp32s3.

Does the issue also happen when the visual micro serial monitor is closed?
  
Back to top
IP Logged
 
Veliferums
Newbies
*
Offline


Posts: 8
Joined: Aug 20th, 2023
Re: Debugger stops/crashes when serial (Serial.println) routines are used.
Reply #2 - Aug 20th, 2023 at 5:03pm
Print Post  
Yes, it does even when I set the serial monitor to COM1 or something else. I'm a professional C++ / Assembler programmer for over 40 years and I even dream in Visual Studio C++ 😊, so believe me I’ve tried everything I can to solve it.
I've also had errors like core 1 of the ESP crashed, or seen unhandled exception errors which corrupt the complete Visual Studio/Visual Micro in such a way that I have to restart Visual Studio. The Version I’m working with is 2022 with the latest version of Visual Micro. I’m working in a Virtual Machine with the following specs:

-      VMWare Workstation 15.5.7 build-17171714.
-      8 GB Memory 4 Processors.
-      Windows 10 Build 22H2, 64bit

Everything works correctly with Visual Studio Code with PlaformIO, but I’m addicted to Visual Studio 😊
In my opinion it has something to do with setting automatic breakpoints when stepping with F10/F1 through the code, because one fixed breakpoint in loop and hitting F5 repeatedly works without any problems. 

Let me know if you want further info.

  
Back to top
 
IP Logged
 
Tim@Visual Micro
Administrator
*****
Offline


Posts: 12188
Location: United Kingdom
Joined: Apr 10th, 2010
Re: Debugger stops/crashes when serial (Serial.println) routines are used.
Reply #3 - Aug 20th, 2023 at 5:21pm
Print Post  
Thanks. We suspect it is something to do with how Visual Studio launches the MI debugger. We pass launch params and the same params work find in PlatformIo and via cmd.exe.

Therefore currently we are investigating 1) are there additional compiler or linker defines required that are specific to the s3 or 2) is the way Visual Studio launches the mi debugger the problem. 

PlatformIO also uses the Mi debugger in VSCode but VsCode launches Mi2 and VS launches Mi1. 

It doesn't appear to be related to the communications between GDB and OpenOCD.

We are considering raising it with Microsoft. Next week will will ask them what logs they need to be able to review the issue. Giving them something to work with can be difficult. We might have to build a small app that attempts to debug a prebuilt program along with a cut down toolchain that just provides GDB and OCD.

It's annoying when all other MCU's work without this issue.
  
Back to top
IP Logged
 
Veliferums
Newbies
*
Offline


Posts: 8
Joined: Aug 20th, 2023
Re: Debugger stops/crashes when serial (Serial.println) routines are used.
Reply #4 - Aug 20th, 2023 at 5:44pm
Print Post  
To be clear, my BOARD is a ESP-WROVER-32 Dev Kit V4.1 with a ESP32-WROVER-B chip. I can't help you after 26 Aug because my trial will be over than and I'm not sure if Visual Micro will work after that.
  
Back to top
 
IP Logged
 
Veliferums
Newbies
*
Offline


Posts: 8
Joined: Aug 20th, 2023
Re: Debugger stops/crashes when serial (Serial.println) routines are used.
Reply #5 - Aug 20th, 2023 at 7:14pm
Print Post  
Don't know if it will help but in the routine uart_write_bytes a exception is thrown:

0x400d35d0  call8      0x400d6024 <uart_write_bytes>
0x400d60a5  call8      0x400d5804 <uart_tx_all>
0x400d5822  call8      0x4008a11c <xQueueSemaphoreTake>

after the last call the debugger is messed-up
  
Back to top
 
IP Logged
 
Page Index Toggle Pages: 1
Send TopicPrint