Support Alternate Clock Frequency for the dsPIC.

[ve7fet]

The dsPIC is currently clocked with a 9.6MHz crystal. This is a problem when trying to use simulcast transmitters, as the crystals are not stable enough between devices to allow for simulcast to work.

One possible solution is to use an OCXO to replace the crystal with. That has been proven to work by others.

Changing the dsPIC divisors to accept 10MHz in directly is not an option, due to the precise timing requirements to generate interrupt service routines that need to happen every 62.5uSec, in order to be able to encode ulaw/ADPCM audio at 8000 samples/sec (125uSec).

Another potential solution involves changing the divisors to be able to use 9.8304MHz. WTF is that, you ask? That happens to also be known as the "CDMA 8x Chip" clock, which is an output that is readily available on the Nortel NTGS50AA GPSDO that is available on the surplus market (it also outputs the more standard 10MHz).

Indeed, initial investigation shows this may be possible.

Current settings (for 9.6MHz):

Fxtal is 9.6MHz

_FOSCSEL( FNOSC_PRIPLL & IESO_OFF )
Primary (XT, HS, EC) oscillator with PLL
Start-up device with user-selected oscillator source

_FOSC( FCKSM_CSDCMD & IOL1WAY_OFF & OSCIOFNC_OFF & POSCMD_XT )
Clock switching and clock monitor both disabled
Single configuration for remappable I/O OFF
OSC2 is clock O/P
XT oscillator (3-10MHz)

PLLFBD = 30; Multiplier (M) factor for the PLL offset by 2 so it is really 32
CLKDIV = 0x0000; N1=Fxtal/2, N2=Fvco/2
ACLKCON = 0x780;=0111 1000 0000, Primary OSC is Clock Source, Divide by 1, AOSC disabled, PLL output (Fvco) provides source for Aux Clock Divider.

So, with the above, Fxtal=9.6MHz, Fosc=9.6(32/(22))=9.68=76.8MHz. Instruction clock (Fcy) is Fosc/2=38.4MHz. Fvco is 9.6/2*32=153.6MHz

// dsPIC33F processor
#define GetSystemClock() (76800000ul) // 76.8MHz
#define GetInstructionClock() (GetSystemClock()/2) // 38.4MHz
#define GetPeripheralClock() GetInstructionClock() // 38.4MHz

Now, what about using 9.8304MHz?

Fin=9.8304MHz
Fosc=76.8MHz

N1 = 8

Fin/N1 = 9.8304/8 = 1.2288MHz = Fvcoin This is within 0.8-8MHz VCO Input Frequency

M = 125

Fvcoin * M = 1.2288*125 = 153.6MHz = Fvcoout This is within 100-200MHz VCO Output Frequency

N2 = 2 (N2 can only be 2, 4, or 8)

Fosc/N2 = 153.6/2 = 76.8MHz = Fosc BINGO! (matches what we already have)

CLKDIV setting:
Bit 7-6
N2 = 00 // 2
Bit 5
0
Bits 4-0
N1 = 00110 // offset by 2, so 6 + 2 = 8

So, that should make it 0000 0110 = 0x06

PLLFBD = 123 // 123 + 2 = M
CLKDIV = 0x0006
ACLKCON = 0x780

And this should work fine for the DAC too, since Fvco is 153.6MHz, see lower down for the DAC clocking calculations.

We probably need to change to EC-PLL clocking from XT-PLL? I suspect that should be:
_FOSC( FCKSM_CSDCMD & IOL1WAY_OFF & OSCIOFNC_OFF & POSCMD_XT ) in Hardwareprofile.h and the POSCMD_XT will need to change to POSCMD_EC

CLKDIV register is 0x0744, and PLLFBD register is 0x0746.

That SHOULD let the firmware run with 9.8304MHz, and keep the same timing restrictions, but there is another problem... the bootloader.

The bootloader is wanting to run at 9.6MHz, so it won't even boot if we feed it 9.8304MHz.

I suspect we will need to hack the bootloader .cof to make those changes, since no one seems to have the source code for that:

I think we’ll need to change address 00F70:
From: mov.w #0x1e,0x0000
To: mov.w #0x7b,0x0000

That should change the PLLFBD

For the CLKDIV, change address 00F74:
From: clr.w 0x0000
To: mov.w #0x6,0x0000 → change the opcode to 200060

I THINK that will put 0x6 in to the buffer to be written in to register 0x0746 on the following instruction.

Probably need to change the configuration bits manually to FF9C from FF9D, and see if that goes. Actually, it appears that if you change the bits and save the workspace in MPLAB, that the changes might stick?

These are just some musings... maybe a better approach would be able to use a programmable clock generator chip to swallow 10MHz and spit out 9.6MHz? The problem there is the DIP switch programmable ones (such as the ICS525) are becoming obsolete, so more complexity is required to use one of the newer options (that needs to be programmed on the fly).

If someone else happens to have a GPSDO that has a 9.8304MHz output, and wants to try the above code changes and see if it boots, have at it! This will be explored for feasibility in the VOTER3 hardware that is in development.