martes, 22 de mayo de 2012

La infame versión Z

En diseño de circuitos uno espera que los componentes se comporten siempre de la misma manera, que cuando compras un recambio de un componente por otro que tiene exactamente el mismo nombre, el funcionamiento sea el mismo. Lamentablemente eso no siempre es así, y en ocasiones, el fabricante no se toma muchas molestias en avisarlo.

Explicaré un caso concreto con la placa STM32F4 Discovery. La mejor y más potente placa de la familia Discovery.

Placa STM32F4 Discovery

El problema


Hace ya un tiempo compré una placa de éstas y empecé a trabajar en el software. El entorno de trabajo, algún dia hablaré del él, está basado en Eclipse y usa compiladores GCC. Hasta el momento he probado con Code Sourcery y Yagarto. Para depurar empleo el servidor GDB que veía con la versión gratuita de Atollic True Studio for STM32.

Como todo iba bién con la placa compré una placa nueva, igualita a a la otra que ya tenía. Mi sorpresa fué que el debugger se colgaba al intentar comunicarse con el microcontrolador.
Para descartar que fuera una placa defectuosa intenté programar en la placa usando el software STLink Utility que proporciona gratuitamente ST para programar sus microcontroladores.

Nada más arrancar ya se veía que algo iba mal.

Aplicación STLink Utility

El software era capaz de comunicar con el microcontrolador, pero no era capaz de averiguar de que micro se trata tal como se desprende de la frase "Unknown Device" arriba a la derecha de la pantalla. Fijémonos, luego diré porqué, en la identificación de la CPU que es 0x413

Al intentar programar el dispositivo las cosas se complican.


Es extraño, nunca habia visto este mensaje, le digo que adelante.


El programa es incapaz de programar el micro. Por lo visto está activada la protección que deshabitlita el bus JTAG para que no pueda extraerse el código del micro. Es extraño porque la placa es nueva.
La protección se configura con los llamados option bytes. Voy a la ventana pertinente y sale algo como ésto:


Parece que la protección de lectura está activada y la flash está protegida contra escritura. No se puede programar el micro y no se puede quitar la protección. No se puede usar el micro para nada que no sea usar el software de demostración que ya venía en la placa.

¡¡ Y la placa era nueva !!


La solución

Después de mucho buscar por internet a alguien que le hubiera pasado algo similar encontré esta referencia.

Por lo visto la gente tenía problemas con la versión "Z" de la CPU. Las placas STM32F4 Discovery, por lo visto, llevaban antes CPUs de versión "A". El último batch de placas usa CPUs de versión "Z".

La siguiente figura muestra una CPU de versión A.

STM32F407 Version A


A continuación se muestra una CPU de versión Z.

STM32F407 VersionZ


Parece ser que en el paso de la versión A  a la versión Z, la identificación de la CPU ha pasado de 0x411 a 0x413. A continuación se muestra el programa STLink Utility conectado a una CPU de versión "A" donde se vé como se identifica como 0x411 a diferencia de la identificación 0x413 de la versión "Z".

STLink Utility con STM32F4 versión "A"
 

Misterio solucionado. Pero en esta historia hay algunos puntos muy molestos:

  • Que ST envie placas STM32F4 Discovery incompatibles con versiones anteriores del software sin avisar de los posibles problemas de compatibilidad.
  • Que ST no actualice la aplicación STLink cuando cambia los MCUs que soporta.
  • Que la aplicación STLink no sea capaz de decir que no sabe como trabajar con el micro en lugar de hacernos creer que se ha habilitado la protección contra escritura.

Suerte que en la misma referencia que cité anteriormente se proporcionaba el link a una versión parcheada de STLink Utility para poder programar la placa.

Como información adicional de los cambios de la versión "A" a la versión "Z", parece que no hay más versiones intermedias. Éstos están documentados en el la Errata Sheet del microcontrolador. Lo que no se dice en este documento es la incompatibilidad que produce con las propias aplicaciones de ST.

Finalmente me alegra decir que la versión actual del servidor GDB de ATollic True Studio es capaz también de comunicarse con la CPU "Z" maldita.























lunes, 7 de mayo de 2012

Calibrando el DCO

En este artículo explicaré por encima el funcionamiento del oscilador controlado digitalmente DCO de la familia MSP430 y explicaré un procedimiento, software incluido, para calibrar este oscilador para un conjunto de frecuencias elegido.

Para empezar, hablaremos del DCO...

Descripción del DCO

Los microcontroladores MSP430 de Texas Instruments, por ejemplo los compatibles con la placa Launchpad, disponen de un oscilador RC interno controlado digitalmente (DCO). El DCO se controla con 3 valores digitales:

  • RSELx  (0..15) Selecciona un rango de frecuencia de funcionamiento
  • DCOx   (0..7)   Selección fina de frecuencia dentro del rango elegido
  • MODx  (0..31) Modulación de frecuencia entre DCO elegido y el siguiente DCO+1
Los valores RSELx y DCOx, por tanto seleccionan la frecuencia del oscilador interno tal y como se muestra en la siguiente figura de la familia MSP430x2xx (slau144i).

Frecuencia vs RSEL,DCO
Se ha de tener en cuenta que los rangos que cubren los distintos valores de RSEL se pueden solapar entre si, por tanto, es posible que RSEL=7 DCO=7 de una frecuencia mayor que RSEL=8 DCO=0.

El valor de MODx permite un ajuste más fino de la frecuencia media del oscilador. Básicamente, cada 32 ciclos, (32-MOD) ciclos se harán con la frecuencia DCO y MOD ciclos se harán con la frecuencia DCO+1. Para que esto funcione el valor de DCO elegido ha de ser inferior a 7 ya que no existe DCO+1 cuando DCO=7. Ls siguiente figura muestra el patrón de modulación para distintos valores de MOD.

Modulación del oscilador DCO
Es importante notar que el uso de la modulación introduce Jitter en la señal de reloj. Eso puede ser o no importante para una aplicación concreta pero es importante tenerlo en cuenta si necesitamos instantes de captura completamente periódicos.
  

Calibración del DCO en producción

El problema general es que las relaciones entre RSEL y DCO y la frecuencia generada tienen una tolerancia muy elevada por lo que para tener frecuencias de operación mínimamente exactas es necesario calibrar el oscilador. A modo de ejemplo, para la familia MSP430G2x21 (slas694i) con RSELx = 7, DCOx = 3 y MODx = 0 que es el valor con el que arranca el microcontrolador, pueden dar valores de frecuencia entre 0,8 y 1,5 MHz. Esto es, el error puede ser de 0,35MHz (un 23%) respecto de un valor central de 1,15MHz.

Calibrar el oscilador es determinar que valores de RSEL, DCO y MOD se han de programar para generar una determinada frecuencia. Aún usando valores calibrados el oscilador tiene una cierta tolerancia que puede ser de hasta +/- 6% para todo el rango de temperaturas y tensiones de alimentación, pero, aun así, es mucha menos tolerancia que un DCO no calibrado. Sin embargo, si calibramos el oscilador cuando el circuito opera a la tensión y temperatura de operación, la deriva será mucho menor.

Todos los microcontroladores de la familia MSP430 se calibran en el momento de producirlos, al menos a la frecuencia de 1MHz. Los valores de RSEL, DCO, y MOD que han de programarse en los registros  DCOCTL (DCO y MOD) y BCSCTL1 (RSEL) se guardan en la memoria flash del microcontrolador.

Usar los valores calibrados en factoría está bien, pero tiene algunos inconvenientes:
  • Sólo podemos usar las frecuencias elegidas por Texas Instruments para nuestro microcontrolador. El MSPG2211 sólo tiene la de 1MHz, el MSPG2553 tiene lass de 1, 8, 12 y 16MHz. Si nos interesa una calibración a 4MHz, mala suerte.
  • Texas Instruments realiza sus calibraciones a 30ºC y 3V. Si nuestro sistema ha de operar lejos de estos valores la calibración no será buena.
Para solventar estos problemas podemos hacer la calibración nosotros mismos.


Calibración de usuario del DCO

Para realizar la calibración debemos de contrastar la frecuencia que genera el DCO con una referencia más exacta. Podemos entonces variar los valores de RSEL, DCO y MOD para lograr la frecuencia deseada.
Un buen patrón para realizar la calibración es el oscilador de cristal externo de 32768 Hz. Hay varios motivos para ello:

  • Un cristal de este tipo puede tener una precisión de 10 a 20ppm
  • Todos los microcontroladores de la serie MSP430 pueden usar un oscilador externo de 32768Hz
  • El Launchpad viene con un un cristal de este tipo, aunque sin soldar. En otro artículo hablo de como instalar un cristal de 32768Hz de manera temporal o permanente en el launchpad.
Buscando en internet se ve que hay varias personas que ya han llegado a esta conclusión como se demuestra aqui y aqui. Incluso existe una libreria de Texas Instruments al respecto.

En general, la mayor parte de soluciones reescriben la Sección A de Information Area de la flash del micrcontrolador que es donde Texas Instruments guarda la información de calibración del oscilador y otros elementos durante la producción. Es por eso que este área está especialmente protegida por un flag de seguridad (LOCKA).

Reescribir este área es potencialmente peligroso porque podemos perder información de calibración importante de otros elementos como el ADC y porque este área está protegida por un checksum que algunas aplicación podrían revisar. Es cierto que se puede recalcular el checksum, pero, igualmente corremos riesgos de borrar información importante.

 Los microcontroladores MSP430 tienen 3 áreas más de información (B,C,D) en la flash, todas ellas de 64 bytes igual que el área A, pero, a diferencia del área A, están vacían en los microcontoladores que salen de la factoría de Texas Instruments. En mi caso he pensado que sería mejor guardar la nueva información de calibración en la Sección B y no tocar la sección A para nada.

Dentro de esta área guardaré 9 valores de calibración para las frecuencias de 500Hz, 1MHz, 2MHz, 4MHz, 6MHz, 8MHz, 10MHz, 12MHz y 16MHz. La posición donde guardaré los valores de calibración las he incluido en un fichero NewDCOCal.h para tener una mejor referencia de sus posiciones. Si hace falta, se pueden cambiar o añadir nuevos valores de calibración si hace falta.


Programa de Calibración

Para realizar la calibración he realizado un programa DCO Calibration. Este program depende, a parte de NewDCOCal.h, del fichero io430masks.h. El programa se ha compilado con el compilador MSPGCC bajo Eclipse y, optimizado en tamaño, cabe en cualquier microcontrolador con al menos 2kB de flash.

El programa está pensado para hacerse correr en la placa Launchpad, por ello se emplean los siguientes pines:

         Xin/Xout : Cristal de 32768Hz
         P1.0 : Led Verde
         P1.3 : Pulsador a tierra
         P1.6 : Led Rojo

Adicionalmente se emplean dos pines para verificar los osciladores:
         P1.4 : Salida de cuadrada a la frecuencia del DCO
         P1.5 : Salida de 256Hz generada por el oscilador de 32768Hz
  
 Cuando el programa arranca, verifica si hay información en la sección de información B. Si hay información, pasa al modo de generación de frecuencia descrito más delante. Si no hay datos, se realiza la calibración, se guarda en la sección de información B de la flash y se pasa al modo de generación de frecuencia.
Durante la calibración el pin P1.4 muestra la frecuencia actualmente generada. Cada vez que se pasa a calibrar una nueva frecuencia, el led verde parpadea una vez. Si la calibración de una frecuencia se ha de repetir por no cumplir con la tolerancia deseada, parpadean los dos leds rojo y verde. 

En modo de generación de frecuencia el sistema programa la primera frecuencia de la lista de frecuencias calibradas (500kHz). Cada vez que se pulsa el pulsador que se halla en P1.3 se salta a la siguiente frecuencia de la lista para pasarse otra vez a la primera (500kHz) después de la última (16MHz). En este modo P1.4 tiene la frecuencia generada y el led verde parpadea a la frecuencia generada dividida por 20*65536 (20 desbordamientos del Timer A0).

En caso de error, el programa se bloquea mostrando un código de error mediante un número de parpadeos:

       (1)  Fallo del oscilador de 32768 Hz
       (2)  Problemas al calibrar una frecuencia
       (4)  No existe calibración de fábrica para 1MHz (necesaria para programar la flash)
       (5)  No puede lograrse la cota de error deseada (por defecto menos del 5%) 
       (Led Continuo) Problemas al arrancar el oscilador de 32768 Hz


Funcionamiento del programa

Para calibrar el oscilador el Watchdog se programa en modo temporizador con un período de unos 1,9ms (64/32768Hz) usando el oscilador de cuarzo. El timer A0 se configura en modo contínuo con el DCO como entrada. Se genera una captura del timer A0 cada vez que se da la interrupción del Watchdog. Calculando el número de ciclos del DCO entre dos capturas podemos inferir la frecuencia del DCO.

                    Frecuencia DCO = 512 * Ciclos entre capturas

Para aumentar la precisión, se promedia el intervalo de 50 capturas.

El programa comienza eligiendo el valor de RSEL, a continuación se elige el valor de DCO que se halla justo por debajo de la frecuencia deseada. Finalmente se ajusta la modulación MOD entre esta frecuencia de DCO y la siguiente.


Compilación condicional

El programa contiene 3 defines que permiten compilación condicional.

Si se activa el define DEBUG, el programa guarda los valores de RSEL, DCO y MOD junto con el error de calibración en cada frecuencia. De esta manera se puede verificar con el debugger.

Si se activa el define FLASH_OVERRIDE el programa reescribirá la información de la Sección B aunque no se halle vacía.

Si se activa el define TEST_MODE, toda la calibración se realizará en RAM para verificar el funcionamientod e la calibración sin tocar la memoria flash.


Video del funcionamiento

A continuación se muestra un video del funcionamiento del sistema de calibración en un Launchpad version 1.5 con el procesador MSP430G2553 que lleva por defecto. Junto al Launchpad tenemos un osciloscopio que muestra la frecuencia generada y un multimetro que trabaja como frecuencímetro.





miércoles, 2 de mayo de 2012

Instalación del Cristal en el Launchpad

 En este artículo hablaré de la instalación del cristal de cuarzo de 32768Hz en el Launchpad.  Un cristal de 32768Hz es fundamental para disponer de un reloj de tiempo real. En efecto 2^15 ciclos de este oscilador corresponden a un segundo. En el caso de la familia MSP430, en concreto, podemos usar el Watchdog en modo timer para generar una interrupción exactamente cada segundo usando como base este cristal de cuarzo.

Launchpad y bolsa con el cristal

 Este cristal de cuarzo viene incluido en la caja del Launchpad, pero no se halla soldado en la placa. El motivo por el que no viene soldado es porque el cuarzo ocupa 2 pines del microcontrolador que podrían ser usado como líneas de I/O. Dependiendo de la aplicación, por tanto, nos puede interesar no soldar este cristal para poder disponer de estas líneas. 

 En la siguiente figura se muestra la localización del cristal de cuarzo.

Localización del cristal

 El problema a la hora de poner el cristal es que el que se proporciona con el Launchpad es muy pequeño y cuesta de soldar. Para hacer las cosas más fáciles lo mejor es sujetar el cristal en su sitio con cinta adhesiva. Se ha de andar con ojo porque el cristal tiene delante y detrás. En la posición correcta los dos pines deben quedan apoyados sobre los pads de soldadura.



Cristal sujeto con cinta adhesiva
Para soldar el cristal conviene tener una lupa y un soldador de punta fina, pero con paciencia al final queda bien soldado. Si se cortocircuitan los pads, se retira el estaño con cinta de desoldar y vuelta a empezar.


Cristal soldado
Una vez soldados los dos terminales del cristal, podemos retirar la cinta adhesiva con cuidado de no arrancar el cristal y, a continuación, soldamos el cuerpo del cristal en el pad que tiene debajo.

Soldadura del cuerpo del cristal
Una vez soldado el cristal, se debe probar que funciona correctamente. Para ello he realizado un programa de test bajo Eclipse basado en dos ficheros main.c y io430masks.h.
El programa intenta poner en marcha el reloj basado en el cristal externo de 32768Hz. Si funciona correctamente, el led verde parpadea cambiando cada segundo. Si el oscilador falla, se enciende el led rojo.


Solución a problemas

Si el oscilador no funciona, lo primero es revisar las soldaduras.

El oscilador es muy sensible a cualquier interferencia. Los pines del oscilador, dado que pueden ser usados como I/O, están conectados a los pines de salida de la placa Launchpad. Para minimizar las interferencias se puede desconectar el oscilador de estos pines retirando las dos resistencais de cero ohmios que unen el oscilador con los pines. En la siguiente figura se muestra la localización de estas resistencias. Esta figura se puede comparar con la anterior que aún tenía las resistencias soldadas.

Resistencias eliminadas

Alternativa al la soldadura

Finalmente, para la gente a la que esta soldadura le resulte muy complicada o, para quienes no quieran sacrificar de manera permanente los dos pines de I/O, existe la posibilidad de poner el cristal de cuarzo conectado a los pines externos de la placa.

El procedimiento se puede hacer con el cristal que viene con el launchpad, pero, debido a su tamaño,no es la solución más cómoda.  Los osciladores de 32768Hz son fáciles de conseguir y baratos. Es importante, no obstante, comprarlos con una capacidad soportada por la familia MSP430 como 12,5pF o 6pF para no tener que añadir capacidades externas. A modo de ejemplo está este de Farnell que es el que he empleado.

En la siguiente figura se muestra un cristal de 32768Hz soldado a dos pines hembra.

Cristal soldado a pines hembra
Para emplear el cristal basta con conectarlo en la placa en los pines correspondientes.

Cristal sobre los pines de la placa

Con ello acaba este artículo sobre el cristal externo del Launchpad. Con un cristal como éste es fácil desarrollar aplicaciones que requieran una temporización precisa como sistemas basados en reloj de tiempo real, frecuencímetros, etc...