problem with internal osc on 18F2550

[TucoRamirez]

hello

I m playing with mikroc and proteus and i tried to use the internal osc.. at 8MHz

So i used the following config in the wizard

pll prescaler selection  : divide by 2 (8MHz input)
System clock postscaller:  primary osc src /1   96MHz pll src /2
USb clock source comes from 96MHz pll divided by 2

oscillator selection: 

here i tested both  INTIO (with osccon= $72  and INTHS and even HS alone

and no matter what, when i put a delay_ms(1000), it gives a 5seconds delay!!


can anyone say me what i did wrong? 
 
thanks in advance

[vovchik02]

Internal OSC default setting 1 MHz (DS39632D-page 32) .
For select 8MHz F_OSC set OSCCON register IRCF(0..2) bit by sofware.
PLL prescaler don't work with INTOSC (DS39632D-page 24).

[TucoRamirez]

yes i did that you say:

     OSCCON = 0x73; // configures oscillator divider for 8MHz int. oscillator
     CMCON  = 0x07; // Disable comparators
     ADCON1 = 0x0F; // Disable Analog functions

the osc in the wizard remains 8M but delays are 5x longer ....

i tested adding an interrupt from timer0 and it gives me the correct simulated expected tick and adding usart it sends the correct baudrate but delay_ms is the only thing that kicks me...

I'm thinking about using a macro like Vdelay_ms ... but for now i can only test in isis because i'm not at home ^^

[TucoRamirez]

I found the error by myself...

The problem never came from oscillator config at all !!!

in fact i dont know if is a mikroe bug or whatelse but...

I remembered i copy paste the timer0 part from examples...  look:  the _bit is everywhere !!!

Code:

// Enable global and peripheral interrupts
     INTCON = 0xC0;       // Set GIE, PEIE
// Setup and enable TIMER0
     TMR0ON_bit = 0;      // turn off the timer during setup
     TMR0IE_bit = 1;      // Enable TMRO interrupt
     T08BIT_bit = 1;      // Enable 8 bit control (as opposed to 16-bit)
     T0CS_bit = 0;        // use internal clock to trigger timer to count
    PSA_bit = 0;         // Use the prescaler to slow the timer down

     // prescaler
     // 111 = 1:256 Prescale value
     // 110 = 1:128 Prescale value
     // 101 = 1:64 Prescale value
     // 100 = 1:32 Prescale value
     // 011 = 1:16 Prescale value
     // 010 = 1:8 Prescale value
     // 001 = 1:4 Prescale value
     // 000 = 1:2 Prescale value
     T0PS0_bit = 0;
     T0PS1_bit = 0;
     T0PS2_bit = 0;

     TMR0L = TIMER_START_VALUE;
     TMR0H = 0;

// TIMER2 config to create pwm.
// PWM frequency = 1/((PR2 + 1) * 4 * TOSC * TMR2prescaler)
   T2CON=0b00000011;  //prescaler 1:16 and turn on TMR2
   PR2=249;// period definition

   CCPR1L = 0; // max DC:  63 for =< 500us   32 for 250u  48 for 375
   CCP1CON.b4 = 0; // Place bit-0 of the duty in the LSB register(bit-4)
   CCP1CON.b5 = 0; // Place bit-1 of the duty in the LSB register(bit-5)
   CCP1CON.b2 = 1; // Turn on PWM Module one,
   CCP1CON.b3 = 1; // by setting bits 2 and 3 of CCP1CON

//   Delay_ms(100/5);  // stupid delay just to wire the Vcc from the servos

 INTCON.GIE = 1;
 INTCON.PEIE = 1;
 PIE1.RCIE = 1; //enable interrupt.
 UART1_Init(115200);
      

     TMR0ON_bit= 1;      // start the timer
     T2CON.TMR2ON=1;
 // i debugged with this itchy bitchy blink !!    
     LATC.F0=1;
     Delay_ms(500);
     LATC.F0=0;
 //VDelay_us(1000000);
 Delay_ms(1000) ;
  while(1){...
}

And is the TMR0ON_bit who piss all my code...  delay of 500ms become a 2.5sec one !!

So now the problem is ton configure correctly the timer0 to not disturb my system...

[TucoRamirez]

i think it's something from my isr that take enough time to perturb/delay the current delay_ms ...

In the meantime i'll keep track of delays by using another timer ...

[xpress_embedo]

Check your Crystal Frequency.
This happens when you have set Crystal Frequency to some other value might be 48Mhz
Change to the Internal Oscillator Frequency.


And i think you can't power the usb module and pll with internal clock in pic18f2550 micro-controller

[gan_canny]

First the internal oscillator works  on the 18F2550. Now any delay_xx statement  that uses in line code ( like a loop with an assembler goto ) will be affected by any isr that triggers during the delay. It takes so many cpu instructions to get both into and out of an isr. Further never place asynchronous calls into an isr ( ex printf) since they can never complete faster than the number of characters to be sent at the chosen baud rate. You can't use the internal oscillator for USB it is never accurate enough for usb timing. Next never use proteus (ISIS) in time assessments. Proteus is just prototyping it is not a one to one mathematical mapping to the actual hardware. If proteus works there is a reasonable probability a real circuit might work. If proteus doesn't work there is still  some probability that a real circuit would work. Think of proteus as a sketching tool a quick drawing tool but never a final result.

[TucoRamirez]

First the internal oscillator works  on the 18F2550. Now any delay_xx statement  that uses in line code ( like a loop with an assembler goto ) will be affected by any isr that triggers during the delay. It takes so many cpu instructions to get both into and out of an isr. Further never place asynchronous calls into an isr ( ex printf) since they can never complete faster than the number of characters to be sent at the chosen baud rate. You can't use the internal oscillator for USB it is never accurate enough for usb timing. Next never use proteus (ISIS) in time assessments. Proteus is just prototyping it is not a one to one mathematical mapping to the actual hardware. If proteus works there is a reasonable probability a real circuit might work. If proteus doesn't work there is still  some probability that a real circuit would work. Think of proteus as a sketching tool a quick drawing tool but never a final result.

I totally agree with you but in my particular case i'm in holidays trip so i forgot my prototype board at home ^^  so isis is my only link between mcu behavior and my free time ...

I'll use the constant time of my isr cycles to count with a reseteable variable in order to generate the desired delays ...   in the intosc side things are clear know ...    and i'll be more careful with isr and timinigs...