Debugger Hints and Tips

Note the following hints and tips when using Visual Studio to debug eRTOS applications.

Debug Behavior

If you cannot debug an eRTOS application, make sure the MaxRT eRTOS Debugger is the selected debugger.
While debugging, only the process being debugged is frozen when a breakpoint is hit. All other Real-time processes along with the Kernel continue to run.
In the event that no debugger is specified in Visual Studio, or you do not see the MaxRT eRTOS Debugger in the drop-down after you create a project, try the following:
Make sure the IntervalZero.Targets file is installed in the following directory:

%eRTOSSDKDir1%\DebuggerExtensions\

Verify that the files IntervalZeroeRTOSBaseDm exist in the same directory.

Note: The file IntervalZeroeRTOSBaseDm.xaml is located in C:\Program Files\IntervalZero\eRTOS SDK\DebuggerExtensions

If these files exist and you still do not see the eRTOS Real-Time Debugger, try the following:

Unload the project, right-click on the project and edit the project file
Make sure the following lines exist near the bottom of the project file:

</ItemDefinitionGroup>

<Import Project="$(eRTOSSDKDir1)\DebuggerExtensions\IntervalZero.targets"

Condition="exists('$(eRTOSSDKDir1)\DebuggerExtensions\IntervalZero.targets')" />

If you receive an error message when you start debugging, make sure:
eRTOS is running. The eRTOS target must be running before you can start a Visual Studio debugging session.
The eRTOSDebug configuration is selected
In the Visual Studio Extension Manager (Extensions > Manage Extensions…), make sure the MaxRT eRTOS VS Support is listed as an extension, and that it is both enabled and installed.
The MaxRT eRTOS Debugger does not allow disassembly/single step of eRTOS system calls (for operational security such as atomic sections).
The MaxRT eRTOS Debugger does not display the Process ID (PID) for eRTOS processes being debugged. A GUID is displayed instead. This is expected behavior when Visual Studio debugs a non-Windows process. The PID is displayed in the Output window.
Deterministic behavior does not exist while using the MaxRT eRTOS Debugger. As a result, eRTOS users should not depend on the execution order of multiple eRTOS applications being debugged by multiple eRTOS Visual Studio Debugger instances.
The thread priority shown in the Visual Studio Debugger Threads window will display Unknown if the real-time priority value does not correspond to a Windows thread priority. eRTOS thread priority values range from 0 to 127 and Windows thread priorities range from -15 to 15. If a real-time priority value matches a Windows value, the text displayed in the debugger Threads window will not be meaningful.
You can step into the functions exported by RTDLL but cannot step into or set a break pointer in the DllMain function.
Breakpoints are not allowed in an Interrupt Service Routine (ISR).
By default, the RtVSMon debug message processing thread runs on the first available eRTOS core at the highest priority. In this setup, if the process being debugged is also running on the first available core, the active debug session may disconnect, and the process under debug could freeze. To prevent this scenario, either schedule the process under debug to run on a different core or start RtVSMON.rtss on a core other than the one where the process under debug is running.
The Visual Studio Registers window displays registers during debugging. Visual Studio 2022 and Visual Studio 2019 currently do not display CET - Shadow Stack Pointer registers.