UDE Frequently Asked Questions (Toggle all items)

If UDE shows a warning after start:

    Runtime components are older than required by UDE !
    This might result in instable function of UDE.

Or if UDE crashes while opening context menus,
then this is probably caused by a wrong/old version of Microsoft visual C++ runtime.

We recommend to fix the issue by installing the latest runtime package from Microsoft:
There a several versions available, please download and install
vc_redist.x86.exe for UDE up to version 5.2
vc_redist.x64.exe for UDE version 2021 and later


Usually the UDE setup detects the installed runtime version and updates it if required.
But there might be some other 3rd party software installed, which also uses a runtime, but does not properly update the windows registry. So the UDE setup cannot recognize that other runtime. The package from Microsoft will update the runtime to latest version.

This is possibly caused by 'SentinelOne(R)' an Endpoint Security product used in your IT infrastructure. Putting 'ude.exe' and/or 'UDEVisualPlatform.exe' on the exception list of 'SentinelOne(R)' Endpoint Security product solves the issue.

A message dialog shows the errors:

  Failed to init debug server from saved settings ! Loading UDE license server failed !

This behaviour can be occured after the parallel installation of different UDE version. The reason is an incomplete component registration process. Browse to the installation directory of UDE and run


All components should be registered successfully.

That happens when using COM applications in conjunction with the MKS toolkit. That toolkit replaces some system *.dll files and the COM mechanism is disturbed. It is a known problem at MKS. An upgrade solves that problem.

See also: CFS 31336 at https://www.mkssoftware.com/support/94p1problems.asp

  //according to: http://with-love-from-siberia.blogspot.de/2009/12/msgbox-inputbox-in-jscript.html
  var vb = {};
  vb.Function = function(func)
    return function()
      return vb.Function.eval.call(this, func, arguments);

  vb.Function.eval = function(func)
    var args = Array.prototype.slice.call(arguments[1]);
    for (var i = 0; i < args.length; i++)
      if ( typeof args[i] != 'string' )
      args[i] = '"' + args[i].replace(/"/g, '" + Chr(34) + "') + '"';
    var vbe;
    vbe = new ActiveXObject('ScriptControl');
    vbe.Language = 'VBScript';
    return vbe.eval(func + '(' + args.join(', ') + ')');

  /** InputBox(prompt[, title][, default][, xpos][, ypos][, helpfile, context]) */
  var InputBox = vb.Function('InputBox');

  /** MsgBox(prompt[, buttons][, title][, helpfile, context]) */
  var MsgBox = vb.Function('MsgBox');


  function showMsgBox( )
    MsgBox("can you see this message box?", 4, "Answer the question!");

For using VBA you have to follow two major principles: First all parameters of functions should be passed by value only by using brackets around parameters.


  str = RawJtagDev.ShiftDr( 12, (SHIFTDATA) )

Secondly it has to be considered that procedure calls (methods without any return value) have an different syntax. Parameters are not passed using brackets.


  RawJtagDev.ShiftIrBit 12, "00101010"

Instead of

  RawJtagDev.ShiftIrBit ( 12, "00101010") ' -> gives an compilation error

After installing the Eclipse environment I am not able to debug the application with the Universal Debug Engine.

First, check if the Universal Debug Engine (UDE) integration is installed:

  1. Start your Eclipse IDE
  2. Open/Create your workspace
  3. Open the Debug Configurations
  4. Check if an Universal Debug Engine item is listed
  5. If yes, continue with Step 13!
  6. To install the UDE Integration click on Help - Install New Software
  7. Click on the Add-Button to add a new repository
  8. Click on Archive and select UDEEclipseIntegration.zip from the UDE installation directory (i.e.: C:\Program Files (x86)\pls\UDE 3.0)
  9. Click on OK
  10. Disable the Group items by category checkbox
  11. Select the Universal Debug Engine Eclipse Integration checkbox and click on Next
  12. Reopen the Debug Configuration (See step 3)
  13. Double-click on the Universal Debug Engine item to automatically create a new launch configuration.

After the launch configuration was created, you should be able to debug your application with the Universal Debug Engine perspective.

The UDE license manager can access to a shared license key file via network folders. Please follow one of these steps:

Adapting an existing installation of UDE

  1. Backup your registry.
  2. Insert a new registry entry using the tool regedit.exe HKEY_CURRENT_USER\Software\pls\Universal Debug Engine\3.0\PlsData
  3. Assert a shared network folder to the entry, where all required UDE instances can access to:



Adapting a new installation of UDE

  1. Insert the following entry to the file setup.ini from the UDE installation folder



The required registry-key will be added automatically while installation process.

Providing UDE licenses via network, for the administrator of the UDE licenses only required. Run the UDE license manager via Help-Lizenz-Manager and add all of the required UDE license keys. This updates the UDE license file on the network folder. All computers, which have the above described registry-key, have now access to the central managed license key file for usage with UDE and UDE Memtool (<PlsData>\UDELicenseMgr.xml).

For diagnostic of the problem run the tool


from the UDE folder. When more than 10 components are shown as not registered for usage with UDE, then the basic reason could be an unregistered atl.dll, which prevents the correct installing of UDE. To solve the problem, please open a command shell within C:\Windows\system32 directory. On command line run:

  regsvr32 atl.dll

Then run


within your UDE installation folder and all components should be registered successfully.

The check box Debug macro with built-in Macro Debugger can not be check'd. What can I do?

If the check box Debug macro with built-in Macro Debugger is disabled, the required library pdm.dll ( version 9.0.30729.1) was not available. Because of the standard installation of this library, the UDE setup does not install or verify this library. Depending from the OS variant (x86 or x64) and from the installer, the library is located typically in

  C:\Program Files (x86)\Common Files\microsoft shared\VS7Debug\pdm.dll
  C:\Program Files\Common Files\microsoft shared\VS7Debug\pdm.dll

or can be located in an other location.
Typically, the macro debug component is installed by one of the following installers:

  • Visual Studio 20xx (all versions)
  • Remotetools for Visual Studio 20xx (all versions).

Please register the library from command line (Windows 10 or later console must be started with administrator rights):

  Regsvr32.exe <Path to library>\pdm.dll

If the library cannot be registered nor cannot be found on the system, reinstall the Visual Studio or install Remotetools for Visual Studio.

For that the Service Mode feature of UDE could be used. Service mode is primary made for debugging applications by connecting to a already running target. Using the mode allows also to download applications without resetting the target. To enable the mode open menu Debug - Debug Server. Under the Download page please enable the Attach to Service Monitor option and enable the Download pattern option.

Now loading applications without reset is possible.

Please take into account that the program counter is now not set automatically to the entry point of the new loaded application. It has to set manually.

The expression object could be used for that task. The character '@' has to be put in front of the variable's name. The following VBA sample could be uses as reference:

  Dim UDEDebugger
  set UDEDebugger = Workspace.CoreDebugger (0)
  set UDEExpression = UDEDebugger.Expression( "@RetVal")
  strValue = "Value = " & Hex( UDEExpression.Value) & vbNewLine
  UDEDebugger.ConOutput( strValue)

To save the System Information under Windows® 10, Windows® 11 ... click on

Start - All Programs - Accessories - System Tools - System Information

Save the Information via menu File - Save... , enter the filename and click on Save.

The debugger reads the register-value from target, if the SFR-View is updated. If you add a register, which clears some bits after read (e.g. interrupt status or similar) then the value of this register changes after SFR update and an unexpected program behavior may occur.

To avoid this problem, read the data from another register (special debug register, e.g. ADC_RESRD instead of ADC_RESR on TriCore). If this is not possible, you may use a variable in your program, which can be monitored using Locals-View or Watch-View.

Create a script file, that contains the appropriate procedure:

  Sub ChangeVariableAndRun()
    Dim UDEDebugger
    Dim Value
    Dim VariableName

    ' Get debugger - is always debugger of index 0 in workspace
    set UDEDebugger = Workspace.CoreDebugger(0)

    ' Get the content of the following variable name (for example "ucMinutes")

    ' Get variable value
    Value = UDEDebugger.Variable( VariableName )

    ' Change the value
    Value = Value + 1

    ' Write new value to the variable
    UDEDebugger.Variable( VariableName ) = Value

    ' Return the application
  End Sub
  1. Start UDE
  2. Load/Create your workspace
  3. Click on Tools - Macros - Open File to open the Script file that contains your procedure
  4. Load the ELF application and source file
  5. Set a breakpoint to the appropriate source line
  6. Click on Debug - Breakpoints... from the UDE menu
  7. Select the breakpoint on which the variable name have to be changed
  8. Enable the Macro checkbox
  9. Enter the procedure name, that is enclosed in your script file (for example "ChangeVariableAndRun")
  10. Click on OK to save all.

After click on Run, the procedure is always called after the appropriate breakpoint was hit.

If you want to connect with more than one instance to only one UAD2/UAD3 via USB/Firewire the 'MultiAccess' Option must be enabled in the CommDev section of the Target Config File (*.cfg).



Another solution is to use Ethernet instead of Plug and Play ports or to use different ports (e.g. USB and Firewire or USB and Ethernet).

Yes, because Windows PowerShell can deal with COM objects it can also control UDE.

Here is a small example which starts UDE, programs the FLASH with an application, executes the program for 1 seconds and read some variables.


  # UDE automation basics - PowerShell demo script
  # On command line run: "powershell .\UDEAutomationDemo.ps1"
  # In PowerShell console run: ".\UDEAutomationDemo.ps1"
  # Note: Don't use expression '$true' together with UDE functions, use 1 instead

  # Helper function to release COM objects
  function Release-Ref ($ref)
    ([System.Runtime.InteropServices.Marshal]::ReleaseComObject([System.__ComObject]$ref) -gt 0)


  $WspFile = "D:\UdeAutomationDemo\UdeAutomationDemo.wsx"
  $CfgFile = "D:\UdeAutomationDemo\TriBoard_TC27xB_dap.cfg"
  $ElfFile = "D:\UdeAutomationDemo\MulticoreDemo.elf"

  write-output "Create new UDELauncher object ..."
  $UDELauncher = New-Object -ComObject $ProgId

  write-output "Start new UDE instance"
  $UDEApplication = $UDELauncher.StartAndCreateWorkspace("UDEVisualPlatform.exe", $WspFile, $CfgFile, 1)
  $Output = " UDE version: " + $UDEApplication.VersionInfo
  write-output $Output

  write-output "Access workspace"
  $UDEWorkspace = $UDEApplication.Workspace
  $Output = " Workspace: " + $UDEWorkspace.ProjectTitle
  write-output $Output

  write-output "Access first core debugger"
  $UDEDebugger = $UDEWorkspace.CoreDebugger(0)

  write-output "Wait for target connected"
  while (0 -eq $UDEDebugger.Connected)

  write-output "Load target application"

  write-output "Start target application"

  write-output "Wait a second"

  write-output "Read some variables"
  $Seconds = $UDEDebugger.ReadVariable("g_SharedData.Seconds")
  $Output = " Time: " + $Seconds
  write-output $Output

  write-output "Release objects and close UDE instance"

  write-output "Release UDE launcher (optional)"

  write-output "Finished"

Please see the UDE Help manual UDEAutomation.chm for more details about automation with UDE.

To enable that option, open the Memtool dialog via menu Tools-Flash programming. Select the General... button and enable After download start Program All function automatically.

At the same time you could also enable option Automatically close Execute Command dialog when finished.

There are several main approaches in general ..

  1. Develop and debug Flash and RAM code separately. For that you need two different build variants, one for located to flash and one located to RAM. The Flash variant should be the final release variant running without UDE. If the development and test is done the Flash variant should be used as the final image.
  2. Locate Flash and RAM to different sections. For that Flash code and RAM code should be located to different section. For example locate Flash code to .text_flash and RAM code to .text section. At the same time you need to create a ROM copy of that section which is copied during bootup of the application. For setting breakpoints in RAM code you have to enable the Set hardware breakpoint by default option located in menu Config-Debug Server Configuration-Debug Server because software breakpoints get lost after copy of RAM code. That is almost the best solution because debug information are available for both, Flash and RAM code.

Probably the target interface configuration is set to stop at exception entries. To continue running when internal resets are generated go to menu Config - Target Interface. Select the Cortex M3 register card and disable Core Reset.

You can add expressions in C syntax like ...

  struct.structmember, structpointer->structmember or array[21].

The easiest way is to display first the whole variable of complex type and then select the interesting members via context menu entry Add as new entry.

Normally the download patterns are the same for *.elf and *.hex file. Under some circumstances it is necessary to patch the *.hex file with additional patterns that do not exist inside the *.elf file. UDE implements a special Hex/Elf option to support that cases. The download pattern are taken from *.hex and the symbol information is taken from the *.elf file.

The option could be found via menu Config - Debug Server Configuration - Symbol - Hex/ELF load.

PowerPc processors have the capability to measure the time needed for program execution. This feature must be enabled:

Set Enable program time measurement in Menu Config - Target Interface... - Debug". You can use the Help button on this tab for more information.

If you enable the "Show descriptions" option, you can see a text string instead of the filename. To change this description:

Click "Edit" and modify the first line of the "Target Description" box. You can also open the configuration file with a text editor and modify the "Description=" entry.

During program loading the debugger creates a database file for symbol management.

The default place is the same directory like the program file. Storing of the database locally speeds up the program loading if the file is located on a network drive. Use the following configuration to do this: Menu Config - Debug Server Configuration - Debug Server - Symbol - Symbol page Database directory.

Perhaps there is a wrong source alias. To solve that issue, open Menu Config - Debug Server Configuration, Go to View Server-Program and click Aliases. Remove all entries and Close/Reopen Workspace.

The UDE Administration tool (UDEAdmin.exe) from the UDE program group can be used to edit a target configuration directly ...

Run the UDE Administration tool and open the menu Edit - Target Configuration file for creating, editing or deleting the configuration file.

To do this ...

  1. create a new workspace (*.wsx)
  2. do your settings and placements or do a debugging session
  3. close and save the workspace
  4. edit the *.wsx using an texteditor and delete the key <TargetInfoFile/>, delete the key <BinaryFiles/>, delete the key <StdUDEProgWin/>, delete the key <MRUSourceFileList/>

and to use this workspace

  1. start UDE
  2. open this workspace, you will be asked for *.cfg file, you can download new application
  3. save workspace as... <new name>
  4. close dont save workspace
  5. open the newly saved workspace

There are different reasons ...

  1. The compiler optimized your program code (-o parameter), so these variables do not longer exist.
    • Choose a lower optimization level for your compiler.
    • Add the "volatile" keyword to the variables you wanna see. But be aware, all optimizations regarding this variables are then disabled.
  1. Your variables are declared "static".
    • Use the "Watch View" to browse your variables in.

Open Project Workspace from Menu Window - Project Workspace ...

The symbol explorer has a Breakpoints node. The context menu of this node allows disable / enable of all breakpoints to the same time.

After loading of a TriCore/PCP application, setting of a breakpoint in PCP code and starting of the TriCore application the breakpoint seems not to work.

The reason is that a PCP breakpoint is realized by code exchange. The TriCore startup code of all known compilers initializes the PCP code memory (RAM) and therefore overwrite the breakpoint code. For debugging of PCP code it is necessary to execute the TriCore application at least until main function and then set the PCP breakpoints.

To setup register settings, when UDE connects to the target, edit the values from the Config - Target Interface - Connect/Reset- Execute Initialisiation Commands page ...


  SET <dst_register> <value> [<mask>]
  COPY <src_register> <dst_register> [<mask>]

  <dst_register> | <src_register> := <register_addr> | <register_symbol>
  <value> := <hexnumber>h
  <mask> := <hexnumber>h

  <register_addr> := <hexnumber>h
  <register_symbol> := <textstring>


  SET: * = (* & ~) | ( & )
  COPY: * = (* | )
  EINIT: Execute EINIT command
  DISWDT: Disable Watchdog


Set the XPEN bit in SYSCON register independently from the WRL/BHE/WRH control.

  SET SYSCON 04h 04h

'????????' is shown, when the respective memory location could not be read, even with established target connection ...

Some architectures / controllers implements a status when the debugger reads memory. Location where '????????' is shown are normally non existing memory or the memory access is not allowed due to current target's processor mode.

General mistakes ...

  • wrong interface cable used
  • wrong Universal Access Device connector used

ASC bootstrap loader Monitor Interface:

  • Possible Reasons for Communication Errors
    • power supply fails
    • ASC bootstrap loader mode in the target system not selected (if applicable)
    • target not in RESET/Bootstrap loader mode
    • wrong target configuration file used when launching UDE
    • no external RAM for the monitor available
    • no external RAM for the interrupt vector table available (0x0000 to 0x01FF)
    • selected baud rate overruns external hardware
  • Additional Diagnosis:
    • Using the MiniMonitor Interface the diagnosis capabilities of the debugger are made available if external RAM access does not work at all.

ROM Monitor Interface:

  • Possible Reasons for Communication Errors
    • power supply fails
    • bootstrap loader mode is selected
    • wrong target configuration file used when launching UDE
    • ROM content not correctly programmed
    • no external RAM in the monitor data area available
    • selected baud rate overruns external hardware

UDE Memtool fails with the message "Unknown FLASH Type".

UDE Memtool stores FLASH memory descriptions within the database file< UDE_DIRECTORY>/extflash.dat. The message above means, that the current FLASH memory is not described in the database. You may extend the database by appending a new FLASH memory definition or an alias FLASH memory definition, if a compatible FLASH memory is defined already. Refer to the FLASH memory datasheet for information about the FLASH device IDs and the internal bank structure. Additionally please note the header of the database for further information.

Use a simple text editor to edit a FLASH memory description or to add a new FLASH memory device into the database.

FLASH memory definition:

  Name= <flash_name>
  Bank0= <bank_0_size> {,<number_of_equal_sized_banks>*}
  Bank[N]= <bank_n_bytesize>

Alias FLASH memory definition:

  Name= <flash_name>
  Alias= <family>.<vendor_id>_<chip_id>


  <family> := <predefined_textstring>
  <vendor_id> := <hexnumber; 2digits>
  <chip_id> := <hexnumber; 4digits>
  <flash_name> := <textstring>
  <bank_n_bytesize> := 0x<hexnumber>
  <number_of_equal_sized_banks> := <decnumber>


  ; 8 MBit, 16-bit chip, bottom boot block, AMD
  Bank4=0x10000, 15*

  ; 8 MBit, 16-bit chip, bottom boot block, Hyundai
  ; (Alias mapped to Amd29F800B)
  1. MSG: UDEDebugServer: holded by CPU exception: ..
  2. WARNING: TcCoreTargIntf: cannot set exception handling at start address: ..
  3. WARNING: TcCoreTargIntf: exception handling at .. temporary disabled

What is the background of this behavior ?

Usually the program code should handle the TriCore exceptions/traps by correct initialization of the BTV (Trap Vector Table Pointer) register and providing a trap vector table. If the program does not handle the traps the TriCore can crash unexpectedly by occurrence of a trap.

UDE supports the debugging of programs that does not implement the trap handling. Enable the UDE trap handling by the dialog 'TriCore Traps' from the menu Debug - Setup TriCore Traps (per default enabled) and set the BTV register to a meaningful value.

The error/warning messages above occur under following circumstances (if UDE implements trap handler):

  1. If a real trap occurs, the TriCore program will be stopped and the first message will be shown.
  2. If the BTV register is pointing into the program location and the program oversteps the trap entry point, the program will be stopped by the UDE trap handling and the first message will be shown. Set the BTV register to point in a location outside of the program code.
  3. If the BTV register is pointing into read/only memory and the debugger tries to handle the traps, the second warning message will be occur because the debugger cannot map the trap routines. Set the BTV register to point in read/write memory.
  4. If the program was stopped at the trap entry code, the trap handling will be disabled temporary because of the impossible reentry into the trap handling code. The third warning will be occur.

Please note that the UDE exception/trap handling is enabled per default. The BTV register is setup via the initialization commands.


  UDEVisualPlatform[.exe] [ -p] [ -s] [ -d]


  -p .. open or create a workspace
  -s .. run a startup script
  -d .. write diagnostic output into file

The UDE software was built and tested under accurateness. Anyhow errors will be occur ...

Please give the pls team your valuable feedback as we continue to build the next version of Universal Debug Engine. For a simple feedback please use an email to support@pls-mc.com.

In case of crashes please fill in the 'UDE Support Request Form' from UDE (use the UDE menu Help - UDE Support Request Form when a workspace is loaded) or act the following steps additionally:

  1. Increase the UDE internal Debug Trace Level. Use the menu Config - Debug Server Configuration - Debug Server - Diagnostic Messages-Debug Trace Level and set the value to 100 respectively pull the slider to the right for 'Report all Messages'. If the debugger cannot connect to the target, answer the occurring error box with 'Ignore' and make the setting described above. Restart UDE.
  2. Cause the error and note the procedure.
  3. Write the content of the 'Command View' into a file. Use the context menu, choose Save... or push the Ctrl-S / Strg-S keys. Choose a file name, for example 'CommandLog.txt' and save the file.
  4. Use the UDEAdmin.exe from the UDE program directory to create a report of installed components of UDE and save it as 'Components.txt'.
  5. Please send an email to the pls Support Team at support@pls-mc.com with following content:
    • a short description of the procedure to cause the error
    • the generated file 'CommandLog.txt'
    • the generated file 'Components.txt'
    • the file '_connection_lost_report_.txt' from your UDE directory
    • the used target configuration file '*.cfg'. If you do not know, where the file can be found, please open the menu Config - Target Configuration and get the file location from the Target Configuration File box. If the debugger cannot connect to the target, answer the occurring error box with 'Ignore'.

Our Support Team will contact you as soon as possible.