Specifications

Section 19. Troubleshooting
19-2

SkippedRecord - Increments normally caused by skipped scans, which
occur when a table called by the skipped scan is supposed to store data.
These counters are not incremented by all events that leave gaps in data,
including the CR1000 powering down or the CR1000 clock being
changed.

ProgErrors -- If not zero, investigate

Memoryfree -- Too small a number leads to problems.

VarOutOfBound - The CR1000 tries to write which variable has gone
out-of-bounds at the end of the CompileResults message. The CR1000
does not catch all out-of-bounds errors.

WatchdogErrors -- Non-zero indicates the CR1000 has crashed, which
can be caused by power or transient voltage problems, or an operating
system or hardware problem. For many types of crashes the CR1000 will
sometimes write information at the end of the CompileResults register
indicating the nature of the last crash.
19.1.2 Program does not Compile
Although the PC CRBASIC compiler says a program compiles OK, it may not
run or even compile in the CR1000. Reasons may include:

The CR1000 has a different (usually older) operating system that is not
compatible with the PC compiler. Check the two versions if in doubt (the
PC version is shown on the first line of the compile results).

The program has large memory requirements for data tables or variables
and the CR1000 does not have adequate memory. This normally is
flagged at compile time, in the compile results. If this sort of error occurs,
check:
a)
For copies of old programs encumbering the CPU drive. The CR1000
will keep copies of all program files ever loaded unless they are
deleted, the drive is formatted, or a new OS is loaded with DevConfig.
b)
That the USR: drive, if created, is not too large. The USR: drive may
be using memory needed for the program.
c)
That a program written for a 4 MB CR1000 is not now being loaded
into a 2MB CR1000.
d)
That a memory card is available if the program is attempting to access
the CRD: drive.
19.1.3 Program Compiles / Does Not Run Correctly
If the program compiles but does not run correctly, timing discrepancies are
often the cause. Neither CRBASIC Editor nor the CR1000 compiler attempt to
check whether the CR1000 is fast enough to do all that the program specifies in
the time allocated. If a program is tight on time, look further at the execution
times. Check the measurement and processing times in the Status Table
(MeasureTime, ProcessTime, MaxProcTime) for all scans, then try