• AVR Freaks

Hot!dsPIC33EP Timer differences

Author
Blue_Key
Senior Member
  • Total Posts : 132
  • Reward points : 0
  • Joined: 2011/12/20 04:48:22
  • Location: 0
  • Status: offline
2019/08/21 06:01:52 (permalink)
0

dsPIC33EP Timer differences

Hi There,
 
I'm facing somewhat a strange issue.
 
I have two parallel PIC on a board, each has an independent system clock source ASDMB-4.000MHZ-LC-T which is rated +/-50ppm, temperature on the board is homogenous.
 
The two PIC has the exact same hardware connected to it and runs both on the same code. 
 
I trigger them for measurement (External ADC) at the same time through an I2C general instruction. The measurement is controlled by Timer1 configured for internal instruction clock.
 
The thing is, over a period of 200ms I get a drift of 1ms (approx 0.5%), very repeatable. The measurement at the start seems to be well synchronized so it doesn't seem to be related to trigger related delay.
 
Given the input clock source is given at 50ppm, I believe my clock source is stable. To add, T2 blink LED every second and it does not seem to drift.
 
I went through the code to check if anything would block the timer interrupt, but nothing there and the code is quite minimal. Flag is cleared as first interrupt instruction.
 
 
 
 

int FICD __attribute__((space(prog), address(0x157F0))) = 0xFFCF;
int FPOR __attribute__((space(prog), address(0x157F2))) = 0xFFDF;
int FWDT __attribute__((space(prog), address(0x157F4))) = 0xFF7F;
int FOSC __attribute__((space(prog), address(0x157F6))) = 0xFF58;
int FOSCSEL __attribute__((space(prog), address(0x157F8))) = 0xFFFB;
int FGS __attribute__((space(prog), address(0x157FA))) = 0xFFFF;

void timerSamplingInit()
{
T1CONbits.TON = 0; // Disable Timer
T1CONbits.TCKPS = 0b00;
T1CONbits.TCS = 0; // Select internal instruction cycle clock
T1CONbits.TGATE = 0; // Disable Gated Timer mode

TMR1 = 0; // Clear timer register
PR1 = 400; // Ltime for 10us

_T1IP = 4; // Set Timer1 Interrupt Priority Level
_T1IF = 0; // Clear Timer1 Interrupt Flag
_T1IE = 1; // Enable Timer1 interrupt

T1CONbits.TON = 0;
}

void initOsc()
{
ClrWdt();
// 4 Mhz Clock
CLKDIVbits.PLLPRE = 1;
PLLFBD = 178;
CLKDIVbits.PLLPOST = 0;

// Initiate Clock Switch to Primary Oscillator with PLL (NOSC = 0b011)
__builtin_write_OSCCONH(0x03);
__builtin_write_OSCCONL(OSCCON | 0x01);

// Wait for Clock switch to occur
while (OSCCONbits.COSC != 0b011);
// Wait for PLL to lock
while (OSCCONbits.LOCK != 1);
ClrWdt();
}

 
post edited by Blue_Key - 2019/08/21 06:02:54
#1

3 Replies Related Threads

    du00000001
    Just Some Member
    • Total Posts : 2997
    • Reward points : 0
    • Joined: 2016/05/03 13:52:42
    • Location: Germany
    • Status: offline
    Re: dsPIC33EP Timer differences 2019/08/21 07:20:04 (permalink)
    0
    Seems these guys "forgot" to specify the initial accuracy  sad: sad
    The 50 ppm is just the frequency variation over temperature - one of quite a number of factors influencing the frequency, like
    • (exact) value of supply voltage
    • load capacitance (including stray capacitances due to PCB layout)
    • effects of aging
    • chip temperature (NO - the temperature on a PCB can only be considered homogenous when it's off and the ambient temperature hasn't changed - both for several hours.)
    • ...
    If you intend to rely on the controllers running synchronously: forget that ! Or supply both with the same clock.
     
     

    PEBKAC / EBKAC / POBCAK / PICNIC (eventually see en.wikipedia.org)
    #2
    Blue_Key
    Senior Member
    • Total Posts : 132
    • Reward points : 0
    • Joined: 2011/12/20 04:48:22
    • Location: 0
    • Status: offline
    Re: dsPIC33EP Timer differences 2019/08/22 04:43:36 (permalink)
    0
    Thanks for your reply.
     
    Those are clocks, not oscillators. I do agree, that inherently there would be differences between the clock, I don't need a dead-precise clock, but here we are talking 0.1% which seems huge for a clock.
     
    This clock datasheet puts aging at 5ppm.
    The clock stability is given at 50ppm. This seems not temperature related as it would be ppm/°C. This is specified as "Overall Stability" so it should account for temperature and other things altogether, which is 0.005%, here I'm out of sync by 100 times this value.
     
    I quite doubt the clock is the source of the issue. I tried changing the clock chip and the delay remains exactly the same.
     
     
     
    #3
    du00000001
    Just Some Member
    • Total Posts : 2997
    • Reward points : 0
    • Joined: 2016/05/03 13:52:42
    • Location: Germany
    • Status: offline
    Re: dsPIC33EP Timer differences 2019/08/22 07:04:35 (permalink)
    0
    The ASDMB-4.000MHZ-LC-T is officially called a (MEMS) clock oscillator. (A clock is e.g. what's exiting an oscillator  grin)
    Considering typical manufacturing tolerances of 25 % in semiconductor production, 0.1 % isn't exactly much.
    And your 0.1 % are to be divided between 2 devices - improving the error for the individual device to 0.05 %.
     
    The datasheet is "nice" but doesn't give enough to really assess the issue. Might be some competitor's datasheet would be more enlightening - I just do not have the time to dig into that...
     
    Blue_Key
    I quite doubt the clock is the source of the issue. ...

    Might be. having identical code on both devices doesn't give away how exactly they synchronize. . . .

    PEBKAC / EBKAC / POBCAK / PICNIC (eventually see en.wikipedia.org)
    #4
    Jump to:
    © 2019 APG vNext Commercial Version 4.5