UDE Message Frequently Asked Questions
An update of the IO Pod configuration is needed, if you see this message. This might be caused by new version of UDE or if you select another communication mode (e.g. DAP instead of JTAG). Please follow the steps below to update or change the configuration.
Open the UAD Configurator: Start via system start menu All Programs - Universal Debug Engine - Tools - UDE Access Device Configurator ( or run UADConfig.exe directly).
Update the configuration:
More information can be found in the UAD-Config help. If there are problems, please contact firstname.lastname@example.org
This error message was caused by UDEs symbol engine database. The appropriate database file is located to deep inside the systems path.
Background: UDE stores data from ELF file inside this database. Usually the database (*.sdf) is located in the same directory as the ELF file.
To resolve the problem, place the ELF file in a directory with a shorter path. The length (incl. *.elf) should not exceed 235 characters. If this isn't feasible, you may place UDEs symbol database in another directory, see below.
If you get this message despite short path, then your ELF file might be located on a mapped drive (e.g. a ram-drive or a ClearCase Repository). In this case you should place the symbol database on a local drive (e.g. temp folder).
Change symbol database path:
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
directory. On command line run:
within your UDE installation folder and all components should be registered successfully.
If you use an old access device with a new UDE version, there may be a loader update for the Access Device required. This update can't be applied over Ethernet, please follow the steps below, to update the loader. To update a UAD2+, which is normally connected over Ethernet, you must connect the UAD2+ using USB or FireWire and apply the update.
MSG: UAD2CommDev: Loader update succeeded, new version: Vx.xx.xx
If there are some problems, please contact email@example.com.
You may get this message, if you update the UDE version and there is a new version of firmware/loader for the Access Device included. This update is normally applied automatically. The loader update will be applied, if you connect the first time to the target. It will take a few seconds and you will see a progress bar while the update is applied. (Old versions of UDE seem to hang for the time, please do not kill the process or turn of the Access Device! ...be patient.).
If the update was successful, you will see the following message in the command view:
MSG: UAD2CommDev: Loader update succeeded, new version: Vx.xx.xx
The update can't be executed, if you use a UAD2+ connected over Ethernet. In this case you will get an message similar like:
MSG: UAD2CommDev: Couldn't execute required Loader Update over Ethernet ! Use USB or Firewire for Update
To update such a device, please follow the steps mentioned in the Hardware FAQ.
This message occurs, when the target system was started in 'Alternate Boot Mode' and the option Safe ABM header handling is not enabled. The message should prevent the user from erasing the ABM header accidentally. The Memtool add-in features the option Safe ABM header handling, which ensures the prevention of the 'ABM header' from the FLASH programming automatically. On this way, the reconnect to the target system is ensured.
Background: Using the 'Alternate Boot Mode', the microcontroller expects a special boot block in the FLASH memory area, the so-called 'ABM header'. If the 'ABM header' is corrupt, the boot procedure will fail and a connection to the target system via JTAG will be impossible.
What are reasons of this error message and how can I solve it? The message occurs, when
SimIO or Simulated I/O is one of the UDE features. It allows the usage of the printf/scanf functions to transfer characters between the user application and the debugger (via Simulated I/O Window) via the debugging communication channel (JTAG, ASC, ..). It supports the so-called printf-debugging. Examples for using the SimIO feature can be found within the UDE installation as Sieve sample for many target architectures.
For using this feature the variable 'g_JtagSimioAccess' must be defined in the user program for allowing the communication. When the Simulated I/O Window is open, and this variable is not found, the messages above is printed in the command view. If SimIO is not used, close the Simulated I/O Window to avoid the message output.
You can configure advanced break conditions (In addition to breakpoints). The complexity of this hardware triggers depends on used target. The program will halt if the configured conditions match. Then this message will be displayed in command view.
Use the menu: Debug - Setup trigger unit to change (or disable) the trigger.
Usually the program code should handle the TriCore exceptions/traps by correct initialisation of the BTV (Trap Vector Table Pointer) register and providing a trap vector table. If the program does not handle the traps it 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 (UDE implements the trap handler):
Please note that the UDE exception/trap handling is enabled per default. The BTV register is setup via the initialisation commands.
While downloading of a program code the target pattern are checked via a CRC checksum algorithm. If the check fails the message above will occur. The reasons may be
While ROM stepping the trap handling by the debugger is not possible, because the traps cannot be caught by UDE. To avoid this error please disable all entries in 'Config - Target Configuration - Debug - Handle this Controller Exceptions'.
To use the trap handling feature anyway either the trap vector table must be located in RAM or all traps must be masked with the debug instructions SBRK (Opcode 0x8C00). The pls Development Tools prepares a tool for patching the debug instructions into the trap table. Please contact the pls Support Team for the availability of the tool.
UDE uses a Microsoft SQL Server Compact database to store debug symbol information.
The database is created with encryption. If it fails, then UDE will display the error message from Microsoft SQL Server Compact.
There is a known issue with encryption and Microsoft provides a hotfix: http://support.microsoft.com/kb/972002/en-us