No consigo que funcione el cristal !! || SOLUCIONADO ||

[MGLSOFT]

Hace un largo tiempo que no me pasaba esto...

Hice un programa (varios en realidad) usando el oscilador interno de un PIC18F26K80, que a decir verdad es excelente...
Este PIC permite usar el oscilador interno a 16 mhz y con el PLL activado, hacer que el micro trabaje a 64 mhz !!

Fiel a mi costumbre de llevar al maximo de exigencias cada PIC que toco,   hice varios programas que usaron este tipo de oscilador.

Ahora quiero poner un cristal externo, cumpliendo las mismas premisas de velocidad, es decir un cristal de 16 mhz y habilitar el PLL para que funcione igual que en los programas anteriores.

Vaya mi sorpresa al saber que el cristal NO Arranca a oscilar !!

Probe al menos 10 configuraciones diferentes, sin obtener resultados !!!  

Tengo experiencia en usar el PLL y las maximas velocidades en la linea PIC18F, por lo tanto no esperaba tal rotundo fracaso en este caso.

Hace mas de una semana que estoy lidiando con este problema...

Como lo arme en protoboard, saque el cristal y lo probe en otro circuito (tambien en protoboard) que tengo armado y el osciloscopio lee bien esa frecuencia en 15,8 mhz.
Pero si lo coloco en el circuito en cuestion, deja de oscilar, incluso hice la inversa, traer el cristal de 10 mhz a esta placa y tampoco arranca a oscilar.

Es posible que el circuito interno del PIC no permita arrancar el oscilador si esta mal configurado ??

A alguien le paso algo asi??
Tienen experiencia que puedan compartir conmigo, en esta linea de PICs ??

[Suky]

No tendrás algún drama en la placa, algún capacitor a gnd o alguna unión que no logres ver? Por lo que se ve, la retroalimentación esta al principio, sin opciones de configuración (control solo por Sleep) y despues un buffer, por lo tanto una mala configuración no debería afectar a la etapa de entrada  Además en el errata no veo nada respecto al oscilador.

No se si se puede en estos micros, pero no probaste de arrancar sin PLL y encenderlo al iniciar el microcontrolador?

Saludos!

[MGLSOFT]

Por lo que veo ya estuviste viendo la hoja de datos, asi que habras visto que tiene tres fuentes de oscilacion diferentes, con una importante cantidad de opciones de combinacion.

Estuve leyendo en foros donde algunos arrancan el PIC con una fuente y despues cambian de oscilador estando en marcha.

Pero es importante el dato que me das, o sea el cristal deberia oscilar aunque la opcion de configuracion este mal elegida, es asi o interpreto mal??

Voy a cambiar de Proto o veo de armarlo en un pcb a ver que pasa...

[BrunoF]

Hace un tiempo renegue mucho con unos 18FxxJxx por un tema similar, también creí que no oscilaban.

En dichos micros no alcanza con activar la PLL en los FUSES, sino que también hay que activarla en el código.
Así que si estás en CCS podrías declarar:

#bit PLLEN = 0xF9B.6

y en el main hacer:
PLLEN = 1;

En mi caso eso bastó para solucionar el problema, aunque en tu datasheet figura que se activa el PLL seteando el FUSE correspondiente o el bit OSCTUNE,PLLEN y la verdad que ese micro tiene más opciones de config de oscilador que los que te menciono.

Saludos.

[Suky]

Pero es importante el dato que me das, o sea el cristal deberia oscilar aunque la opcion de configuracion este mal elegida, es asi o interpreto mal??

Si, lo determino de lo que se ve en el datasheet.

Es cierto lo que dice Bruno, para un PIC18F67J50 hago:

Código: C

1. unsigned int pll_startup_counter = 1000;
2.         OSCTUNEbits.PLLEN = 1;  //Enable the PLL
3.         while(pll_startup_counter--);

Pero no encontré referencia de esto para un 18F26K80, puede que sea igual. Pero como dices que con el interno funciona  

[Nocturno]

Prueba con esto en tu main():

setup_oscillator(OSC_NORMAL|OSC_PLL_ON);

[MGLSOFT]

Manolo:
Lamento decirte que ya probe esa opcion...

Suky:
Entiendo que tu rutina espera 1000 tikcs de programa para que se active el PLLEN ??

Bruno:
Yo compilo y despues veo el assembler generado y PLLEN esta habilitado, por eso no entiendo bien que pasa.


Voy a armar todo el circuito en un pcb en vez de protoboard a ver si eso me esta molestando o no...

[Suky]

Eso, vine así en los ejemplos de Microchip, colocan la variable a 600, 1000 o 2000 generalmente... Un tiempo como para que enganche y se estabilice.

[MGLSOFT]

Ajah!!
Y esos ticks deberian ser multiplos del tiempo de oscilacion primario, es decir antes de multiplicarlo en el PLL.
Por ejemplo, si son 10 Mhz y con PLL activado hacen 40 Mhz, el tiempo de cada ticks corresponde a los 10 Mhz...

[BrunoF]

El datasheet dice que se el PLL puede demorar hasta 1000 ciclos en estabilizarse luego de activado y recomienda que hagas perder el tiempo al uC durante dicho período mínimamente, para garantizar la estabilidad. Con cumplir los ciclos mínimos, es suficiente. Podés excederte en todo los ciclos que desees.

[manutek]

Por ahí digo una boludes pero podría ser el tipo de corte de cristal lo q esta jodiendo ? digo por xt o at  o hs ....

[MGLSOFT]

No hay caso!!
 

Sigue haciendo lo que se le viene en gana!!   
Y lo arme en PCB y sigue sin darme bolilla al intento de hacerlo funcionar...

Vere de escribir los registros de prepo...

[jeremylf]

A mi me paso hace mucho tiempo con el 18F2550 que cambiando los fuses HS, HSPLL, etc. Habia un fusible (no recuerdo cual) que no hacia cambio en la configuracion real (ocea en el hex). Esto lo comprobe viendo en el MPLAB porque yo siempre creo, edito y compilo en la IDE de CCS pero para grabar el pic, importo el hex al MPLAB y ahi veo el config bits. Bueno, ahi me di cuenta que no combiaba el fuse en cuestion. El problema, si mal no recuerdo, era del CCS, actualizando la version se arreglo eso.

Aun que dudo que te pase esto, porque seria bien tonto, mas que nada lo pongo para dejar una experiencia que pueda servir a otros menos experimentados =)

Mas bien, has probado con otros de esos pics?

[MGLSOFT]

A mi me paso hace mucho tiempo con el 18F2550 que cambiando los fuses HS, HSPLL, etc. Habia un fusible (no recuerdo cual) que no hacia cambio en la configuracion real (ocea en el hex). Esto lo comprobe viendo en el MPLAB porque yo siempre creo, edito y compilo en la IDE de CCS pero para grabar el pic, importo el hex al MPLAB y ahi veo el config bits. Bueno, ahi me di cuenta que no combiaba el fuse en cuestion. El problema, si mal no recuerdo, era del CCS, actualizando la version se arreglo eso.

Aun que dudo que te pase esto, porque seria bien tonto, mas que nada lo pongo para dejar una experiencia que pueda servir a otros menos experimentados =)

Mas bien, has probado con otros de esos pics?

No es tonto, estuve viendo desde MPLAb y veo que el archivo generado en assembler desde CCS coincide con el que veo en MPLAB, en ambos NO se cambia de tipo de oscilador aunque le ponga lo que le ponga.

Eso no lo entiendo.
Mañana (porque hoy ya es tarde) voy a ponerlos a mano esos bits, a ver que pasa, porque sino voy a volverme loco...

[MerLiNz]

Yo tengo esto de un 18f46k80

fuses:
#pragma config RETEN = OFF, INTOSCSEL = HIGH, SOSCSEL = DIG, XINST = OFF
#pragma config FOSC = INTIO1, PLLCFG = ON, FCMEN = OFF, IESO = OFF, PWRTEN = OFF
#pragma config BOREN = OFF, WDTEN = OFF, CANMX = PORTC, MCLRE = OFF, STVREN = OFF
#pragma config BORPWR = LOW

#pragma config CP0 = OFF, CP1 = OFF, CP2 = OFF, CP3 = OFF, CPB = OFF, CPD = OFF
#pragma config WRT0 = OFF, WRT1 = OFF, WRT2 = OFF, WRT3 = OFF, WRTC = OFF, WRTB = OFF
#pragma config WRTD = OFF, EBTR0 = OFF, EBTR1 = OFF, EBTR2 = OFF, EBTR3 = OFF
#pragma config EBTRB = OFF

y esto en el inicio del main:
OSCCONbits.IRCF=7;
OSCTUNEbits.PLLEN=1;

Lo unico que creo es que utilizaba el cristal interno a 16mhz y luego el pll hasta 64mhz, hace tiempo que lo hice asi que no me acuerdo bien, sin embargo funcionaba a la perfeccion.