The PIC contains a Watch Dog Timer (WDT)
that will cause an interrupt every 18 ms. This timer is used to eliminate
program hang-ups by forcing an interrupt. (You may read more about the
WDT on page 52 of the PIC datasheet.) This interrupt will cause the PIC
to come out of sleep and start executing code as if a user had pressed
a key. The WDT must be disabled! To disable the WDT you must pull-down
the ‘Configure’ menu from the MPLAB IDE and select ‘Configuration Bits’.
The window that will open will allow you to turn off the Watch Dog Timer.
Added Spring 2005:
Make sure that all of the elements of your language toolsuite are correct.
Under "Project" choose "Select Language Toolsuite" and make sure that none
of the programs have red x's besides them. If one does, you will
have to search for the application that should be associated with that
program. You will most likely find them in the MPASM Suite subdirectory.
Make sure that you have an active debugging tool. If you don't see
the toolbar buttons that correspond to commands like "Run" and "Halt" then
your debugger isn't active. Under "Debugger" select "Select Tool" and choose
"MPLAB SIM."
Make sure that you have chosen the right processor. Under "Configure"
choose "Select Device" and make sure that the pull-down device window shows
"P16F84." A different device may not use the same instruction set
as the 16F84, and will not be able to understand a program written using
those instructions.
If strange things happen after you successfully build a program, you may
have a watchdog timer problem. Basically, the Watchdog Timer monitors
processor inactivity, and resets the processor if a sufficient number of
instruction cycles pass without processor activity. This can occur
if you leave a program running too long in the infinite loop instruction
that we use as a HALT statement. You can disable the Watchdog Timer
in simulation with no (currently observed) ill effects. Under "Configure"
choose "Configuration Bits." Click on the "Watchdog Timer" option
to bring up a pull-down menu. Choose "Off." You can also set
up a breakpoint at whatever instruction is serving as your HALT statement.
If you are running Visual Studio, then you may or may not know that Visual
Studio appears to co-opt the file extension .cod. Apparently, Visual
Studio doesn't play well with others, as it won't let other programs that
need or use files having that extension...like MPLAB...use it for their
own purposes.
To the best of my observation, computers running Visual Studio will give
linker errors when you attempt to build assembly files in MPLAB.
The visible symptoms of the problem are error messages that refer to stack
underflow or core errors. I will try to get specific error messages,
so that you know what you're looking for to see if it's happened.
The quickest solution (the one that was applied to best effect in the CEL)
is to do a clean reinstall of MPLAB. This will make MPLAB work again,
at least up to the point where you use Visual Studio to do something.
Since no one uses Visual Studio in the CEL, we haven't had the chance to
observe whether it attempts to grab the extension again.
If you use Visual Studio often, you may find the MPLAB problem to be a
recurring one. In fact, you may find the MPLAB reinstall (and apparent
de-association of the file extension) to cause problems with Visual Studio.
At this time, we have no information as to whether or not this is the case.
If you have found that installing (or re-installing) MPLAB has caused problems
with some aspect of your use of Visual Studio, please document the specifics
of your use and bring it to my attention as soon as you can.
When assembling files in a project, the only file that needs to be there
(and that should be there) is the .asm file. The presence of a linker
file (.lnk) in the project files causes problems with the building of a
program that begins at program memory address 0 (ORG 0). Removing
the linker file from the project files should remove the problem.