18F24J11 clock switch not working

[colin382]

I have a logger application that must run for a long time on a small battery. The data acquired by the logger is written to an SD card once per day.
The logger runs on the internal clock at 31000Hz until the SD card is to be written. This action requires a serial port working at 2400 bps or higher, for which a much faster chip clock is needed. I use the 8MHz internal clock.
I have tried several ways of switching clock rates "on the fly" but none have worked. The attached code is my best effort so far, but although the code runs correctly, the current taken suggests that the chip is always using the high clock rate.

So, dear forum members, is there a way of switching clocks as needed?

[temtronic]

re: I have a logger application that must run for a long time on a small battery. The data acquired by the logger is written to an SD card once per day.

Have you 'done the math' to see how big the 'small' battery needs to be to run for a 'long' time ? Depending on SD card mfr/size it might take a lot of power to store the data. Hmm..how much data ? What 'enviroment' (temperatures) is it located in ? Anything other then 'warm', and battery capacity can be 1/2 or even a 1/3rd of 'rated' aH.
At least look at Microchip's AN606 as a start to begin the 'math'.
When you get the 'number'... double it. 'Little' details like pullups, LEDs,enabled peripherals can steal a few electrons...over time,,,oopsy, battery died....

[Ttelmah]

It will do.

You have the FSCM fuse set. If the clock speed drops below about 100KHz,
it'll switch to the default clock. You need this off.

You need to be setting the oscillator to 8MHz, before you use the UART,
wait a short while for it to stabilise, do your UART operation, then switch back
to 31K.

Also your 'setup_uart' line is doing nothing. A code line placed outside of
the code, has no effect at all.

[colin382]

@temtronic
Thanks for your interest and observations. The code quoted is of course just the minimum to explain the problem. The project is to run from 3 * AA dry cells and consists of the micro, a SparkFun OpenLog that is only powered when needed (once per day)and one LED using 1mA that is pulsed for 30ms for each logged event- this happens about 2000 times a day on average. The hardware is in a heated residential property. Running from 31000Hz the quiescent current is about 100uA. The 1.4mA quoted originally includes the current taken by a Pickit4.

@Ttelmah
Thanks for the tip regarding the fail-safe fuse- I rather lazily assumed the CCS Wizard would read my mind and do what was necessary. As an aside, why would it step in when the code is running at a legitimate speed?

The code below implements your suggestions but sad to say the current is still high. I have attached the .lst file in case it helps.

[PCM programmer]

Look at the ASM code for your #use delay() statements inside main().
It's not switching the oscillator frequency. That code is the delay code
for delay_ms().

You need to use the CCS function designed for changing osc freq:

setup_oscillator(OSC_31KHZ);

and

setup_oscillator(OSC_8MHZ);

After each line above, you can put the appropriate #use delay()
statement to tell the compiler the current osc frequency.

You should be aware that the #use delay() statement only affects
code that occurs physically after it in the source file. The manual says:

[colin382]

@PCM,

This is one of the many methods I have tried and failed with. I have now re-visited this solution after Ttelmah suggested turning off the FCMEN fuse, but still no luck.

After RTFM I also modified your suggestion to include OSC_INTRC, e.g. setup_oscillator(OSC_8MHZ | OSC_INTRC); etc. but with no benefit.

To be clear, I added the setup statement immediately before each pre-existing #use delay statement, with the appropriate argements.
In desperation I also tried only adding the setup statements in main(), and then only in while() but as one might expect, there was no improvement.

It's near midnight here in UK, so closing now and hoping for an overnight epiphany...

[Ttelmah]

The wizard is totally thick. It often generates incorrect values. This is why
all the 'old hands' here, 'scream' when people use the wizard....

For your clock switch, you need:

[colin382]

Thanks Ttelmah, that works exactly as hoped. I did need to add a 2ms delay after the fprintf() to allow the last two bytes to be sent before switching back to the slow clock. My error was putting the initial setup_oscillator() and delay() before main().

There is one remaining issue: the current in the slow clock period is 1.7mA. If I remove all references to the RS232 and the associated setup_oscillator() and delay() so that the chip is always running at 31KHz the current comes down to 0.1mA. Next I left all the clock change stuff in place, but deleted the UART setup and the fprintf() that uses it. The current is then also 0.1mA.

It seems that invoking a UART enables a hardware module that runs continuously. Since there doesn't seem to be a #unuse RS232() built-in function, I will resurrect a bitbang UART TXD function I used some time ago. I don't need the RXD side.

Thamks again for your expertise and patience.

[Ttelmah]

If you look at the setup_UART function, you can use your #use RS232 like
this:

#use RS232(UART1, baud = 9600, ERRORS, NOINIT, stream = Logger)

Then when you want to use the UART (immediately after the clock switch),
use:

setup_UART(TRUE); //will enable the UART

Then once you have finished your printf, use:

[colin382]

Well I would never have thought of that in a million years.
It works and the current in slow clock is now 0.1mA. Brilliant.
Serial data is correct BUT the baud rate is 125K and doesnt change when I change the #use RS232() baud argument !
I think this is because the BRG register is left at default (=0), so the baud rate becomes Fosc/64. The list file has no reference to SPBRG1 (at register FB0h)
I could just write the appropriate value into SPBRG1, but is there a better way?

[Ttelmah]

You can include the clock rate in the setup_UART. Normally it shouldn't be
needed, but I'd suspect it is getting confused by the clock changes.

setup_UART(9600, Logger, 8000000);

Should put the right BRG value in.

[colin382]

That fixed it. Once again, thanks for your help.

Until the next time...

[Ttelmah]

Nice to see progress forwards.