Have you ever made the mistake of addressing memory in the wrong page or bank? Rather then losing valuable development time to debug such common problems use the Scan Tool to find them before starting the emulator or programming a microcontroller. Instead of ignoring all the message 302 warnings let us flag the ones that are really a problem.

Message[302]: Register in operand not in bank 0. Ensure that bank bits are correct.

It takes about 30 minutes to emulate, find a problem, isolate the problem, fix it, and retest a typical memory addressing bug. Longer when you have to program parts or troubleshoot code created by someone else. So we have purposely priced the Scan Tool for what many companies would consider the cost of catching just one problem in your code.

The Scan Tool attempts to simulate your source code for all possible conditions and then analyze the results to look for memory addressing errors. These errors are quite common on processors with multiple RAM banks or ROM pages. While you could use a BANKSEL before every RAM access or a PAGESEL before every ROM access it could waste more than 20% of your program space and execution time. With the Scan Tool you can comment out the BANKSEL and PAGESEL macros, run the scanner, and then uncomment the lines that resulted in errors.

During the scan, the stack depth is tracked and tested against the max stack depth of the interrupt handler. If the combined total is greater than eight, a stack overflow warning is generated. An error may never occur in your program because the right events may not line up together. But when it does, these are very difficult bugs to track down. The scan tool exposes the possibility so you can flatten your code to use less subroutine depth in the critical routines.

While checking the interrupts the scanner will also make sure that the W and the STATUS registers are properly saved before the interrupt routines modify them. An unexpected benefit we found in beta testing was that it also catches the error of storing the saved W and STATUS registers in banked RAM. If it were possible for an interrupt to occur when the processor is in another bank, the temporary storage could overwrite other variables or return garbage. Either case would have been very difficult to track down prior to our tool that can flag broken code before the first instruction is ever executed.

We you run the Scan Tool after every compile. It only takes a few more seconds to save potentially hours of debugging frustration. Also run it on every product you have shipped to customers and make sure that you are not creating warranty liabilities with buggy code.

Since the Scan Tool is under continuous development we include one year of technical support and free updates with your license purchase. The planned improvements coming in the next year include adding PCL modification support, the official release of v1.0, support for more devices, and additional test coverage for your code. Maintenance contracts for additional years of support and updates can be purchased at any time to keep your license up to date.

We encourage your participation in our development by requesting new features, reporting bugs in our software, and giving us feedback on how the tool works for you. We will respect your privacy if you would please report when the scan tool successfully finds a problem in your code.

When you purchase the license to run our code on your computer you also get our newsletter. The newsletter lets tells you what's new and shares experiences gained from all our users.

Purchase a new license or maintenance contract now.

Limitations of current version:

• INDF writes are not tested, make sure FSR did not point to STATUS or PCL
• PCL modifying instructions not simulated, but treated as NOP or RETURN
• Lookup tables and unreachable code are not scanned
• STATUS modifying instructions are currently limited to BCF, BSF, and CLF
• Always case sensitive
• Default radix of hexadecimal must be used for constants
• Cannot interpret compile time variables