Troubleshooting
Where to look when problems occur



Follow link below for most frequent problems, or continue reading for "overview"
Quick reference


OVERVIEW

The amount of hardware and device drivers interraction between our own hardware and our device driver can vary from system to system and can also create a variety of problems which can often be isolated by using the troubleshooting methods described in this document.

An error condition can be the result of a problem existing anywhere within the chain of devices and drivers between the Model-301 or Model-302 (hereafter referred to as "M30x") board(s) and the application software that displays the error. A typical USB system will consist of a "root hub" and it's driver as well as a "host controller" and it's driver at the PC end of things if there are no external hubs connected. When an external hub is added additional drivers are added for each. There is the possibility of a problem existing within any individual driver which can then effect all of the other drivers and supported hardware within the chain. There is even a possibility that a piece of hardware or device driver not even related to the USB can have an effect on the USB drivers as well as all of the other drivers on the system.

A few of the most common error conditions as they are seen by the application are,
  Scan Halted
  Device Not Found
  Failed to signon
  Buffer wrap (either scan buffer or microcode buffer)
































































Quick Reference
Scan Halted
Device Not Found
Failed to signon

Other errors
( such as buffer wraps )



    Scan Halted




What to check first: Power loss or spike
Other possibilities: Low Level drivers not responding

A scan can halt as a result of problems related to both the hardware, as well as the drivers that support the hardware. For example, a common problem during inclimate weather is power outages which can sometimes last for hours but can also last for only a second or two. Another example which can cause a lack of response is when one of the drivers on the system actually "hogs the system" for only a second or two. Although a second or two seems like a very short time, it can have a very profound effect on the ability of the other drivers on the system which may require millisecond or even microsecond slices of time to properly maintain the functionality fo the hardware they are supporting.




    Device Not Found



If the device has never worked, please review   install.htm   first for issues that could be related to the way the installation of the hardware was performed or the possibility of incompatible PC hardware or external hubs.

If the device has worked but no longer signs on or appears to be unable to communicate with the device, look first at   power-related issues.

Please note that although the error indicates "Device not found" the actual error could be the result of the application not being able to access the DLL - and thus the device is not found. A common issue that creates this problem for a device that once worked but no longer works, is the installation of new software or drivers which results in incompatibility between versions of each. Please run our   "VerChk.exe"   utility to find out if there is a compatibility issues. Be sure to place   "VerChk.exe"   into the directory where your application and the DLL reside. When the utility is run, it will display the locations of as well as the versions of the DLL and Driver that it finds on the system. Sometimes the problems is nothing more than a new driver and DLL being installed but the USB cable not being disconnected and then reconnected (or reboot of the PC) which allows the old driver to unload from memoryh and the new one to load. The   "VerChk.exe"   utility will inform you if that is the problem as well as other problems that could exist.

A problem that occurs rarely is an actual failure of the host controller driver. Such a failure is more likely when a USB cable is removed and then reconnected "VERY" quickly. The error appears to be due to the inability for the various threads within the drivers to begin processing the reconnect before they completely finish processing the disconnect. This error can prevent further communication with that host controller (and thus the USB port) until the PC has been rebooted. Sometimes the problem will also show itself as a yellow exclamation mark beside the host driver within the Windows System Device Manager.




    Failed to signon



As with the "device not found" problem, a failure to signon can be the result of many issues. The first of course IS the   Device Not Found   problem, so one should refer to the documentation concerning that issue first.

Another issure that could cause this is application software and it's configuration file. Some of our sample software ships with a text based configuration file,   "LL_USB.CFG"   which requires the entry of your actual device ID number. If you don't update that file with your device ID the application won't signon since it doesn't know what to signon to. Likewise, if an error is made to that configuration file, it will become unreadable and the application will fail to signon since it won't be able to acquire the information from that file that it needs to do the signon.

As with the possibility of the incorrect device ID being entered in the   "LL_USB.CFG"   file, some of our sample software also has the option for the user to enter the device ID into a window on the main application panel. We've had customers contact us when they couldn't signon, and the problem was nothing more than the obvious issue of entering the correct device ID within that box.




    Other errors   ( such as buffer wraps )



The   "Microcode Buffer Wrap"   problem can manifest itself in various ways depending on the application software being used. We've devoted a great deal of time to do the best we can to deal with this situation when it happens as well as preventing it from happening in the first place. A microcode buffer wrap is the result of our device driver not receiving a long enough slice of time to keep the data read from the data-buffer within the M30x hardware. There are many things that can create the problem, but most of them are the result of other drivers that are poorly managed and "hog" the system time slices. One example would be the game "Pinball" that ships with versions of Windows later (and including) WinME. We've determined that when a user starts that game, our driver recieves no slices of the system time that it needs to process data for the amount of time required for that game to start - typically several seconds. We've also determined that other forms of software such as automatica schedulers (to name just a few) can do the same sort of thing.

An issue that is somewhat related to the previous paragraph has to do with maintenance of the user's PC using some of the utilities that ship with the Windows Operating System. One of the utilities we recommend using frequently is the "Disk Defragmenter". Whenever an application runs, the disk is often used to store data - sometimes in user files and sometimes in system cache files which aren't quite as obvious to the user. Since a single file can be spread across a diskdrive in small chunks, adding and deleteing files can leave a disk very fragmented. When a disk is extensively fragmented, the disk access time is also greatly effected. Since low-level drivers are used for accessing the disk drive, a fragmented disk will cause the driver to require more of the system time-slice which then effects every other driver on the system - including ours.

Another, yet less common problem is   "Scan Buffer Wrap".   This problem is related to the data buffer located within the DLL, and is usually a result of the application not calling into the DLL frequently enough to keep it's buffer emptied. This problem is usually very easily fixed by fixing the software and shouldn't be a problem that occurs within any of our "sample" software.

One of the most effective steps we've taken to deal with the above-mentioned problems (as well as a few others) that is "user interractive" is the use of the "LL_USB.INI" file. Within that file are various parameters that can be manipulated to help make our DLL and Device Driver perform efficiently on a system which may not be currently functioning as well as it should. Documentation concerning the various parameters within that file can be fournd   here.   Be careful when changing the parameters in that file, and be sure to save a copy of the original before editing it, as it is shipped with parameters that should work well on most systems. A very powerful paramter within that file is the   "ProcessPriorityBoost".   which boosts the thread priority of the DLL which in turn boosts the priority of the user application. What that does, is it causes the user application to sort of "Hog the system" which is something we usually discourage unless the option is needed to gain priority over another running application (maybe a background task the user is unaware of) in which case it is often required. A couple of other powerful options are the   "StackedIrpCntOverride".   and the   "ScanSystemBoostLevel".   Both of these parameters cause the device driver to put pressure on the more powerful (because they ship with Windows) lower level drivers causing them to give us the data we need from our hardware at a higher priority than we are typically allowed by our own driver. However, beware that setting the paramters incorrectly can have a negative effect. For example, setting the   "StackedIrpCntOverride"   to   "1".   will give less of an advantage to our driver but "will" cause the driver to use a little less memory which is rarely a problem. However setting it to a value of 20 or greater can have a very positive effect with no bad effect accept more use of memory which is rarely a problem on the PCs these days. A similar scenario exists in regard to the   "ScanSystemBoostLevel"   except it shows itself a little differently. If that value it set very high, our driver will request larger packets of data from the low-level driver which is fine, but the problem is, it won't return that data to the user until it has it all. Therefore, setting that value too high can cause your scan data to appear at the application level at a very slow rate, but in "big chunks" at a time. If a   "Microcode Buffer Wrap"   problem presents itself, it's usually best to increase the   "StackedIrpCntOverride"   to 20 or greater and if that doesn't solve the problem start increasing t the   "ScanSystemBoostLevel"   but start at the number,   "4".  































































    Power Loss or Spike



Power Loss Recovery   (follow link for recover solutions or read on for overview)

A common problem during inclimate weather is power outages which can sometimes last for hours but can also last for only a second or two. Power "spikes" can, and often do occur under a variety of circumstances - for example, large motors which are connected to a shared power source starting, or relays connected close to or within the PC (such as some modems) being activated.

If the Model-30x has it's power supply connected to a wall outlet and the computer is connected to a UPS (Uninterrupted Power Supply) the computer may give no indication that there was a loss of power while the Model-30x will automatically reset itself to recover from a loss of power. The condition is more obvious when the computer and/or monitor is also connected directly to a wall outlet. Occassionally power spikes can also occure which likewise can have more of an effect on whatever hardware is connected directly to the wall if the spike occured somewhere external to the PC such as in the wiring leading up to the outlet.

We've also experienced spikes occuring within the PC itself. Most of the spikes that occur within the PC are a result of a relay residing on an add-on card such as a modem. Such a spike can often be determined by noticing if an error condition displayed by the software seems to occur frequently when using the modem to connect to the internet. A spike can sometimes even occur if two external hubs are connected to a PC and then either the power cable to one of the hubs or the USB cable going from the PC to the hub is removed - this too happens more often if the external hub uses a relay (rather than IC) for switching.







    Low Level drivers not responding



This is a problem that occurs occassionally. It appears to be a result of unknown activity on the USB cable and is related to the low-level drivers below our driver. If performing a scan when the error occurs the scan will halt and need to be restarted. Our driver is in constant communication with the low-level drivers during a scan. Although the occurrences are somewhat random, we've seen this error occur when two USB cables are connected to the back of the PC and then one of the cables is quickly removed and reconnected. We've also seen it occur when two cables are connected to the PC and an externl hub is connected to it's power supply - not often, but occassionally and usually with an external hub that later proves to have other problems.

The low-level drivers pass information back to our driver concerning the status of the data packet it's requested as well as the status of the driver and the hardware it is communicating with. Occassionally it will indicate that it has lost communication with our M30x device, however our factory tests have shown that our devices are still functioning normally and attempting to pass the scan data back to the host. This indicates that there has been a loss of communication between the actual onboard hubs (or external hubs) and the host drivers themselves.

The only known solution is a reset of the host hubs which we do either on request by the application or somewhat seamlessly the next time an I/O is attempted by the user application.
































































    Recovering from power loss or spike



1.)    Often all that is required is a reinitialization by the application. When a power outage has occured, certain codes are passed from the hardware to the driver and finally to the application by way of the DLL. One or more of the codes represent a cycling of power to the M30x device which is an indicator that a new initialization is required. Depending on the software being used, a reinitialation may automatically be performed by the next attempted I/O seen by the DLL.

2.)    Check that all power cables are connected. One thing that is frequently overlooked is a power cord that isn't plugged all the way into a recepticle. Another thing that happens occassionally is the toggle (on/off) switch found on many power strips can accidentally be pushed to the "off" position when the power adaptor module is connected.

3.)    If connected to an external hub, check to see that the LED(s) that coincide with the port on the hub that the the Model-30x is connected to is lit. If not, the hub may need to have it's power cable disconnected and reconnected. If the LED(s) still don't turn on, the USB cable to the external hub may need to be disconnected and reconnected and if the LED(s) still remain off, try rebooting the PC. If the LED(s) on the external hub still remain off, the external hub may have been damaged by a power spike in which case it will need replaced. However, if the an external hub and/or the M30x is connected to a "power distribution strip" the strip may have been damaged by a power surge - this can usually be determined by connecting a known good appliance such as a lamp to the power strip to see if there is power going to the strip's outlets.




























lawsnlab@lawsonlabs.com
last modified: 12-16-03