This is probably quite simple

My program (below) executes only once. Even if I remove power and re-apply, it won't execute again. What have I done wrong?

LED VAR BYTE
symbol config = $2007 'address of configuration register

PORTB = %00000000
TRISB = %1111100


poke config, %10000110100001 'Set pin #4 as Master Clear, use
'pullup resistor. Set oscillator as
'XT, use 4mHz quartz crystal.


again:
pause 30 'wait 3 seconds
for LED = 1 to 5
PORTB.0 = 1
PAUSE 63 'turn on LEDs for 63 milliseconds
PORTB.0 = 0
pause 63 'turn off LEDs for 63 milliseconds
next LED
PORTB.1 = 1
PAUSE 5000 'turn on sound for 5 seconds
PORTB.1 = 0
goto again ' for testing purposes only

Your code can't poke any value into the config word location. This area is only accessible at program time.

Thanks, I erased the 16F627A and reprogrammed without the POKE statement. Now it goes around the loop for several minutes before pausing for about 1 minute, then goes around the loop again. Have you any idea why it pauses?

The compiler (or programmer) must be putting in a default configuration. How do I know what that is, and how do I change it?

I'm not sure why it would ever pause that long, but first read this on setting config fuses, make sure you're getting it setup like you want, then see what happens when you run your example.

Config fuse article: http://www.picbasic.co.uk/forum/showthread.php?t=543

Please see the program listing below. Now the problem is that the program re-executes even tho it is not supposed to. When power is applied, the oscillator starts and the program executes as it is supposed to. At the end, the oscillator stops for about 30 seconds, then starts again. I turned the Watchdog timer off thinking that would prevent it from starting again, but that did not work. If I wait long enuf, the program will re-execute and the process repeats (except the oscillator does not stop) as long as the power is left on. When I remove power and re-apply, the oscillator stops; the chip is dead. If I leave power off over night and try again, it will work again. All three port outputs are connected to LEDs. Eventually I will use port4 to turn the power off which will prevent this problem, but I would like to know why it works this way. Evidently, either the program, assembler, or IC is flaky. Or maybe it is the fact that I am using a breadboard?

@ DEVICE WDT_OFF
LED VAR BYTE

PORTB = %00000000
TRISB = %1101100

PORTB.4 = 1 'enable V reg
pause 3000 'wait 3 seconds
for LED = 1 to 5
PORTB.0 = 1
PAUSE 63 'turn on LEDs for 63 milliseconds
PORTB.0 = 0
pause 63 'turn off LEDs for 63 milliseconds
next LED
PORTB.1 = 1
PAUSE 5000 'turn on sound for 5 seconds
PORTB.1 = 0
PORTB.4 = 0 ' TURN OFF POWER
end

It's just plain bad practice to stop your code dead like that with an end statement... The end statement is there to tell the compiler there's no more code to compile, NOT to tell the processor to stop!

If you want to end execution, send the device into an endless loop...

deadloop:
pause 1000
goto deadloop ' loop till doomsday

If you examine what's happening in your PIC, the program counter keeps incrementing and your PIC will keep on executing whatever code is remenant in the PIC. When you program a PIC, unless you specify otherwise, your PIC will not first be erased, all that happens is your new code replaces what was there previously. If your new code is smaller than what was previously in memory, then some of the previous content will remain and once your code executes, it will happilly continue into whatever garbage was there previously. You must therefore terminate your program logically. Most if not all programs are continuous loops. If your application demands a 'once-only' execution, you must program-in a suitable termination. Even if your PIC has first been erased, the PIC will continue with NOP statements untill it reaches the end of program codespace at which point what it will do will be unpredictable... it might restart, it might not, but it sure as hell will be unstable.

Oh... and the reason I put a PAUSE statement in is that PICBasic will insert code to keep the watchdog timer happy. If you just had...

deadloop:
goto deadloop

then the Watchdog (if enabled) will time out and restart the PIC as PICBasic would not had inserted a CLRWDT in that instance.

...or of course use PICBasics STOP statement!

you example expanded...
.. ..
PAUSE 5000 'turn on sound for 5 seconds
PORTB.1 = 0
PORTB.4 = 0 ' TURN OFF POWER
STOP
end

Thanks much for the info, I am learning (more by making mistakes than otherwise). I am embarrased to say this, but even tho I wrote it in my program "use 10k pullup on MCLR", I neglected to do it. Now that it is installed, things work like I expect.

I tried the pause loop and the stop command but both leave the oscillator running and the current draw is 800 microamps. I tried sleep $FFF with the watchdog timer turned off;this stops the oscillator and, after a few minutes, it settles down to 40 microamps current draw which is quite acceptable.

>I tried the pause loop and the stop command but both leave the oscillator running and the current draw is...

Yes, but getting the current down is moot because if you look at your logical flow when you get your hardware sorted out the PIC will switch itself off before you get to the STOP point... it's only until then you need a way of stopping you code, thereafter, if everything is working as it should, you'll never get to that point (well in reality you will but the PSU would be in the throws of shutting down anyway).

How do you disable the watchdog timer in picbasic? I am trying to step through a program with the ICD2 and I keep getting the error that you can't debug with the watchdog timer enabled.

You've not specified what PIC you're using... so, go look in the Datasheet for your PIC... it's usually a setting of the Config Word and that information can be found in the "Special Features of the CPU" section of the Datasheet. When you program your PIC, it should appear as one of the options you can manually switch ON or OFF.

Sorry about that....I am using the PIC18F452 that came with the PICDEM2 board.

I started poking around in some of the files and came across "_WDT_OFF_2H" in a "__config" statement. That solved my problem.

Thanks for the help!