32kHz simulation vs on chip

[CeesD]

A strange differency I found between simulation and reality.

I want to run the chip (PIC12F683) on its internal 31 kHz oscillator. In Flowcode therefore I set the clock speeld in ProjectOptions --> GeneralOptions to 31000 Hz.
And at the top of the program I added the C-code line: osccon = 0x00;
In ProjectOptions --> Configure I have the oscillator set at 'Internet RC Clockout'. And 'auto clear watchdog' is on.
In the Flowcode simulation it runs fine. A delay for 1 second is 1 second.

When I compile the program to hex format, and load with a PicKit-3 the hex file into the PIC12F683, However it seems to run there 8 times slower (estimated), although at the clockout pin (3) the frequency is approx. 8 kHz as expected (i.e. 31/4). The delay in the program seems to last 8 seconds or about.

However, when I set it all for 1 MHz (osccon = 0x40;) it runs on the chip correctly and according to the simulations.

What am I not doing correctly? Hopefully someone can give me a clue.

PS: Lateron I want to let the chip use an external oscillator (TCXO) signal of 32768 Hz.

[Benj]

Hello,

In this context the simulation will run a lot faster than the hardware as the simulation has a massively power CPU to do all the number crunching in between delays. In contrast the PIC is running very slowly so delays might be bang on but other processing is now taking much longer. You can confirm this with a simple 1 second flasher loop to see if it purely the delays that are longer than expected.

In contrast running at 1MHz is 32 times faster. e.g. 32 times more processing power.

[CeesD]

For testing I made a simple program, with a loop having (almost) only a delay of 600 seconds, during which interrupt may come in (on the edge of an input signal pin). There is no number crunching.
After completion of the delay another delay becomes in of also 600 seconds during which no interrupts are accepted (by the way, during the tests no interrupts were coming in at all).
Next the program while-loop continues with the first 600 seconds delay.

On the simulation debugger window of Flowcode I can follow the simulation delay in seconds. Indeed 600 second almost.
The chip clock speed is set at 1 MHz. In the top of the program in C is set: osccon = 0x40; (1 MHz). So that seems fine to mee.
I did not alter the watchdog time, which thus is the standard 18 msec (or about?). And the 'auto clear watchdog' is set.

When I compile it to hex file and load that simple program in a PIC12F683 chip, and let it run, then I see that it takes some 800-900 seconds instead of the 600.

What could be causing the difference?

[Benj]

Hello,

If you disable the watchdog timer in the configuration settings and untick the auto clear watchdog setting then does that improve things at all? The auto clear watchdog tries to break up long delays into shorter delays with calls in between the delays to the watchdog clear function. This additional code at very low processor speeds could potentially be having a big impact.

[CeesD]

Lowering the watchdog timer interval to 1 second (from the 18 msec) does hardly solve the question.

I use now the following trick: lowering the cpu clock setting the project building general options for building the hex file.
I my application the clock was set a 1 MHz with the osscon variable. When I set de cpu clock setting in the building also on 1MHz, the program (mostly delays during which external interrupts are handled) is 16% slower than real time.
When I lower the 1 MHz in the cpu clock setting with the same figure of 16% then the program is not slower than real time anymore.

[Benj]

Hello,

That's a nice workaround, thanks for sharing.

I wonder if we can do something to make this better. I will have a think on it.

[CeesD]

(Ben, thanks for your remarks).

In the small program for the PIC12F683 (1 MHz) I developed and discussed, there are long periodes of repetetive (in a while loop) delays of 1 minute (to get a delay of e.g. 6 hours).

I want to replace this delay by a simple while loop of about 50x a C-command 'sleep()', each lasting 1.2 second, thus also yielding approx. a 1 minute delay sleeping. However, the current consumption during the sleepy period does not drop at all.

I scanned alsmost all forum messages about this problem and did not find any clue. Probably I must set some register to 1 or 0 first.

I hope that someone can give me a direction to look into? I did cost me so far various night hours because of this so seemingly simple problem.

[Benj]

Hello,

The 12F683 is now quite an old device, if you opted for a newer device you would likely get a much bigger power saving.

The 12F683 datasheet states this:

standby current
1nA @ 2V

operating current
8.5uA @ 32KHz @ 2V
100uA @ 1MHz @ 2V

Note the 2V, I'm guessing the numbers will be significantly different at 5V.

Also which version of the device are you using, the industrial -I will behave differently to the -E extended. See section 15.2 of the datasheet for specifics.

Section 4.2.3 may also be helpful as it details ultra low power mode.

Section 9.8 also has relevent info.... The comparator and voltage reference, if enabled before entering Sleep mode, remain active during Sleep....

Don't use the PDF viewer built into your web browser to view the datasheet, PDF-XChange is a very nice PDF viewer and gives you all the bookmarks down the side in a format that is actually readable, it also works as opposed to Adobe reader which has a tendency to lock up or crash.

[CeesD]

I am aware of the age of the 12F683, but that's what is installed at the moment.

My concern is that if I add in the flowcode-6 program diagram inside a while loop the C-code sleep(); , I have to do some other settings first before actually the power consumption goes down during each sleep().

Perhaps the datasheet gives (hidden?) some clues about this issue. I keep studying, but perhaps someone has solved already this?

[CeesD]

To better explain my posts before, I herewith add a small diagram how the C-code sleep() is positioned inside a flowcode-6 while loop (using PIC12F683),

[CeesD]

I forgot to mention in my last post with the diagram that in the start of the program is added:

option_reg = option_reg | 0b00001111; //Configure watchdog to 1:128 Postscaler
wdtcon = 0b00000111; //Configure watchdog 1:256 (from Benj)
osccon = 0x45;

There is no further C-code in the program.

[CeesD]

I found my error: the peripherals were not switched of before the sleep() started.
Now I measure indeed some 30 microAmp current consumption during sleep(). And with the while loop I can make effectively very long sleep periodes.

Sorry for bothering you all with my stupidity.