Extremely long delay loop on PIC16F84

I am working on my first project using a 4MHz PIC16F84. The whole purpose of the project is to set portb<0> pin from HIGH to LOW for a
prolong period (as much as 30 minutes) before tuning back to HIGH upon detection of activity at porta pins.
My idea is to cascade a series of fully loaded counters (I am using 4 8-bit file registers, i.e. count1 to count4, in my experiment) so as to generate the required lengthy delay. The idea is simple but it doesn't work out as expected however.
What's strange about the counting process is count3 will only count from 0xFF to 0xF5 before reseting itself to 0xFF. That is where my trouble is about. It has been confirmed both on simulator and my hardware circuit. If I load the counters with smaller initial values, say 0x0F, the problem disappears. Of course, smaller values doesn't generate long delay. Can somebody give me some idea about why the PIC behaves differently from what the programme logic states?
Below is the problematic code that I've been experimenting. Thanks for any help.
;;;;;;;;;;;;;;;;; PROBLEMATIC PIC CODE ;;;;;;;;;;;;;;;         list pF84         radix    hex          porta        equ    0x05 portb        equ     0x06 count1        equ    0x0c count2        equ    0x0d count3        equ    0x0e count4        equ    0x0f
        org 0x000 ; processor reset vector         goto    start              start    movlw    0xff     tris    porta        ; configure porta as input port              movlw    0x00     tris    portb        ; configure portb as output port     clrf    portb        ; set portb LOW          scan    btfss    porta, 0     call    timer     btfss    porta, 2     call    timer     btfss    porta, 3     call    timer             goto    scan    
timer    bsf    portb, 0    ; set portb<0> HIGH
    ; initialise count1 to count4     movlw    0xff     movwf    count1             movlw    0xff     movwf    count2             movlw    0xff     movwf    count3             movlw    0xff     movwf    count4                  delay    decfsz    count1, f     goto    delay     movlw    0xff     movwf    count1              decfsz    count2, f     goto    delay     movlw    0xff     movwf    count2              decfsz    count3, f ; THIS GUY NEVER COME TO ZERO BUT 0xF5, WHY???     goto    delay     movlw    0xff     movwf    count3              decfsz    count4, f     goto    delay              bcf    portb, 0    ; set portb<0> LOW     return
    end
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
CFF wrote:

[snip]
Is the watchdog resetting the processor?
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On 6 Nov 2004 09:08:38 -0800, the renowned snipped-for-privacy@myrealbox.com (CFF) wrote:
<code snipped>
Turn off the WDT or add a CLRWDT instruction in your timing routines such that it gets hit at least every 7msec (no prescaler).
Best regards, Spehro Pefhany
--
"it's the network..." "The Journey is the reward"
snipped-for-privacy@interlog.com Info for manufacturers: http://www.trexon.com
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
This link is useful: http://www.piclist.com/techref/piclist/codegen/delay.htm
cheers,
Al
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
It is possible the watchdog timer is interrupting you (that depends on the other code present). Putting in a CLRWDT at the appropriate point would solve that. I am not familiar with the PIC16F84, but don't most PICs have SFRs at 0x0c through 0x0f? If this is true for the PIC16F84, they could change because of the functional state of the associated peripherals.

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.