Is this a known Bug in 'Time' or is this just me?

[HertzHog]

OK I am making a rate meter. 18M2+ chip
When I run it in what I call 'One Shot' mode it malfunctions. I think my logic is OK.
What I am trying to achieve, in 'One Shot mode' is measuring a rate for a period of time, then stopping it after a defined period of time, (time needs to stay fixed) and displaying the rate till it is reset. Rate is Events / Time.
So, I stop the time with Disable time and then display till reset. My logic is OK. BUT the time is still advancing! Therefore my rate degrades

So, I have removed everything to simulate the bug and have the following code... It 'malfunctions' too! Can you explain this?
I show the minimalistic code which still demonstrates the problem...

#no_data

Disabletime  ; This should stop the word variable time from incrementing

Main:
Nap 1   ; Commenting out this Nap makes it work OK!
Pause 2000  ; It seems to be the Nap AND the Pause which makes this bug appear, but why?
SerTxd("The value of Time is = ",#Time," seconds.",13,10)   ; Time slowly increments while this runs on my chip but why?
Goto Main

Is this a 'Bug' has it been fixed? Is it feature? What is happening? Have others found this?
Nap seems to reactivate the time variable incrementing during the subsequent pause command.
HertzHog

 

[Technical]

We'll look into it, putting the processor into sleep mode will affect the timers, but should not turn 'time' incrementing back on as you are suggesting.
Disabletime does not actually disable the timers altogether, it simply sets a flag to stop the 'time' variable incrementing on the ticks when they still occur.

Did you try simply adding a disabletime after the nap?

 

[HertzHog]

I have not explored all possible work arounds yet. I am sure there is one. But, I just found time was nudging up slowly causing my rate to change after I thought it should be fixed.
I then tried to see if it was the chip or my logic that was at fault. I replicated the issue with the pointless and minimalistic program I presented above and found I could.
The nap and pause in the loop seemed to be required for the issue to resurface.
In my program, the rate display needs to pause as the digits are flashed out on a 7 segment display (with the potential to have an interrupt triggered and processed in data collection phase).
As no data is collected after the sampling time period is over, a slow iteration was required and naps seemed appropriate between sessions of displaying the result while waiting to move on after a manual reset.
I think time is incremented by the loop commands rather than each second as it changes too slowly.
I have not tried other chips etc. just my current 18m2+ at this stage.
HertzHog

 

[HertzHog]

It is a Nap 'feature'!

I have tried this on another 18M2 board. The bug persists. It seems that the effect of a Nap is to restart the time timer even if it was disabled before the Nap with a disabletime command!
Can anyone else confirm my findings?
Re-examining my original fuller code, there seems to be a bit more to this as time advances too slowly (vide infra)? I think there is only one place that time is disabled and that is outside the loop which takes more than 2 seconds to loop but only 2 seconds are added per loop. HertzHog.

P.S. I am now much more sure that it is the Nap command, as it exits, that restarts the time counter even if previously disabled by a DisableTime command. However, Time does NOT get incremented during the Nap which is why only 2 seconds was added per loop in my full program (those 2 seconds were commands and pauses) even when the loop was slower to complete, as it was delayed on purpose by the other Nap commands which do not get measured by time, as the chip is resting.
Hence think of a Nap as a concatenated...
Nap X : EnableTime
Surprisingly that feature, at least of an 18M2, is not documented in the manual. So, beware! HertzHog

 

[HertzHog]

It is a Nap 'feature'!

We'll look into it, putting the processor into sleep mode will affect the timers, but should not turn 'time' incrementing back on as you are suggesting.

Technical. IMHO I agree it should not, BUT you may be wrong in terms of what it does do on an 18M2 at least?
Is it the same with all chips in the series? That can be tested.
HertzHog

 

[Technical]

We have briefly tested this and there does seem to be a issue, we will have to investigate whether it is expected behaviour after a low-power sleep(nap) or an issue in the firmware or the compiler. Another disabletime after the nap is a simple workaround for now, as it should reset the 'ignore' time flag.