Configuración de reloj y overclocking en Kinetis MK66

[planeta9999]

 

Tengo un pequeño lío con la configuración de reloj de un Kinetis MK66, a raiz de estar usando el bootloader uTasker. Después de muchas pruebas, conseguí que me funcione el bootloader en un MK66, porque con la configuración para Teensy 3.6 no funcionaba bien.

Ahora intento hacerlo funcionar en un MK64 y vuelvo a tener problemas de configuración del bootoader, en teoría debería de funcionar si selecciono la configuración para un Teensy 3.5, pero no es así, hace cosas muy raras y no carga el firmware, o lo hace a veces y bloqueando la ejecución.

Bueno, el problema del uTasker es otro tema. La cuestión es que mirando la configuración del reloj, me encuentro con cosas que no me cuadran.

Teensy 3.6 instala un cuarzo de 16Mhz, y en el listado de configuración del reloj en Arduino (Teensyduino), me deja seleccionar entre otras, 180Mhz. No entiendo como sacan los 180Mhz, a partir de 16Mhz, configurando el divisor y el multiplicador del PLL, no me salen las cuentas. El problema, es el de siempre con un entorno como el de Arduino, hay cosas que están por ahí ocultas y no las puedes ver, a menos que empieces a indagar a ver donde se esconden.

En los fuentes de uTasker, para que me funcionara el bootloader con un cuarzo de 16Mhz (originalmente estaba a 12Mhz para una placa FRDM-K66), configuré el reloj con estos parámetros. Funciona, si, pero ahora me he dado cuenta de que probablemente lo he overclockeado a 240Mhz (16/2= 8Mhz*30 = 240Mhz). Segun la lista de clocks disponibles para Teensy 3.6, este puede funcionar overclockeado a 192Mhz, 216Mhz y 240Mhz, seguramente eso explica que me funcione, pero no entiendo como configuran el reloj para 180Mhz con cuarzo de 16Mhz.

#define CRYSTAL_FREQUENCY    16000000  // 16 MHz crystal
#define CLOCK_DIV            2
#define CLOCK_MUL        30     // the PLL multiplication (x16 to x47 possible) [PLL output range 90..180MHz]
#define OSC_LOW_GAIN_MODE
#define _EXTERNAL_CLOCK      CRYSTAL_FREQUENCY
#define BUS_CLOCK_DIVIDE     2  // 120/2 to give 60MHz (max. 60MHz)
#define FLEX_CLOCK_DIVIDE    2  // 120/2 to give 60MHz (max. 60MHz)
#define FLASH_CLOCK_DIVIDE   5
#define SYSTEM_CLOCK_DIVIDE  1  // 1 to 16 - usually 1
#define USB_CRYSTAL_LESS

[tsk]

Según por lo que leí en otros lados el cálculo que estás haciendo sólo llega hasta el VCO que puede tener una frecuencia de hasta 360Mhz y la salida del reloj para el sistema es la mitad del valor de VCO

Si eso es verdad, entonces con un cristal de 16Mhz y con los siguientes parámetros tendrías 180Mhz

CLOCK_DIV 2
CLOCK_MUL 45

16Mhz/2 = 8Mhz
VCO = 8Mhz*45 = 360Mhz

VCO/2 = 180Mhz

En la hoja de datos puedes comprobar que el VCO puede ir de 180 a 360Mhz. Simplemente es comprobar en un diagrama que esto f_sys = f_vco/2 es verdad

[planeta9999]

Gracias tsk.
¿ Entonces ahora, tal como lo tengo configurado con el PLL para 240Mhz, realmente estaría rodando a 120Mhz ?

Ya me extrañaba este comentario en los fuentes, a ver si es eso:

#define CLOCK_MUL        30     // the PLL multiplication factor to achieve operating frequency of 120MHz (x16 to x47 possible) [PLL output range 90..180MHz - VCO is PLL * 2]

[tsk]

Aparentemente si

[planeta9999]

 

Justo ahora estaba escribiendo el comentario que leo en el fuente del uTasker.

#define CLOCK_MUL        30     // the PLL multiplication factor to achieve operating frequency of 120MHz (x16 to x47 possible) [PLL output range 90..180MHz - VCO is PLL * 2]

Lo que no entiendo entonces es porque este hombre a puesto el MK66 a rodar a 120Mhz, cuando puede hacerlo a 180Mhz.

Y mi duda ahora mismo, esto es un bootloader, ¿ cuando salte a la aplicación de usuario se mantendrá la frecuencia del oscilador a la configurada en el bootloader, o a la configurada en la aplicación de usuario ?.

Que el bootloader ruede a 120Mhz me da igual, pero la aplicación de usuario tiene que rodar a 180Mhz, sino estoy desperdiciando la potencia del MK66, y mi aplicación la necesita sino hubiera puesto un MK64 a 120Mhz que es más barato.

[tsk]

No se como trabaja el bootloader de uTasker, pero revisa en las fuentes si antes de saltar a la aplicación de usuario deja el reloj en ese estado o lo pasa al estado inicial, ya que debe deshabilitar todo lo referente a IO, Interrupciones y Timers (Systick) antes de saltar a la aplicación de usuario, después la aplicación de usuario tiene que reconfigurar el reloj de acuerdo a sus propias especificaciones al igual que mover la dirección del vector de interrupciones,

Por ejemplo:

Código: C

1. /* A valid program exists, the we prepare the system to jump to
2.                          * the main firmware
3.                          */
4. MX_GPIO_DeInit();
5. SysTick->CTRL = 0x0;  //Disable SysTick Timer
6. HAL_DeInit();
7. RCC->CIR = (uint32_t) 0x0; //Disable clock interrupts
8.  
9. __set_MSP(*((volatile uint32_t *) APP_START_ADDRESS)); // Set MSP
10. __DMB(); //Need to be executed before relocating VTOR
11. SCB->VTOR = APP_START_ADDRESS;
12. __DSB(); // Need to be executed after relocating VTOR
13.  
14. /* Jump to the main firmware */
15. uint32_t MainFirmwareAddress = *((volatile uint32_t *)(APP_START_ADDRESS + 4)); //Jump address to the Reset Handler
16.  
17. void (*Reset_Handler)(void) = (void *)MainFirmwareAddress;
18. Reset_Handler();

ResetHandler que ya forma parte de la aplicación de usuario, llega a un punto donde manda llamar a la función (en el caso de los ST y el código generado por CubeMX) SystemInit

Código: ASM

1. /* Call the clock system intitialization function.*/
2.   bl  SystemInit

que es la función que se encarga de resetear el reloj al estado inicial.

Código: C

1. void SystemInit(void)
2. {
3.   /* FPU settings ------------------------------------------------------------*/
4.   #if (__FPU_PRESENT == 1) && (__FPU_USED == 1)
5.     SCB->CPACR |= ((3UL << 10*2)|(3UL << 11*2));  /* set CP10 and CP11 Full Access */
6.   #endif
7.   /* Reset the RCC clock configuration to the default reset state ------------*/
8.   /* Set HSION bit */
9.   RCC->CR |= (uint32_t)0x00000001;
10.  
11.   /* Reset CFGR register */
12.   RCC->CFGR = 0x00000000;
13.  
14.   /* Reset HSEON, CSSON and PLLON bits */
15.   RCC->CR &= (uint32_t)0xFEF6FFFF;
16.  
17.   /* Reset PLLCFGR register */
18.   RCC->PLLCFGR = 0x24003010;
19.  
20.   /* Reset HSEBYP bit */
21.   RCC->CR &= (uint32_t)0xFFFBFFFF;
22.  
23.   /* Disable all interrupts */
24.   RCC->CIR = 0x00000000;
25.  
26. #if defined (DATA_IN_ExtSRAM) || defined (DATA_IN_ExtSDRAM)
27.   SystemInit_ExtMemCtl();
28. #endif /* DATA_IN_ExtSRAM || DATA_IN_ExtSDRAM */
29.  
30.   /* Configure the Vector Table location add offset address ------------------*/
31. #ifdef VECT_TAB_SRAM
32.   SCB->VTOR = SRAM_BASE | VECT_TAB_OFFSET; /* Vector Table Relocation in Internal SRAM */
33. #else
34.   SCB->VTOR = FLASH_BASE | VECT_TAB_OFFSET; /* Vector Table Relocation in Internal FLASH */
35. #endif
36. }

[planeta9999]

OK, gracias, le echaré un ojo, supongo que el bootloader dejará que la aplicación de usuario tome el control total, pero lo verificaré.

[planeta9999]

 

Ya averigué porqué el bootloader uTasker está funcionando a 120Mhz, a pesar de que el MK66 puede rodar a 180Mhz. En los Kinetis (y puede que en todos los ARM Cortex M4), cuando grabas en la Flash, el reloj no puede ir a más de 120Mhz (Normal Run Mode), el modo rápido (HSRUN) puede trabajar incluso con overclocking a 192Mhz, 216Mhz y 240Mhz, pero no se puede usar si vamos a grabar en la Flash.

Lo que no me ha aclarado el autor del uTasker es si al pasar el control a la aplicación del usuario, la frecuencia del reloj cambia a la del aplicativo compilado a 180Mhz, o se mantiene a la fijada por el bootloader a 120Mhz.

Para salir de dudas voy a crear un miniprograma para medir la velocidad de proceso, creando un bucle de 100000 ó 1000000 de ciclos, capturando antes y despues el tiempo con la función millis(). Si con el aplicativo de usuario a 120Mhz o a 180Mhz me da el mismo resultado, es que el bootloader manda al fijar el reloj, espero que no porque sino estaría desperdiciando la potencia del MK66 haciéndolo rodar a 120Mhz.

Otra duda que tengo es sobre el overclocking. ¿ Es seguro, se puede dañar el micro, sobrecalentamiento, fallos, reseteos... ?, ¿ teneis alguna experiencia overclockeando un micro ?. Subir el MK66 de 180Mhz hasta los 240Mhz, me parece una pasada, siempre que lo aguante. No quisiera terminar con un montón de quejas, porque los micros empiecen a caer como moscas.

El overclocking del MK66 no es algo que quiera forzar yo de manera artificial, en el menú de Arduino para el Teensy 3.6 (que monta un MK66), te dan la opción de seleccionar como frecuencia de reloj, 192, 216 y 240Mhz, y te indican que es overclocking.

[tsk]

Dicen que funciona bien a 240Mhz pero en dos fuentes distintas mencionan que arriba de >192Mhz tiene problemas con i2c/i2s

I found overclocking the teensy to 240MHz did not allow the I2C OBD-II adapter to communicate with the teensy

http://www.instructables.com/id/Arduino-Car-Display/

No, it (3.6) works great with 240MHz.
But..I2S/Audioshield with >192 MHz....for me..not

https://forum.pjrc.com/threads/39213-Teensy-3-5-3-6-overclocking

Aunque no descarto que esos problemas sean por cuestiones de configuraciones internas de las librerías.

[planeta9999]

En mi caso, de momento no uso I2C ni I2S en los diseños con MK66. Igual lo pruebo en mis placas comerciales, pero solo si el aplicativo se me queja de falta de velocidad a 180Mhz, si no prefiero no arriesgar.

O igual pongo una placa de prueba aquí con un MK66 a 240Mhz, rodando una aplicación, conectada día y noche durante un par de semanas. A ver que pasa, si se calienta, si resetea o si termina quemándose.