31KHz Watchdog reset ... but for no obvious reason

PhilHornby

Senior Member
I have some code running on a 14M2, that is triggering the 'well-known' 2.1Sec Watchdog Reset when running at a clock speed of 31KHz ... even though it doesn't take anything like 2.1 Seconds to execute :confused:

This is the code :-
Code:
            [COLOR=Red][I]setfreq k31[/I]                                     ;low power previously engaged ...
            [/COLOR][COLOR=Blue]do 
            [/COLOR][COLOR=Green];**   setfreq K125                              ;Must be executed at 125KHz or above...
                  [/COLOR][B][COLOR=Blue]high LEDPin [/COLOR][COLOR=Black]: [/COLOR][COLOR=Blue]nap [/COLOR][COLOR=Navy]1 [/COLOR][COLOR=Black]: [/COLOR][COLOR=Blue]low LEDPin          [/COLOR][/B][COLOR=Green];about 32mS 
                                                            ;@ 31KHz, when the LED goes off, the processor resets?!?
            ;**   setfreq k31
                  [/COLOR][COLOR=Blue]nap [/COLOR][COLOR=Navy]5                                     [/COLOR][COLOR=Green];wait 576mS
                  [/COLOR][COLOR=Blue]PeekSfr IOCAF[/COLOR][COLOR=Black], [/COLOR][COLOR=Purple]SwitchChecker              [/COLOR][COLOR=Green];get pin no.s that have edge detections
            [/COLOR][COLOR=Blue]loop while [/COLOR][COLOR=Purple]SwitchChecker [/COLOR][COLOR=DarkCyan]= [/COLOR][COLOR=Navy]0                    [/COLOR][COLOR=Green];wait for switch to be pressed again[/COLOR]
Without the 'setfreq k125 command, the Picaxe resets immediately after executing the 'high : nap : low' sequence. The sequence itself works successfully and gives a short 'blip' of an LED. I have tried splitting it into 3 separate statements, but to no avail. I have tried a second 14M2, with exactly the same results.

I've been staring at this for quite a while and can only think I'm missing something blindingly obvious. I can't see what is so special about the HIGH/NAP/LOW sequence, compared with code that has already been successfully executed @ 31KHz.

This is some of the immediately preceding code - that works OK :-

Code:
            [COLOR=Blue]setfreq K31                                     [/COLOR][COLOR=Green];save power
            [/COLOR][COLOR=Blue]low LEDPin                                      [/COLOR][COLOR=Green];turn off LED - as acknowledgement
            [/COLOR][COLOR=Blue]do while [/COLOR][COLOR=Purple]SwitchPin [/COLOR][COLOR=DarkCyan]= [/COLOR][COLOR=Navy]0                          [/COLOR][COLOR=Green];really do need the user to release switch!
                  [/COLOR][COLOR=Blue]nap [/COLOR][COLOR=Navy]0                                     [/COLOR][COLOR=Green];18mS
            [/COLOR][COLOR=Blue]loop
            
            [/COLOR][COLOR=Green];
            ; Hurray - switch released!
            ;
            [/COLOR][COLOR=Blue]nap [/COLOR][COLOR=Navy]4                                           [/COLOR][COLOR=Green];wait for switch to stop bouncing (probably unnecessary)
            
            
            [/COLOR][COLOR=Blue]PokeSfr IOCAF[/COLOR][COLOR=Black], [/COLOR][COLOR=Navy]0                                [/COLOR][COLOR=Green];reset Switch detections
            [/COLOR][COLOR=Purple]SwitchChecker [/COLOR][COLOR=DarkCyan]= [/COLOR][COLOR=Navy]0                               [/COLOR][COLOR=Green];say we've not seen any[/COLOR]
Any thoughts?

UPDATE: I don't know if it is pertinent, but this code is running in #Slot 1 of the 14M2
 
Last edited:

slimplynth

Senior Member
I do need to be better with WatchDogs so know this thread will help me for sure.. but looking at your code, have you tried using higher clock speeds to compare what happens?
 

AllyCat

Senior Member
Hi,

.... what is so special about the HIGH/NAP/LOW sequence, compared with code that has already been successfully executed @ 31KHz.
It's complicated because the PIC has three separate "31 kHz" oscillator signals (suffixed as LF, MF and HF) and I believe one of these is used for the NAP (and Sleep) timer.

If it's only k31 which is exhibiting the problem, my guess is that the NAP is in some way corrupting the 31 kHz instruction clock (or vice versa). Maybe Peeking the WDTCON and OSCCON SFRs will give a clue?

BTW, I calculate that at k31, a High .. : Low .. alone should generate a pulse of almost 50 ms.

Cheers, Alan.
 

PhilHornby

Senior Member
If it's only k31 which is exhibiting the problem, my guess is that the NAP is in some way corrupting the 31 kHz instruction clock (or vice versa). Maybe Peeking the WDTCON and OSCCON SFRs will give a clue?
Yes, it is - although I've obviously not tried all possible permutations.

Him as well said:
BTW, I calculate that at k31, a High .. : Low .. alone should generate a pulse of almost 50 ms.
I connected my scope up. FWIW, I measured (a single) 49mS pulse @ 31KHz, with nap 1 and a continuous train of 52mS pulses without it :rolleyes: (Entirely possible that's down to the way the program gets loaded into memory I suppose :confused: )

I simplified the program into a form that reproduces the issue :-

Code:
[COLOR=Navy]#picaxe [/COLOR][COLOR=Black]14m2[/COLOR]
[COLOR=Navy]#no_data
#no_end
#slot 0
#terminal 4800
      [/COLOR][COLOR=Blue]pause [/COLOR][COLOR=Navy]2000        
      [/COLOR][COLOR=Blue]sertxd (cr[/COLOR][COLOR=Black],[/COLOR][COLOR=Blue]lf[/COLOR][COLOR=Black],[/COLOR][COLOR=Red]"START PROGRAM"[/COLOR][COLOR=Blue])
      output b.1  
      
      setfreq k31
      do
            high b.1 [/COLOR][COLOR=Black]: [/COLOR][COLOR=Blue]nap [/COLOR][COLOR=Navy]1 [/COLOR][COLOR=Black]: [/COLOR][COLOR=Blue]low b.1    
      loop[/COLOR]
I tried nap 0, nap 1 and nap 2 @ k31,k125,k250,k500,m1,m2 & m4. (NOTE: I misread the manual - k125 isn't actually valid for the M2 series - and seems to be misinterpreted as something substantially slower than 31KHz).

Only the combination of k31 and nap 1 produce the unexpected RESET. (I note with interest, that 1/31000 = 32.3mS which is the claimed Time Delay for nap 1...)

I worked around my problem, by using pulsout b.1,22 - which gives 32mS @ 31KHz. The manual only gives 'pulsout' units for increasing clock speeds, but extrapolating the other way gives the right answer - more or less)
 

PhilHornby

Senior Member
Nap 1 + 31KHz don't mix...

This simpler code demonstrates that it is the interaction between 31KHz clock speed and the NAP 1 command.

Code:
[COLOR=Navy]#picaxe [/COLOR][COLOR=Black]14m2[/COLOR]
[COLOR=Navy]#no_data
#slot 0
#terminal 4800
      [/COLOR][COLOR=Blue]pause [/COLOR][COLOR=Navy]2000        
      [/COLOR][COLOR=Blue]sertxd (cr[/COLOR][COLOR=Black],[/COLOR][COLOR=Blue]lf[/COLOR][COLOR=Black],[/COLOR][COLOR=Red]"START PROGRAM"[/COLOR][COLOR=Blue])     
      setfreq k31
      
      do
             nap [/COLOR][COLOR=Navy]1
      [/COLOR][COLOR=Blue]loop[/COLOR]
 

bpowell

Senior Member
The PICAXE uses the watchdog timer for Napping....so maybe a Nap 1 (setting the WDT to 36ms) works for the nap, but then, when it comes out of the nap, the WDT is still at 36ms, and the PICAXE can't get through it's own code fast enough to "pat" the watchdog, allowing a reset to happen? Just an idea.
 

hippy

Technical Support
Staff member
I tried nap 0, nap 1 and nap 2 @ k31,k125,k250,k500,m1,m2 & m4. (NOTE: I misread the manual - k125 isn't actually valid for the M2 series - and seems to be misinterpreted as something substantially slower than 31KHz).
I cannot comment on the NAP issue you appear to be having, but K125 appearing not to be valid may be related to that.

K125 is otherwise valid for the M2 chips. These two programs at K31 and K125 both toggle an 18M2 LED every 4 seconds or so -

Code:
#Picaxe 18M2
SetFreq K31
Do
  Toggle C.2 : Pause 31
Loop
Code:
#Picaxe 18M2
SetFreq K125
Do
  Toggle C.2 : Pause 125
Loop
I will see if I can get set-up a 14M2 to check it is the same or you could run the test code on your 14M2 to confirm you see the same.

I believe the long PAUSE works and there is no watchdog reset because the PAUSE is resetting the watchdog repeatedly while looping within the firmware.
 

PhilHornby

Senior Member
Confirm both programs work as described on 14M2.

The PDF manual only lists k125 against the 28X1 and 40X1 - which I didn't notice when speed-reading it. These are the measurements I took (for High b.1 : nap x : low b.1 ). The k125 figures don't appear to fit the pattern, hence my assumption I was using an unsupported clock speed.

napk31k125k250k5001m2m4m
023mS43mS30mS23mS20mS19mS18mS
149mS *60mS47mS40mS37mS36mS35mS
284mS95mS82mS75mS64mS70mS69mS

(* = unexpected RESET)
 
Last edited:

hippy

Technical Support
Staff member
Thanks for the confirmation.

I can reproduce the 'NAP 1' reset at K31 on an 18M2. I have no idea why and it does seem to be an anomaly. Having a NAP for less than the WDT period should not cause a reset so it would appear to be some sort of unintended or unexpected interaction with that specific combination.

The pragmatic solution would likely be to use two 'NAP 0'.

As to the measurements you are getting I would expect the divergences at the K31 and K125 end comes down to non-linearity of the execution time of the code which sets up the NAP versus the actual time it does nap for, or the different oscillator sources used for the clock.
 
Last edited:
Top