INtime SDK Help
Troubleshooting
This topic lists problems you may encounter while running INtime software, and explains how to avoid or resolve those problems.
See the documention on License Manager for more information. Look for the -w and -w -d options.
If your clock battery failed or the system clock was changed back by more than one day after you install the software, the license management software considers this action as an attempt to defeat the licensing, so will fail.
Restoring the clock value will allow the system to continue to function.
Be careful that when installing a license generated from a fingerprint that the license is being installed on the correct host.
Prior to INtime 5, a node-locked license is keyed in part from the volume ID of the system volume of the Windows installation. If you replace or reformat the disk drive then your license will be invalidated. After INtime 5 the disk hardware ID is used instead so this is no longer an issue. However, if the storage medium is a RAID volume then there is no unique disk ID so the license reverts to using the Windows volume ID. Some default BIOS settings enable RAID even with only one disk. Make sure that RAID is disabled in the BIOS before reformatting the disk drive to avoid invalidating the license for future drive reformatting. A fingerprint with RAID enabled will create a license that will be invalidated after a disk reformat.
Starting with INtime 7, a fingerprint from INtime 7 with RAID enabled will use the disk hardware ID so the license remains valid even after a disk drive reformat.
Use the correct USB key
If you have multiple development kits each with their own key, be sure to use the correct key with each development kit.
I started the INtime kernel but it did not start (INtime for Windows)
Inspect the event log. Open the Windows Event Viewer and inspect the INtime log. To access the event log, click on INtime status monitor icon and select Event Viewer from popup menu. Look for error messages from the INtimeKernelManager service, which should explain why the kernel failed to start. Possible failures may include the following:
License failure
If you receive a message about license failure, inspect the cases in the “License Failures” section.
Memory not available (INtime for Windows)
If you have configured memory from the Windows non-paged pool and you find a message “memory not available”, Windows was unable to allocate the required memory in a single contiguous allocation. If running on a 32-bit version of Windows and there is 4 GB or less of RAM installed, consider changing the configuration to “Exclude memory from Windows”. This reserves memory at the top of available RAM before Windows is ever booted and prevents Windows from using it. INtime then uses that memory.
No Rt Node Memory is available
This may be caused by applying a configuration from one host onto a host with more cores, resulting in incorrect memory descriptions in the registry. This also confuses the INtime Configuration Tool. Configuration files may result in errors when the hosts differ in the number of cores or in memory size. Use LNC to avoid these problems. See Deploying Your INtime System and Local Node Configuration.
The system freezes or resets when I start the kernel
1. Bugcheck event (“bluescreen”) occurs.
The INtime product has a feature which can intercept bluescreen events (Windows “STOP” or "Bugcheck" events) so that if an event occurs which causes a bluescreen, the system will freeze. In this case the INtime kernel continues to operate until it decides to release Windows and allows it to completely shutdown. If this feature is disabled (The Windows Bugcheck Interception feature in the System parameter in INtime configuration is set to “Do not Trap Windows Bugcheck Exception”) then the bluescreen will occur. However, if your Windows system is configured to automatically reboot after collecting the dump information you may not have time to observe the event.
2. An automatically-loaded application is causing the system to freeze.
INtime for Windows: open the INtime configuration and disable the autoloader. In the Node Manager, select your node then select the Auto Load tab. Check the "Disable Auto Load" box. Start the kernel again.
A real-time application may cause the host to hang in a couple of cases:
• If a thread continuously executes (“spins”) it will prevent threads of a lower priority from executing. (In shared mode this can cause interface between INtime and Windows that makes it appear as if Windows is completely hung.) There is an INtime utility to detect this, called “Spin Doctor”. See the appropriate documentation to configure this utility.
• A hard to detect error could be caused by wrong priorities and deadlocks. A very good tool to track the dynamic execution of an application is INscope. Use this tool to write a trace of thread switches, API calls, interrupts and even user defined events. The tool itself has help included and incldes an API to control some of the functionality during from within the user code.
• Hardware faults like divide by 0 or page faults are by default caught by the INtime kernel and the faulting thread suspended. In the case where a thread is interrupted and the fault occurs in the interrupt handler, the interrupted thread may be suspended. This may cause a critical kernel thread to be suspended which causes lock-up. Keep interrupt handlers simple and short. See the Debugging section about how to debug interrupt handlers. When running the application from a PC with the SDK, you can use any debugger present on your host, selected from a dialog, which is shown when the HW error is caught. Select the version of Visual Studio to use. The INtime Spider debugger is also available, but it is not as user friendly as Visual Studio. Another option is to select Analyze Exception, which opens the INtime Explorer to examine the threads in the process which caused the exception. Normally the current program counter and the disassembly at the fault location as well as the register content is displayed. From the map file of the application, find the corresponding source function. A crash report file is also generated, which can be analyzed by INtime explorer. Use View -> Crash Log.. from the menu and select the rtc file with the name of the node (default NodeA.rtc). From the next dialog select the entry with the actual Date/time and the right rta. Provide the location of the rta and if possible the pdb file is loaded. A report is generated and stored as a text file with additional information about the current process state at the time of the exception, which should help to find the root cause in the application.
There are different memory sections in every application which can cause runtime errors. The stack needs to be big enough to store all the needed information during function calls. Recursion or unintended stack writes (accessing objects out of bounds) can lead to situations where the return address is wrong, local variables are overwritten, or in the best case the application crashes. Calculate the stack requirements correctly during development and use the appropriate settings when creating threads.
Out of system memory errors occur if too many applications are loaded at same time and the total memory assigned to the INtime node is too low. Check the return values from memory allocations to avopid code just failing to execute. Always check the return values and take appropriate actions (warnings on screen or log entries) when memory is too low.
Heap is the last memory area which can cause trouble during long term program execution. Things like fragmentation or write out of bounds are hard to detect and test for, but you might find some help using the debug heap library.
If a device is to be used by INtime on an INtime for Windows host, then the device must first be assigned to an INtime node using the INtime Device Manager. See Configuration for details.
It is not permitted to share a legacy interrupt line ("IRQ") between devices controlled by both INtime and Windows. This is because both device drivers, one on INtime one on Windows, have to handle the interrupt before the next interrupt can be asserted, which loses the ability of handling the real-time interrupt in a deterministic way. The Device Manager prints a warning when you attempt to share an IRQ between INtime and Windows.
The most likely cause of this is that the Windows Device Interface is expecting a Windows device driver to be installed before it can replace it with the INtime dummy device driver (rtdrm.sys). If you do not have a Windows device driver for your device you can apply rtdrm.sys manually by using the Windows Device Manager, select the device, then Update driver... and navigate to %INTIMECFG%\drivers to install the driver.
I cannot install an interrupt handler for my device
If SetRtInterruptHandler(Ex) fails and returns a status 0x8004 (E_PARAM), assuming that the parameters are correct, the other reason for this failure is that the kernel does not know that the device is assigned to this node. Make sure that the device is assigned to the INtime node by using the INtime Device Manager.
If Visual Studios is open or has recently been open, or if the INtime development tools did not cleanly uninstall, INtime help may fail to install.
If this error is observed, execute the install again to install without an error.
If you installed Visual Studio after installing INtime you need to perform an additional step in order to include the INtime components in Visual Studio. Go to Control Panel -> INtime -> Development Tools, and click on the Install button for the version of Visual Studio which you are using.
The INtime project type and the debugger require a valid license to be installed. See the section on “license errors”. It is possible to configure your solution so that you can edit and compile it without the need for a license to be installed. See the article at: https://tenasys.com/my-tenasys/knowledge-base/knowledge-base-page/?pageNum=19
Visual Studio hangs when I debug my interrupt handler: You cannot debug interrupt handlers using Visual Studio. Keep interrupt handlers short and simple and debug the code in the interrupt thread. If you really need to debug your handler, see the section in “Debugging”. Perfmon.exe and INtime performance counters