UNIVERSIDAD CARLOS III DE MADRID ESCUELA POLITCNICA SUPERIOR

INGENIERA EN TELECOMUNICACIONES PROYECTO FIN DE CARRERA

DESARROLLO Y VALIDACIN DE UN BOOTLOADER PARA APLICACIONES DE CARGA REMOTA EN ENTORNOS INALMBRICOS 802.15.4 Y ZIGBEE

AUTOR: Jorge Jimnez Wrzburger TUTOR: Dr. Jos Ignacio Moreno Novella

19 Noviembre 2009

PROYECTO FIN DE CARRERA

Departamento de Ingeniera Telemtica Universidad Carlos III de Madrid
Ttulo: Desarrollo y validacin de un bootloader para aplicaciones de carga remota en entornos inalmbricos IEEE 802.15.4 y ZigBee. Autor: Jorge Jimnez Wrzburger. Tutor: Dr. Jos Ignacio Moreno Novella.

EL TRIBUNAL
Presidente: D. Mario Muoz Organero Secretario: D. ngel Cuevas Rumn Vocal: Da. Matilde Snchez Fernndez

Realizado el acto de defensa y lectura del Proyecto Fin de Carrera el da 19 de Noviembre de 2009 en Legans, en la Escuela Politcnica Superior de la Universidad Carlos III de Madrid, acuerda otorgarle la CALIFICACIN de:

Presidente

Secretario

Vocal

Resumen
En el entorno hostil que suele representar una red inalmbrica de sensores (WSN): escenarios con alta densidad de dispositivos, equipos instalados en localizaciones de difcil acceso, comunicaciones de alta latencia sobre canales ruidosos con numerosas interferencias, etctera, se hace necesario un mecanismo que posibilite la actualizacin del firmware de los componentes del sistema. De esta forma se podran corregir errores de funcionamiento, modificar parmetros de comportamiento o simplemente aadir nuevas funcionalidades a los dispositivos de la red.

La tecnologa ZigBee, diseada para la intercomunicacin inalmbrica de dispositivos de reducida capacidad, tamao, consumo y coste, se plantea como una de las ms apropiadas para cubrir la mayora de las necesidades demandadas en el campo de las redes de sensores.

Sin embargo ni el estndar ZigBee, ni los perfiles superiores de aplicacin que funcionan sobre l, especifican el procedimiento que han de seguir los dispositivos para actualizar su firmware, dejando que cada fabricante plantee su solucin propietaria para los productos que introduce en el mercado.

As pues, el objetivo de este proyecto ser desarrollar un cargador de arranque (bootloader) capaz de sustituir el firmware en ejecucin en dispositivos ZigBee por otro que previamente una aplicacin de carga remota ha recibido y almacenado en una memoria auxiliar.

Para ello, ser necesario familiarizarse previamente con el entorno de desarrollo (CodeWarrior) y las libreras IEEE 802.15.4 y ZigBee que suministra uno de los principales fabricantes de chips en la banda de frecuencias de 2,4GHz, Freescale, para una vez adquirida la capacidad de crear nuevas aplicaciones sobre ellas y entender el funcionamiento de las diferentes capas, programar el bootloader.

Puesto que el procedimiento interno de actualizacin del firmware de un dispositivo ZigBee es muy dependiente de los componentes (chip, memoria, bus, etc.) que integre, ser necesario estudiar tambin, a lo largo del desarrollo del proyecto, el caso concreto de los circuitos de los equipos que pretenden soportar esta aplicacin.

Finalmente, puesto que el bootloader debe ser capaz de actualizar equipos ZigBee de forma independiente del modo en que la nueva imagen llegue hasta la memoria auxiliar, ser imprescindible elaborar una aplicacin auxiliar (cargador RS232) capaz de transmitir el nuevo firmware al dispositivo. La elaboracin de este cargador permitir depurar y validar el funcionamiento del bootloader adems de evaluar el formato ptimo de almacenamiento de la nueva imagen de firmware en la memoria auxiliar.

Abstract
In the hostile environment that is often a wireless sensor network (WSN), a great need of a system devices firmware updating mechanism rises up. This way, application bugs could be fixed, devices behaviour could be modified and new functionalities could be added.

ZigBee technology is designed to grant wireless communications between small, low consumption & low cost devices, so it is probably the most appropriate standard to meet the needs demanded in the field of sensor networks.

However, neither the ZigBee standard nor the application profiles specify how wireless devices can update their firmware. So each manufacturer will have to develop its proprietary solution for the devices that sells.

Thus, the objective of this final thesis is to develop a boot loader capable of replacing the old firmware running on a ZigBee device by a new one previously stored in an auxiliary EEPROM by a remote programming application.

To achieve this aim, the first step to be taken will be choosing a suitable ZigBee chip manufacturer (Freescale) and then becoming familiar with its development environment (CodeWarrior) and its IEEE 802.15.4/ZigBee libraries.

Freescale is nowadays one of the leading ZigBee chip manufacturers working on the frequency band of 2.4 GHz and, at the time this thesis started, it was probably the best choice.

Since the internal process of updating the firmware of a ZigBee device is highly dependent on its integrated components (chip, memory, bus, etc...) a deep study of chosen ZigBee devices integrated circuits will have to be done next in order to successfully develop the bootloader.

Finally, since the developed application should be able to update ZigBee devices in real time independently of the means the new image is stored in the EEPROM. To achieve that, it will be essential to develop next an auxiliary application (RS232 loader) capable of transmitting the new firmware to the device so the programmed bootloader could be debugged and validated.

In addition to all this, the optimum format for storing the new firmware image in the auxiliary memory will be discussed.

Agradecimientos
Cuando estoy por fin a punto de acabar esta etapa de mi vida, que en ocasiones pens que nunca lograra terminar, no me queda ya ms que agradecer a todos aquellos que han hecho que este momento sea posible.

En primer lugar quiero agradecer a mis padres y a mi hermana su apoyo y comprensin incondicional en todo momento, incluso en las ocasiones en que haba perdido completamente el rumbo. Si estoy ahora aqu es gracias a vosotros.

Igualmente gran parte del mrito es de Sara, mi paciente compaera de los ltimos aos, cuyos fuertes puntapis en mi trasero han sido sin ninguna duda el acicate que necesitaba para dar el ltimo paso de terminar esta memoria. Muchsimas gracias por soportarme y apoyarme a lo largo todo el proceso. Ha sido un privilegio compartirlo contigo.

Un agradecimiento especial merece tambin toda la gente maravillosa que he tenido la oportunidad de conocer en la universidad. Mis amigos de los primeros aos: Carlos, Edu, Dani, Ral, Emilio, Nacho y Sara, Chico, Elisa, Cano, Ivn, lvaro y Raquel, Guillermo y Sara, Gabi, Noelia, Adrin, Pablo, Patri, Ruth, Sergi, Turrin, Sonia, Natalia, Eva, Sergio y Ramn, con los que he superado muchos malos momentos y disfrutado an muchos ms buenos.

Mis amigos de los ltimos aos, responsables en gran medida de que volviese a disfrutar con la carrera en la mejor compaa. Nunca se me van a olvidar todas esas situaciones de risas histricas con vosotros en la biblioteca, a la una de la maana, la vspera de los exmenes. Muchas gracias Aitor, Marcelo, Arry, Fito, Miri, Merche, Mele, Ivn, Ivanga, Jauma, Ysus, Inma, Joseto, Davo, RAM, Sofi, Isidro, Marta, Nere, David y Demelza.

Mis compaeros de la asociacin, con los que he compartido infinidad de momentos buenos, merecen tambin una mencin especial. Gracias Pablo (Presi), Raquel, Juanvi, Carlitos, Corts, Carlos, Isaac, lvaro, Chus, Sacha, lex, Gorka y Morn.

Mis compaeros del servicio informtico tambin aportaron su granito de arena a todo este proyecto, de modo que mil gracias Pay, Movi, Ivn, David, Mayte, Chechu, Amarri y Jeda.

A mis amigos del barrio, que pacientemente han soportado mis continuos desplantes a lo largo de aos sin mandarme al cuerno. Ahora que me quedo sin excusas para seguir siendo un mal amigo, voy a tener que hacer algo al respecto. Muchas gracias Pablo, Irene, Jose, Gonzalo, Miguel, Daro, Rubn, Raquel, Bedoya, Fiz y Peni.

Mis compaeros de NLaza, junto a los que he aprendido mucho, merecen tambin mi agradecimiento. Gracias muchas pues, seores David (qu grandes nuestras conversaciones), Pedro y Jos.

Tambin quiero agradecer a mi tutor, Jos Ignacio Moreno, que me ha ayudado a terminar este proyecto a pesar de la tremenda informalidad a la que le he sometido. En serio, muchsimas gracias.

Igualmente quiero agradecerle a su equipo, Grego, Gema, y Vctor, todas las risas compartidas y el apoyo mostrado.

En ltimo lugar, muchas gracias tambin a todos aquellos que no cresteis que lo conseguira, fuisteis la inspiracin que necesitaba.

ndice
1. Captulo 1 - Motivacin y Objetivos ................................................................. 11 1.1. Motivacin .......................................................................................................... 12 1.2. Objetivos ............................................................................................................. 16 1.3. Organizacin de la Memoria .......................................................................... 18 1.4. Medios Materiales para la Ejecucin del Proyecto .................................. 22 2. Captulo 2 Estado del Arte............................................................................... 24 2.1. Introduccin a las Redes de Sensores Inalmbricas ............................. 25 2.2. El Estndar 802.15.4......................................................................................... 28 2.2.1. Introduccin y Aspectos Generales ........................................................ 28 2.2.2. Topologas de Red ....................................................................................... 29 [Link]. [Link]. Topologa en estrella ................................................................................. 30 Topologa peer-to-peer ............................................................................. 31

2.2.3. Arquitectura de Red..................................................................................... 32 2.2.4. Nivel Fsico (PHY)......................................................................................... 33 [Link]. Bandas de Frecuencia y Consideraciones Generales .......................... 33 [Link]. Formato de Trama ...................................................................................... 35 [Link]. Servicios del Nivel Fsico ........................................................................... 36 2.2.5. Nivel de Acceso al Medio (MAC) .............................................................. 37 [Link]. Mecanismos de Control de Acceso al Medio ......................................... 37 [Link]. Modelos de Transferencia de Datos ........................................................ 39 [Link]. Formato de Trama ...................................................................................... 42 [Link]. Servicios del Nivel MAC ............................................................................. 43 2.3. La especificacin ZigBee ............................................................................... 48 2.3.1. Consideraciones Generales ...................................................................... 49 [Link]. Tipos de Dispositivos .................................................................................. 49 [Link]. Topologas de Red ...................................................................................... 50 [Link]. Arquitectura de Referencia ZigBee .......................................................... 50 2.3.2. Nivel de Red ................................................................................................... 52 [Link]. Entidad de Datos del Nivel de Red .......................................................... 53 [Link]. Entidad de Gestin del Nivel de Red ....................................................... 53 [Link]. Formato de Trama de Red ........................................................................ 54

2.3.3. Nivel de Aplicacin ....................................................................................... 55 [Link]. Subnivel de Soporte de Aplicacin (APS) ............................................... 55 [Link].1. [Link].2. Ligaduras (Bindings) .............................................................................. 56 Transmisin de Mensajes de Capa de Aplicacin ............................ 57

[Link]. Plataforma de Aplicacin (AF) .................................................................. 57 [Link].1. [Link].2. Perfiles de Aplicacin (Profiles) ............................................................ 58 Racimos (Clusters) ................................................................................. 59

[Link]. Objeto de Dispositivo (ZDO) ..................................................................... 59 2.4. Plataformas ZigBee Disponibles en el Mercado ...................................... 61 2.5. Soluciones de Autoconfiguracin de Dispositivos ................................. 64 3. Captulo 3 Escenario de Aplicacin y Requisitos ..................................... 66 3.1. Introduccin ....................................................................................................... 67 3.2. Requisitos de una Red de Sensores de Bajo Consumo ........................ 67 3.3. Requisitos de una Aplicacin de Actualizacin de Firmware .............. 69 3.4. Dispositivo NLaza NDimension ND07 ......................................................... 72 3.4.1. Especificaciones Elctricas y Generales............................................... 73 3.4.2. Plataforma MC13213 System-On-Chip de Freescale .......................... 76 3.4.3. Configuracin del Dispositivo (Funcionamiento y Desarrollo) ....... 79 3.5. Entorno de Desarrollo: CodeWarrior for MicroControllers v5.1 .......... 83 3.6. Generacin de Aplicaciones ZigBee de Ejemplo: BeeKit ...................... 85 3.7. Librera ZigBee 2006 de Freescale: BeeStack 1.0.5. ............................... 87 3.7.1. Introduccin................................................................................................... 87 3.7.2. Descripcin de Capas y API ...................................................................... 89 3.7.3. Bugs Conocidos y Reconocidos por Freescale .................................. 93 3.8. Bus I2C (Inter-Integrated Circuit) y TWI (Two Wire Interface) ............... 96 3.8.1. Diseo de Referencia .................................................................................. 96 3.8.2. Capa Fsica..................................................................................................... 99 3.8.3. I2C vs. TWI .................................................................................................... 100 3.8.4. I2C en el AT24C512 ..................................................................................... 101 [Link]. Escritura Sobre la EEPROM AT24C512 ............................................... 101 [Link]. Lectura de la EEPROM AT24C512 ........................................................ 102 3.9. Estndar RS232 ............................................................................................... 104 3.9.1. Niveles de Voltaje ....................................................................................... 105

3.9.2. Conectores y Seales ............................................................................... 106 3.9.3. Configuracin .............................................................................................. 108 4. Captulo 4 Bootloader y Aplicaciones Auxiliares ................................... 109 4.1. Bootloader ........................................................................................................ 110 4.1.1. Introduccin: Conceptos Bsicos ......................................................... 111 4.1.2. Elementos Relacionados con el Bootloader....................................... 113 [Link]. Mdulos de la Secuencia de Arranque .................................................. 114 [Link]. Memoria del MC13213 ............................................................................. 117 [Link].1. [Link].2. [Link].3. [Link].4. [Link].5. Memoria Flash del MC13213. Algoritmos de Sobrescritura .......... 120 Proteccin de Bloques de Memoria Flash ........................................ 124 Redireccin de los Vectores de Interrupcin ................................... 126 Seguridad de la Memoria .................................................................... 128 El Componente NVM (Non-Volatile Memory) .................................. 129

[Link]. Mdulo I2C del MC13213 ......................................................................... 132 [Link]. Vectores de Interrupcin .......................................................................... 135 [Link]. Watchdog ................................................................................................... 136 4.1.3. Formatos de Firmware: Registros S19 y S19 Modificados ............. 139 [Link]. Fichero Motorola S19 ............................................................................... 139 [Link]. Formato de Almacenamiento de Imgenes en EEPROM .................. 140 4.1.4. Desarrollo del Bootloader ........................................................................ 148 [Link]. Estructura de la Aplicacin ...................................................................... 148 [Link].1. [Link].2. [Link].3. [Link].4. Bucle de Lectura de Registros S19 Modificados ............................. 153 Bucle de Sobrescritura de la Memoria Flash ................................... 160 Bloque de Sobrescritura de la Pgina Flash 127 ............................ 163 Comprobaciones Finales y Reset (Fin de la Actualizacin) .......... 164

[Link]. Validacin de la Actualizacin del Firmware ........................................ 166 [Link]. Opciones del Compilador y del Enlazador (Linker) ............................. 167 [Link].1. [Link].2. [Link].3. Opciones del Compilador .................................................................... 168 Pragmas ................................................................................................. 170 Opciones del Enlazador y Fichero de Parmetros(PRM) .............. 171

[Link]. Programar Cdigo en Ensamblador....................................................... 173 [Link]. Localizacin Inteligente del Bootloader ................................................. 175 [Link].1. Emplazamiento en la Memoria (RAM y Flash) ................................ 176

[Link].2.

Emplazamiento en la Secuencia de Arranque ................................. 177

4.1.5. Servicio Tcnico de Freescale ................................................................ 181 4.1.6. Actualizaciones de Libreras: Consecuencias y Estado Actual .... 183 4.2. Aplicacin Auxiliar: Cargador RS232 ........................................................ 185 4.2.1. Introduccin y Objetivos .......................................................................... 185 4.2.2. Descripcin de la Aplicacin y Esquema de Funcionamiento ...... 186 5. Captulo 5 Validacin del Sistema............................................................... 190 5.1. Introduccin ..................................................................................................... 191 5.2. Validacin Mediante el Depurador ............................................................. 191 5.3. Validacin Mediante Trazas Serie RS232 ................................................. 194 5.4. Validacin Mediante Trazas Radio (ZigBee) ............................................ 195 5.5. Validacin del Sistema Completo .............................................................. 197 6. Captulo 6 Conclusiones y Trabajos Futuros........................................... 201 6.1. Visin Global del Proyecto. Conclusiones .............................................. 202 6.2. Trabajos Futuros............................................................................................. 204

Apndice A Instrucciones y Recomendaciones de Instalacin .............. 205 Apndice B Presupuesto ................................................................................... 214 Apndice C Glosario y Acrnimos .................................................................. 221 Apndice D Bibliografa y Referencias........................................................... 226

10

Captulo 1 Motivacin y Objetivos

11

1.1.

Motivacin

Las redes de sensores llevan siendo objeto de investigacin y estudio desde hace ya ms de una dcada. Las relativamente recientes publicaciones de estndares y soluciones en este campo, como pueden ser IEEE 802.15.4 [1], ZigBee [5], Z-Wave [7], Bluetooth ULP [8], etc., estn propiciando la salida de estas tecnologas de los laboratorios de investigacin hacia el mercado de consumo.

Aunque las primeras investigaciones sobre redes de sensores estaban orientadas principalmente hacia aplicaciones militares, hoy en da se conciben aplicaciones mucho ms diversas como son la automatizacin del hogar y edificios, la automatizacin industrial o la lectura automtica de contadores, por ejemplo.

Debido entre otras cosas a los retrasos producidos en la publicacin de especificaciones y estndares de protocolos de comunicacin para redes de sensores, ha tenido lugar la aparicin de diversas tecnologas propietarias que pretenden extender su solucin particular en el mercado.

El estndar IEEE 802.15.4 para comunicaciones inalmbricas a 250 Kbps en la banda sin licencia de 2.4GHz (y sus alternativas de menor velocidad de transferencia en las bandas de 868 y 900 MHz), as como la posterior especificacin ZigBee, han supuesto unas de las ms robustas alternativas de acceso pblico ante la amplia oferta de tecnologas propietarias.

Esta caracterstica (estndar de pblico acceso) convierte a ZigBee en una opcin muy atractiva para los desarrolladores de productos inalmbricos, ya que asegurar la interoperabilidad de sus dispositivos con los de otras marcas. Por otro lado tambin ser atractiva para los clientes finales, ya que no dependern de una nica compaa y podrn disponer de diferentes opciones a la hora de ampliar su red.

El estndar IEEE 802.15.4 es un protocolo abierto diseado para posibilitar una comunicacin fiable y segura entre dispositivos de bajo consumo (muchas veces a pilas y dormidos la mayor parte del tiempo) que forman redes en forma de rbol, estrella o malla y trabajan sobre bandas de frecuencia gratuitas pero colmadas de interferencias. Para poder garantizar dicha fiabilidad, el estndar provee de un protocolo muy robusto frente a las perturbaciones producidas por otras comunicaciones o emisiones de dispositivos domsticos basado en tcnicas de espectro ensanchado (DSSS), control de acceso al medio y deteccin de colisiones.

ZigBee se presenta como una especificacin no propietaria de las capas de red, transporte y aplicacin que habr de funcionar sobre las capas fsica y de acceso al medio (MAC) que ofrece el estndar IEEE 802.15.4. De este modo, se beneficia de sus propiedades y aporta

12

valor aadido al proporcionar soluciones nter operables, de bajo coste y bajo consumo en entornos de automatizacin del hogar, de edificios, industrial, de lectura automtica de contadores (AMR) y un largo etctera.
[9]

La ZigBee Alliance

es una asociacin de ms de 225 compaas de 28 pases distintos que

trabajan de forma conjunta para posibilitar la elaboracin de productos fiables, econmicos y de bajo consumo que, interconectados mediante red inalmbrica, permitan monitorizacin y control y se basen todos ellos en el mismo estndar global abierto.

Los miembros actuales de la ZigBee Alliance son proveedores y fabricantes de tecnologa en el todo el mundo lo cual, junto con la extensa gama de transceptores en las bandas de frecuencia de 800, 900 y 2400MHz disponibles en el mercado actual, posibilita la aparicin inminente de una gran variedad de productos ZigBee robustos, relativamente baratos y fiables.

Con todo esto el estndar ZigBee parece ser, a da de hoy, una de las tecnologas ms interesantes para el desarrollo de aplicaciones que funcionen sobre redes de sensores inalmbricas, formadas por dispositivos de bajo consumo y coste reducido. Esto se debe a que:

Trabaja sobre el estndar pblico IEEE 802.15.4, diseado por una de las entidades certificadoras ms importantes y slidas del mundo. La ZigBee Alliance, responsable de la elaboracin de la especificacin ZigBee, es una asociacin de compaas muy representativas del sector (tales como Philips, Texas Instruments, Motorola, Siemens o Honeywell) siempre interesadas en sacar un producto funcional y slido al mercado que ser continuamente perfeccionado para cubrir todas las necesidades que vayan surgiendo. A da de hoy contina publicando revisiones y mejoras de la especificacin, as como diferentes perfiles de aplicaciones (Home Automation redes de sensores [12] [13].
[10] [11]

, Smart Energy

, Building Automation,

Automatic Meter Reading) para cubrir las necesidades emergentes del mercado de

Al ser una especificacin pblica, muchas compaas suministran kits de desarrollo que incluyen la pila de protocolos IEEE 802.15.4 y ZigBee que permite implementar aplicaciones sobre sus chips de la forma ms rpida posible [14] [15] [16]. De esta forma, es relativamente sencillo empezar a desarrollar aplicaciones ZigBee una vez se ha elegido el chip y el transceptor radio de un fabricante determinado.

Una vez elegida la tecnologa ZigBee como protocolo de comunicaciones inalmbricas en un entorno de redes de sensores de bajo consumo y coste reducido, es preciso preguntarse qu tipo de aplicaciones funcionarn sobre sta. Para ello la especificacin ZigBee soporta una serie de perfiles de aplicacin (profiles) que definen el formato de un conjunto de comandos,

13

atributos y variables que sern necesarios para que una aplicacin determinada funcione correctamente sobre una red de sensores formada por dispositivos de diferentes fabricantes.

Estos perfiles son desarrollados y mantenidos por las compaas integrantes de la ZigBee Alliance y responden a las necesidades de una red de sensores de bajo consumo soportando muy diversas aplicaciones destinadas a entornos como podran ser la automatizacin del hogar, la automatizacin industrial o la lectura automtica de contadores.
[10]

De este modo, el perfil del Home Automation

(primer perfil ZigBee publicado por la ZigBee

[17]

Alliance en el ao 2007 y destinado a la automatizacin del hogar

), incluye las

especificaciones necesarias que tendrn que cumplir dos (o ms) dispositivos de diferentes fabricantes para poder funcionar de forma conjunta. Ejemplos seran pues un interruptor inalmbrico y una fuente de luz regulable, un sensor de temperatura y un termostato, etc.

En este escenario de aplicaciones y dispositivos tan diversos, se hace necesario un mecanismo que permita poder actualizar el firmware de los equipos, ya sea para reemplazar el cdigo que se est ejecutando (por ejemplo en el caso de la automatizacin del hogar, actualizar un interruptor OnOff a un interruptor regulable), para aadir nuevas funcionalidades, o simplemente para corregir errores de la aplicacin.

Hay que tener en cuenta que las redes de sensores inalmbricas pueden presentar una alta densidad de dispositivos (lo cual puede complicar su identificacin) y estar posicionados en localizaciones de difcil acceso como pueden ser techos, cajas de registro o tomas elctricas. Idealmente, en una red ZigBee, cada sensor dispondr del mnimo nmero indispensable de perifricos y puntos de acceso integrados ya que eso reducir su coste y consumo al mximo.

Todos estos factores, junto con el hecho de que de momento no existe un mtodo de actualizacin estandarizado en la especificacin ZigBee o en los perfiles de aplicacin (profiles), propiciarn que cada fabricante disee su mtodo propietario para actualizar el firmware de los dispositivos que suministra.

De todas las soluciones posibles aplicables a un entorno tan heterogneo como puede llegar a ser una red ZigBee, la solucin inalmbrica se plantea claramente como la opcin ms interesante ya que cubre el mayor nmero de situaciones posibles. Esto se debe a que todos los dispositivos dispondrn obligatoriamente de una antena y sern capaces de comunicarse mediante el mismo protocolo dentro de las mismas bandas de frecuencia.
[18]

El proceso de actualizacin inalmbrica (Over the Air Programming separar siempre en dos partes perfectamente diferenciables:

) del firmware, se puede

14

1. Carga Remota: protocolo de transferencia del nuevo firmware desde un dispositivo emisor a uno o varios receptores a travs de la red para su posterior almacenamiento. Este protocolo ser siempre independiente del hardware de los dispositivos receptores y podra permitir a dos fabricantes distintos actualizar sus equipos de forma idntica siempre que implementen un algoritmo comn en sus aplicaciones. 2. Bootloader: aplicacin responsable de la actualizacin del firmware antiguo por el nuevo en tiempo de ejecucin y de la reinicializacin del dispositivo. Este procedimiento es fuertemente dependiente del hardware implicado y ser especfico de cada modelo de dispositivo ZigBee.

Este proyecto pretende desarrollar pues un bootloader, que ser capaz de sustituir una aplicacin en ejecucin en un dispositivo ZigBee por otra nueva almacenada previamente en su memoria auxiliar. El protocolo elegido para que dicha actualizacin sea transmitida y almacenada en el dispositivo ser trasparente al funcionamiento del bootloader (pero el conjunto deber ser compatible).

15

1.2.

Objetivos

Este proyecto surge como una colaboracin entre la Universidad Carlos III de Madrid y la empresa NLaza Soluciones
[19]

para la elaboracin conjunta de una solucin capaz de

actualizar el firmware de los dispositivos 802.15.4 y ZigBee suministrados por esta ltima.

De esta forma, el desarrollo de esta solucin se dividir en dos secciones: la relativa a la transferencia inalmbrica e interfaz con el usuario (carga remota) y la relativa al almacenamiento, actualizacin del firmware y reinicializacin del dispositivo (bootloader). Ambas partes son perfectamente diferenciables y es esta ltima, el bootloader, el objetivo final de este proyecto.

Para lograr dicho objetivo ser necesario estudiar en primer lugar el funcionamiento del estndar IEEE 802.15.4 y de la especificacin ZigBee. De este modo se podr despus entender adecuadamente la implementacin que de estos protocolos hacen las libreras de Freescale (compaa que formaba parte de Motorola hasta el ao 2004 y que es uno de los principales fabricantes de chips en la banda de frecuencia de 2.4GHz; chips que adems estn integrados en las placas de NLaza Soluciones).

Posteriormente seguir un proceso de familiarizacin con el entorno de desarrollo y las libreras de Freescale tras el cual, una vez adquirida la capacidad de crear nuevas aplicaciones y entender la comunicacin existente entre las diferentes capas, se proceder a desarrollar un bootloader que posibilite la actualizacin del firmware a travs de distintos mecanismos: puertos serie, interfaz radio, etc.

El bootloader desarrollado deber ser capaz de desempear las siguientes funciones ante una solicitud emitida desde la aplicacin anfitrin: acceder a la imagen del nuevo firmware almacenado previamente en una memoria EEPROM (integrada en los dispositivos NLaza Soluciones y accesible mediante el protocolo I2C), interpretar su formato, borrar la memoria Flash, sobrescribirla con la imagen almacenada, realizar las comprobaciones de seguridad y validacin pertinentes y, en ltimo lugar, reinicializar el sistema.

Puesto que tanto las partes relativas a la carga remota como la relativa al bootloader (este proyecto) sern desarrolladas de forma simultnea e independiente por dos equipos de trabajo diferentes, el siguiente paso a dar ser la elaboracin de un cargador serie (RS232) que se encargue de preparar imgenes de prueba en la memoria auxiliar del dispositivo.

Esta aplicacin auxiliar permitir ir depurando la aplicacin desarrollada as como ir evaluando y optimizando el formato de almacenamiento de las imgenes en el equipo receptor.

16

Cerca del final del trabajo se analizar el hardware integrado en los equipos ZigBee suministrados por NLaza Soluciones para poder configurar los puertos y perifricos de forma que el bootloader pueda: acceder al nuevo firmware preparado en la memoria auxiliar, regrabar la memoria del dispositivo, reinicializar la placa y permitir al resto de las aplicaciones trabajar de forma transparente mientras no se est actualizando el dispositivo.

As pues el objetivo final de este proyecto ser obtener un bootloader capaz de actualizar el firmware de un dispositivo ZigBee de forma fiable, robusta, transparente al resto de aplicaciones y que adems sea independiente del mecanismo (inalmbrico o no) que se emplee para hacer llegar la nueva imagen al dispositivo receptor.

La nica condicin necesaria para esta transmisin ser que la nueva imagen termine alojndose en la memoria EEPROM auxiliar siguiendo un formato concreto que se acordar de antemano. Dicho formato se disear de forma que optimice el espacio disponible en la EEPROM dadas las restricciones existentes de memoria, batera y capacidad de proceso.

17

1.3.

Organizacin de la Memoria

Para entender correctamente la estructura de este proyecto, es necesario tener en cuenta que se ha dedicado tanto tiempo al estudio terico de las redes ZigBee y a los mdulos contenidos en el chip elegido, como al trabajo prctico que ha supuesto la familiarizacin con el entorno de desarrollo, la programacin y depuracin de las aplicaciones, y la validacin de stas.

As pues, la organizacin de la memoria se ha llevado a cabo en varios captulos que aparecen ordenados de forma ms o menos cronolgica en el ndice de este documento.

De este modo, los primeros captulos sern principalmente tericos, ya que describirn el estado del arte de la tecnologa y las caractersticas de la plataforma finalmente seleccionada (y las razones que justifican dicha eleccin).

Los siguientes captulos se centrarn en las herramientas y protocolos con los que habr que familiarizarse para desarrollar la aplicacin objetivo de este proyecto (captulo 3, escenario de aplicacin) y en el estudio de los mdulos de la plataforma MC13213 directa o indirectamente relacionados con dicha aplicacin (primeros subapartados del captulo 4).

Inmediatamente despus, se explicar el diseo, desarrollo y la validacin de las aplicaciones del bootloader y del cargador RS232 (resto del captulo 4 y el captulo 5). Este bloque representar el grueso del trabajo prctico realizado.

Finalmente se desarrollarn las conclusiones obtenidas fruto del desarrollo de este proyecto y se esbozarn los posibles trabajos futuros que podran surgir a raz de stas (captulo 6 y apndices).

A continuacin se ofrece un breve resumen de cada captulo para facilitar una visin global del trabajo realizado.

Captulo 1: Motivacin y Objetivos

En este captulo se introducen las necesidades relacionadas con la carga remota a las que es necesario dar solucin y se concretan exactamente los objetivos que se pretenden alcanzar con este proyecto a ese respecto.

Adicionalmente, se explicar la distribucin de esta memoria y se presentarn los medios materiales que han sido necesarios para el desarrollo efectivo del proyecto.

18

Captulo 2: Estado del Arte

En el captulo 2 se introducirn de forma resumida las tecnologas inalmbricas de bajo consumo de redes de sensores disponibles en la actualidad (y en el momento concreto en que se inici este proyecto) para luego estudiar de forma ms profunda los estndares 802.15.4 y ZigBee, sobre los que se basar este proyecto.

A continuacin se proceder a realizar una evaluacin de las plataformas ZigBee disponibles en el mercado a principios del 2007 (y en la actualidad) y a justificar la eleccin de una de ellas: Freescale.

Finalmente se introducirn algunas de las soluciones existentes para la autoconfiguracin de dispositivos de comunicaciones. Se obtendr as una idea general de lo que se trata de conseguir y los mtodos que se emplean habitualmente para ello.

Captulo 3: Escenario de Aplicacin y Requisitos

Este captulo se inicia con la exposicin de los requisitos que una red de sensores de bajo consumo y que una aplicacin de actualizacin de firmware han de satisfacer, ya que stos sern luego objetivos primordiales del proyecto.

De estos requisitos se concluir la necesidad de disponer de una aplicacin abierta capaz de actualizar el firmware de los dispositivos en tiempo de ejecucin. Sin embargo una parte fundamental de esta aplicacin, el bootloader, es completamente dependiente del hardware elegido, de forma que ser necesario seleccionar un producto comercial real para su desarrollo.

El dispositivo elegido finalmente ser el ND07 de la lnea de productos de NLaza Soluciones, que es un coordinador ZigBee con puerto RS232 para comunicaciones serie basado en el chip MC13213 de Freescale.

A continuacin se analizarn el chip elegido (MC13213) y el dispositivo que lo integra (ND07), para tener consciencia de los mdulos que los componen y que habr que aprender a controlar.

Posteriormente se estudiar la librera ZigBee y el entorno de desarrollo ofrecidos por Freescale para adquirir la capacidad de programar nuevas aplicaciones ZigBee mediante ellas. En ltimo lugar se explicarn dos protocolos de comunicacin, el bus I2C y el protocolo RS232, que ser imprescindible familiarizarse para implementarlos dentro de la aplicacin final.

19

Captulo 4: Bootloader y Aplicaciones Auxiliares

El captulo 4 comenzar con una introduccin al concepto de bootloader haciendo especial nfasis en la nomenclatura que se emplear en el resto de la memoria.

A continuacin se desarrollar un estudio en profundidad de los mdulos de la plataforma MC13213 de Freescale que estn relacionados con el proyecto, y se explicarn las decisiones de diseo concluidas.

Ms tarde se presentar la discusin mantenida respecto al formato ptimo (dadas las especificaciones de funcionamiento y las restricciones materiales) para el almacenamiento de las imgenes de firmware en la memoria auxiliar del ND07 y las conclusiones acordadas.

Finalizados todos los anlisis se proceder explicar la estructura de la aplicacin del bootloader, desarrollando cada uno de los mdulos que la componen, el proceso de validacin aplicado y las decisiones de diseo tomadas.

Dado que el bootloader se program originalmente en C, y que ms tarde se comprob que para garantizar siempre su correcto funcionamiento era necesario reprogramarlo todo en ensamblador, los siguientes subapartados desarrollarn los elementos implicados (opciones del compilador, ensamblador, etc.) y el procedimiento seguido para realizar dicha traduccin.

Las decisiones tomadas acerca del emplazamiento ptimo del bootloader en memoria (RAM y Flash) y dentro de la secuencia de arranque cerrarn la seccin de la memoria relativa al diseo de esta aplicacin, objetivo principal del proyecto.

Puesto que el bootloader es independiente del modo de transmisin del nuevo firmware hasta el dispositivo a actualizar, el resto del captulo se dedicar a explicar el desarrollo de una aplicacin auxiliar (Cargador Serie RS232), que har uso de l con el fin de evaluar y optimizar su funcionamiento. Esta aplicacin permitir pues actualizar el firmware de dispositivos mediante imgenes enviadas a travs de una comunicacin serie RS232, empleando el bootloader para ello.

Captulo 5: Validacin del Sistema

En el captulo 5 se presentarn en primer lugar los tres mtodos empleados para depurar y validar tanto la aplicacin del bootloader como la aplicacin del cargador RS232. Estos mtodos se aplicaron a lo largo de todo el proceso de desarrollo.

20

En ltimo lugar se presentar el escenario propuesto para la validacin del sistema completo, junto con la descripcin del funcionamiento de dicho sistema obtenido en laboratorio.

Captulo 6: Conclusiones y Trabajos Futuros

En el captulo 6 se analizarn las conclusiones obtenidas fruto del desarrollo del proyecto y se plantearn las posibles lneas de trabajo futuro que podran surgir a partir de los resultados alcanzados.

Apndices

Los apndices incluirn las instrucciones y recomendaciones de instalacin del bootloader (una de las principales conclusiones de la memoria), el presupuesto requerido para realizar el proyecto y la bibliografa y referencias empleadas.

21

1.4.

Medios Materiales para la Ejecucin del Proyecto

La elaboracin de este proyecto ha requerido de una serie de elementos hardware y software imprescindibles para alcanzar los objetivos impuestos. La justificacin de la eleccin de la mayor parte de estos elementos (tecnologa, hardware y empresas implicadas) vendr dada en posteriores captulos.

Podemos distinguir pues los siguientes componentes fsicos (hardware):

PC (Pentium 1GHz) con 512 MB RAM y 600MB de espacio en disco duro y puerto serie Kit de Desarrollo de Freescale para el chip MC1321x Dispositivo ZigBee con puerto serie RS232: NLaza NDimension ND07 Adaptador de grabacin para que el USB MultiLink de Freescale (incluido dentro del Kit de desarrollo) sea compatible con el ND07 (programador/depurador NLaza-Freescale) Dispositivo sniffer para la captura de tramas ZigBee: Daintree Sensor Network Adapter Fuente de alimentacin regulable (para alimentar el ND07 durante los procesos de depuracin y programacin del dispositivo)

Las especificaciones del listado de dispositivos anterior las han dictado fundamentalmente los requisitos mnimos necesarios para el correcto funcionamiento de las aplicaciones implicadas en el desarrollo del bootloader.

As pues enumeramos las aplicaciones (software) que han sido necesarias: Sistema Operativo Microsoft Windows XP Entorno de Desarrollo (IDE): CodeWarrior for Microcontrollers (RS08/HC(S)08/ColdFire V1) con una licencia estndar Servidor de licencias flotantes FlexLm v8.4. (incluido con el CodeWarrior) Software Analizador de Protocolos (captura de tramas radio) Daintree Sensor Network Analyzer (SNA) con una licencia estndar Software BeeKit Wireless Connectivity Toolkit con una licencia estndar Pila 802.15.4 y ZigBee: BeeStack 1.0.5. (incluidos en el BeeKit) WinMerge 2.0.2 [20] Software libre para comparacin de ficheros en Windows XP RealTerm [Link] [21] Terminal serie (software libre) ms potente que el HyperTerminal de Windows XP (versin por defecto)

Una vez elegida la tecnologa inalmbrica (ZigBee), el fabricante de chips (Freescale) y el microprocesador/microcontrolador sobre el que se programar la aplicacin del bootloader (plataforma MC13213), la mayor parte del software necesario para el desarrollo queda inevitablemente definido. As pues, alrededor de la fechas en que se comenz este estudio

22

(finales del 2006), Freescale suministraba el IDE CodeWarrior for Microcontrollers (que inclua el compilador necesario para el chip MC13213) junto con el servidor de licencias flotantes FlexLm dentro de su kit de desarrollo.

Contemporneamente a la compra del kit de desarrollo del MC13213, se adquiri el analizador de redes (SNA) de la compaa Daintree Network. Esto se debi a que Freescale recomendaba sus herramientas, asegurando compatibilidad con sus chips, y existan pocas o ninguna opcin adicional.

El BeeKit suministrado por Freescale es una herramienta diseada para el desarrollo rpido y configuracin de aplicaciones de ejemplo basadas en las pilas 802.15.4 y ZigBee, que han sido necesarias para la programacin del bootloader y el cargador RS232. As pues fue necesaria su adquisicin tambin.

La eleccin de la empresa NLaza Soluciones como suministradora del hardware definitivo fue debida a que en 2006 se planteaba como una de las pocas empresas espaolas desarrolladoras de dispositivos ZigBee y por entonces la nica que trabajaba con Freescale. La eleccin del ND07 de entre su lnea de productos fue debido a que era un dispositivo sencillo, con conexin serie RS232, y dispona de una memoria auxiliar EEPROM que permitiran el fcil desarrollo y testeo del bootloader (y de las aplicaciones auxiliares).

Finalmente, la eleccin de Windows como sistema operativo fue debida principalmente a la sencillez que ofreca la configuracin de las aplicaciones funcionando sobre Windows frente a la complejidad que presentaban las mismas sobre otras plataformas como Linux (sobre las que tambin funcionaban las aplicaciones FlexLm y CodeWarrior). Adicionalmente, por entonces exista ms documentacin y ms herramientas para la depuracin de cdigo sobre Windows.

23

Captulo 2 Estado del Arte

24

2.1.

Introduccin a las Redes de Sensores Inalmbricas

recientes avances en sistemas microelectromecnicos, miniprocesadores y

Los

tecnologas de transmisin inalmbrica de baja potencia en han permitido el desarrollo de una gran variedad de sensores de bajo coste, bajo consumo y reducido tamao que son capaces de observar y reaccionar ante cambios de determinadas variables del entorno.

Cuando estos dispositivos se empleen de forma conjunta, colaborando y comunicndose de forma inalmbrica, se podrn obtener resultados con un mayor valor aadido, formando lo que se conoce como Redes de Sensores Inalmbricas (WSN).

Los sensores inalmbricos estn equipados con un transceptor radio y una serie de transductores a travs de los cuales obtienen informacin sobre el entorno que los rodea.

Cuando se despliegan en gran cantidad dentro de un escenario determinado, se organizarn automticamente y configurarn una red ad hoc multisalto que les permitir comunicarse entre ellos y con uno o ms nodos sumidero (sinks). Estos sumideros permitirn a un usuario remoto la recoleccin de las medidas recibidas de los sensores de la red y la introduccin de comandos destinados a stos.

La aplicacin auxiliar del cargador RS232 desarrollada en este proyecto (se explicar ms adelante en la memoria), actuar como uno de estos nodos sumideros funcionando dentro una red de sensores ZigBee.

Las aplicaciones de esta tecnologa son numerosas y pertenecen a campos muy diversos como pueden ser la medicina (monitorizacin de constantes vitales y envo de alarmas en caso de problemas), la agricultura (medicin de condiciones climatolgicas y control de cultivos), el medioambiente (medicin de polucin, deteccin y prevencin de incendios e inundaciones, etc.), el control de inventarios, la deteccin de intrusos, la localizacin y seguimiento de personas, las aplicaciones militares, el control y monitorizacin de estructuras o maquinaria (puentes, aviones, etc.), juguetes y perifricos de PC, y un largusimo etctera [22] [23].

Existen dos campos de aplicacin especialmente relevantes como son la automatizacin del hogar (domtica) y la gestin y medicin remotas del consumo energtico. Esto se debe principalmente a las optimistas estimaciones realizadas acerca de la relevancia que tendrn en el futuro las redes de sensores inalmbricas en dichos sectores. Para ambos campos de aplicacin existe, en la actualidad, una considerable variedad de sensores disponibles en el mercado.

25

Sin embargo, los escenarios de aplicacin de las redes de sensores suelen ser considerablemente complejos, debido principalmente a los problemas que arroja la coexistencia una alta densidad de dispositivos en un mismo rea reducida, la alta latencia de las comunicaciones (los dispositivos entrarn en letargo habitualmente para ahorrar bateras), el reducido ancho de banda y las interferencias con otras tecnologas.

A estos inconvenientes habr que sumarle las limitaciones impuestas por los dispositivos que integrarn habitualmente este tipo de redes, que presentarn un coste, tamao y consumo reducidos, pero tambin una baja capacidad de cmputo y almacenamiento (memoria).

Es debido a todo esto que a lo largo de los ltimos aos han ido surgiendo tecnologas de redes de sensores muy diferentes y se hace cada vez ms necesario el proceso de estandarizacin de los diversos protocolos de comunicacin.

As pues, se pueden distinguir principalmente dos tipos de tecnologas: las propietarias y las pblicas. Mientras que el primer tipo pueden ser soluciones sencillas y robustas, tienen el grave inconveniente de ser difcilmente escalables y de forzar al cliente a permanecer con un nico fabricante, con las limitaciones que eso supone. Por el contrario, las soluciones pblicas permitirn la creacin de redes heterogneas muy escalables, ya que los distintos fabricantes crearn soluciones diferentes basadas en el mismo protocolo de comunicaciones acordado.

De este modo, actualmente se pueden encontrar en el mercado diversas tecnologas WSN propietarias como: Z-Wave, EnOcean, ANT, Wibree (ahora Bluetooth ULP), MiWi, etc.

Las principales diferencias entre ellas se pueden observar en la siguiente tabla:

Protocolo Alcance Z-Wave 1 100m 868.42 (Europa) Banda de Frecuencias 908.42 MHz (USA) Tasa de Transferencia Modulacin Tamao de Pila de Protocolo 9.6 Kbps o 40 Kbps GFSK 16 KB 26 KB EnOcean 100 - 300 m 868.3 MHz o 315 MHz 125 Kbps (no mantenido) ASK < 32 KB 1 Mbps GFSK 2 KB 1 Mbps GFSK 90 KB 250 Kbps O-QPSK 3 KB 17 KB 2.4 GHz 2,4 GHz 2,4 GHz ANT 1 30 m Bluetooth ULP 1 - 10 m MiWi 1 100 m

Caractersticas generales de las tecnologas WSN propietarias

Aunque a primera vista unas tecnologas parecen claramente mejores que otras en realidad cada una tiene su propio campo de aplicacin. Por lo general, un mayor alcance y velocidades de transmisin suele implicar un mayor consumo (pero por ejemplo EnOcean ni siquiera

26

requiere bateras). Por otro lado, cuanta menos memoria requiera la pila de protocolos, sta ofrecer unas peores prestaciones (nmero mximo de nodos en red menor, incapacidad de formar redes malladas, etctera) pero emplear probablemente chips ms baratos.

Desafortunadamente, aunque muchas de estas tecnologas son muy eficientes, su campo de aplicacin es muy reducido (por ejemplo Z-Wave se ha diseado especficamente para automatizacin del hogar y Bluetooth ULP para redes muy pequeas no malladas) y lo que ms grave: no otorgan interoperabilidad entre dispositivos de diferentes fabricantes al tratarse de protocolos propietarios (a excepcin de MiWi, cuyo protocolo es abierto pero requiere del uso de transceptores de MicroChip).

Es por ello que si se desea disponer de una solucin interoperable y escalable, es imprescindible elegir una tecnologa abierta. Esta es la razn de la importancia de las entidades de estandarizacin (IEEE por ejemplo) y las alianzas de empresas del sector, como la ZigBee Alliance [9].

De este modo, se dispone tambin de un nmero considerable de tecnologas abiertas basadas en especificaciones o estndares como: ZigBee, Wi-Fi, Bluetooth, Wireless USB, etc.
Estndar Alcance ZigBee 1 100 m 868.42 (Europa) Banda de Frecuencias 908.42 MHz (USA) 2.4 GHz (Global) 20 Kbps (Europa) Tasa de Transferencia 40 Kbps (USA) 250 Kbps (Global) Modulacin Tamao de Pila de Protocolo O-QPSK 40 KB 100 KB OFDM 1000 KB OFDM 1000 KB MB-OFDM 11 54 Mbps 11 54 Mbps 53 - 480 Mbps 2.4 GHz 2.4 GHz 3.1 GHz 10.6 GHz Wi-Fi (802.11 b y g) 1 250 m Wi-Fi (802.11 b y g) 1 250 m Wireless USB 1 10 m

Caractersticas generales de algunas tecnologas WSN pblicas Una vez ms cada una de las tecnologas ha sido diseada con un diferente objetivo en mente, sin embargo su penetracin en el mercado ser mayor al permitir a cualquier fabricante desarrollar productos interoperables cindose a una determinada especificacin o estndar.

De entre todos ellos, resulta especialmente interesante la especificacin ZigBee, basada en el estndar pblico IEEE 802.15.4 y la alianza de compaas ZigBee Alliance [9] capaz de generar redes malladas muy seguras de hasta 65000 nodos, empleando dispositivos de muy bajo coste y consumo. ZigBee ser pues la tecnologa escogida para el desarrollo de este proyecto y se estudiar en profundidad en el apartado 2.3.

27

2.2.

El estndar IEEE 802.15.4

2.2.1. Introduccin y Aspectos Generales

El IEEE 802.15.4
[1] [2] [3]

es un estndar pblico del organismo internacional IEEE que

definir los niveles fsico (PHY) y de acceso al medio (MAC) para las comunicaciones realizadas dentro de las redes inalmbricas personales de baja tasa de transmisin (LRWPANs).

Este tipo de redes se emplea habitualmente para el intercambio de informacin en distancias relativamente cortas, requiriendo para ello de muy poca o ninguna infraestructura, lo cual posibilita el desarrollo de soluciones baratas, de tamao reducido y muy eficientes en trminos de consumo.

De este modo, el estndar se ha diseado para proveer de conectividad inalmbrica (robusta, flexible y segura) a dispositivos mviles o fijos, de baja potencia y muy reducido consumo (alimentados habitualmente mediante bateras) y alcance limitado. No obstante, dependiendo de la aplicacin y el tipo de dispositivo el estndar permitir disponer de mayor cobertura a costa de una menor tasa de transferencia. Las principales caractersticas del estndar sern pues:

1. Flujos binarios inalmbricos de 20 Kbps, 40 Kbps, 110 Kbps, 250 Kbps o 851 Kbps dependiendo del rango de frecuencias que se emplee. 2. Topologas de red en estrella o peer-to-peer. 3. Empleo de direcciones cortas (16 bits) o extendidas (64 bits). 4. Acceso al canal compartido mediante algoritmos de contienda (CSMA-CA o ALOHA, este ltimo slo para UWB), o libres de contienda mediante asignacin de slots de tiempo (GTSs). 5. Soporte de asentimientos de tramas para mayor robustez de las comunicaciones. 6. Bajo consumo de energa. 7. Capacidad de detectar el nivel de energa (ED) y calidad del enlace de los canales (LQI). 8. Disponibilidad de 16 canales en la banda de 2450 MHz, 30 en la banda de 915MHz y 3 en la banda de 868MHz empleando tcnicas de espectro ensanchado de secuencia directa (DSSS) y secuencia paralela (PSSS). Adicionalmente tambin se dispondr de 14 canales de espectro ensanchado de chirps solapados (CSS) en la banda de 2,4GHz y 16 canales UWB (con sus frecuencias centrales en 500MHz y de 3,1 GHz hasta 10,6 GHz).

28

El estndar definir dos tipos de dispositivos:

1. Dispositivos de Funcionalidad Completa (Full Function Device, FFD) 2. Dispositivos de Funcionalidad Reducida (Reduced Function Device, RFD)

Los cuales difieren en su uso y en la cantidad del estndar que implementan, ocupando as ms o menos memoria segn la aplicacin deseada.

Un FFD puede funcionar como coordinador de la PAN (Personal Area Network), como coordinador (haciendo las veces de router) o como dispositivo final. As mismo pueden comunicarse con cualquiera de estos tres tipos de dispositivos. Normalmente sern dispositivos dotados de ms memoria, de mayor capacidad de cmputo o incluso de bateras de mayor tamao (para una mayor autonoma).

Un RFD en cambio suele ser un dispositivo ms simple, con menor capacidad para realizar tareas complejas o de larga duracin. Habitualmente desempearn aplicaciones sencillas que consuman poca energa ya que tpicamente estarn dotados de recursos escasos en trminos de capacidad de cmputo o memoria disponible. Los RFDs slo podrn comunicarse con un FFD, no pudindolo hacer con otros RFD, por lo que se comportarn siempre como dispositivos finales dentro de una red.
[1]

El estndar IEEE 802.15.4 fue publicado por primera vez en octubre del ao 2003

y ha sido
[2]

revisado en dos ocasiones. La primera revisin, realizada en septiembre del ao 2006

, dio

lugar a una nueva versin del estndar. En cambio, la siguiente revisin efectuada en agosto del ao 2007 [3] se limit a corregir y completar algunos aspectos de la ltima versin publicada (incluyendo principalmente nuevos canales y tcnicas de espectro ensanchado en el nivel fsico). En este captulo se describirn las tres versiones simultneamente.

2.2.2. Topologas de Red

Dependiendo de los requisitos de cada aplicacin, una red IEEE 802.15.4 puede implementar una de las siguientes topologas: topologa en estrella y topologa peer-to-peer.

Un requisito fundamental de ambas topologas ser que todos los dispositivos de la red debern disponer de una direccin extendida de 64 bits (nica y de fbrica) que les permitir identificarse de forma unvoca.

29

Adicionalmente todos los dispositivos obtendrn una direccin corta (de 16 bits) en el momento de la asociacin a la red, que les permitir realizar comunicaciones de forma ms eficiente que empleando la direccin de 64 bits.

La siguiente figura ilustra la forma de las dos topologas de red mencionadas:

Topologas de una red 802.15.4 [2] Cada PAN (Personal Area Network) individual dispondr de un identificador nico que permitir a los dispositivos comunicarse dentro de la red o entre redes independientes (empleando para ello el identificador de la PAN en conjuncin con sus direcciones corta o larga).

El mecanismo mediante el cual se eligen los identificadores (direcciones cortas y de PAN) queda fuera de las especificaciones del estndar 802.15.4. De igual forma, la definicin del proceso de formacin de redes en forma de estrella o peer-to-peer tendr lugar en la especificacin de la capa de red (fuera de este estndar), no obstante se introducir brevemente dicho proceso a continuacin.

[Link].

Topologa en estrella

En la topologa de estrella, las comunicaciones se establecern nicamente entre los dispositivos y un nico controlador central llamado coordinador de la PAN (PAN Coordinator), que ser el encargado de asignar las direcciones cortas de los dispositivos en el momento de su asociacin a la red.

Habitualmente, cada dispositivo de la red dispondr de una aplicacin asociada determinada y ser la fuente o el sumidero de diversas comunicaciones. Sin embargo, el coordinador de la PAN ser adicionalmente el controlador principal de la red y ser tambin capaz de iniciarla, terminarla o encaminar paquetes a travs de ella.

30

Debido a estas responsabilidades aadidas, ser habitual que el coordinador de la PAN disponga de ms memoria y capacidad de proceso, adems de alimentacin va red elctrica mientras que la mayora del resto de dispositivos de la red emplearn bateras.

Las redes en estrella suelen establecerse cuando un FFD se enciende por primera vez y trata de convertirse en el coordinador PAN de su propia red.

Para ello escoger un identificador de PAN que no est empleando ninguna red vecina, generar la nueva estrella y a continuacin permitir a otros dispositivos (RFDs o FFDs) asociarse a ella.

Las aplicaciones tpicas de este tipo de topologa son: automatizacin del hogar, perifricos de PC, juegos, juguetes y aplicaciones del cuidado personal de la salud.

[Link].

Topologa peer-to-peer

En una red con la topologa peer-to-peer cualquier dispositivo podr comunicarse con cualquier otro siempre que est en su rango de cobertura y que no se trate de dos RFD.

Este tipo de redes tambin dispondrn de un nico coordinador de la PAN, que habitualmente ser el primer dispositivo FFD en iniciar una comunicacin sobre el canal.

En esta ocasin los dispositivos se asociarn a la red a travs de cualquier FFD dentro de su rango de cobertura (no necesariamente el coordinador de la PAN), de modo que la asignacin de la direccin corta puede no depende necesariamente de un nico nodo central.

Esta topologa permite crear redes mucho ms complejas que la topologa en estrella, posibilitando por ejemplo la creacin de redes malladas (mesh), en las que cada dispositivo de la red puede comunicarse con todos los dems o la creacin de redes cluster tree, en la que extiende la cobertura al desplegar muchos FFD actuando como coordinadores y algunos RFD actuando como dispositivos finales.

Este tipo de redes pueden ser ad hoc, auto organizativas y auto regenerativas. Adicionalmente permitirn encaminar paquetes a travs de mltiples saltos entre dos dispositivos alejados dentro de la red (aunque esto depender del nivel de red elegido).

Las aplicaciones tpicas de este tipo de topologa sern: control y monitorizacin industrial, redes de sensores inalmbricos, gestin de inventarios, agricultura inteligente y seguridad.

31

2.2.3. Arquitectura de Red

La arquitectura del IEEE 802.15.4 se define en funcin de una serie de bloques destinados a simplificar el estndar, denominados capas o niveles. Cada nivel es responsable de una parte del estndar y ofrece unos determinados servicios a las capas superiores. El diseo de los diferentes niveles est basado en el modelo OSI de siete capas.

Una LR-WPAN se compone de los niveles fsico (PHY) y de acceso al medio (MAC). Ambas capas dispondrn de diversos puntos de acceso (SAP) que actuarn de interfaz entre los diferentes niveles y permitirn definir los enlaces lgicos que se describirn a lo largo del estndar. La figura siguiente mostrar pues la arquitectura descrita:

Arquitectura de un dispositivo LR-WPAN El nivel PHY involucrar al transmisor-receptor de radiofrecuencia junto a los mecanismos de bajo nivel que lo controlan. Proveer de dos servicios: el servicio de datos (PD), que permite la transmisin y recepcin de unidades de datos (PPDUs), y el servicio de gestin, que actuar de interfaz entre la MAC y la entidad de gestin de la capa fsica (PLME)).

El nivel MAC proporcionar acceso al canal fsico para cualquier tipo de transferencia de informacin. De nuevo, pueden distinguirse dos servicios: el servicio de datos, que permite la transmisin y recepcin de MPDUs (MAC Protocol Data Units) y el servicio de gestin (MLME).

Las capas superiores representadas en la figura anterior se refieren a una capa de red (que proporcionar las funcionalidades de configuracin de red y manipulacin y encaminamiento de mensajes), y a una capa de aplicacin (que soportar la funcionalidad buscada para el dispositivo). Dichas capas superiores se encuentran fuera del alcance del estndar 802.15.4 y, a efectos de este proyecto, las definir la especificacin ZigBee (que se describir en el apartado 2.3).

32

2.2.4. Nivel Fsico (Capa PHY)

El nivel fsico (PHY) corresponder al nivel ms bajo de la arquitectura de protocolos definida en el estndar IEEE 802.15.4, y se encargara de controlar directamente la transmisin de los datos por el medio. Esta capa ser pues la responsable de:

1. Activar/desactivar el transceptor de radio. 2. Realizar la deteccin de energa (ED) dentro del canal seleccionado. 3. Dar una indicacin de calidad del enlace (LQI) a partir de los paquetes recibidos. 4. Evaluar la disponibilidad del canal (CCA) para CSMA-CA. 5. Seleccionar la frecuencia de canal. 6. Gestionar la transmisin y recepcin de datos por el canal.

A continuacin se resumirn sus caractersticas ms importantes.

[Link].

Bandas de Frecuencia y Consideraciones Generales

Los canales de una LR-WPAN se situarn en las siguientes bandas de frecuencia sin licencia:

868 868.6 Mhz (Europa) 902 928 Mhz (EEUU) 2400 2483.5 (Mundial) 3100 10600 (variable dependiendo del pas)

Podemos resumir las caractersticas de las diferentes PHY en la siguiente tabla:

PHY 868/915 868/915 868/915 (opc) 868/915 (opc) 868/915 (opc) 868/915 (opc) 2450 DSSS UWB sg (opc) 2450 CSS (opc) 2450 CSS (opc)

Banda (Mhz) 868-868.6 902-928 868-868.6 902-928 868-868.6 902-928 2400 -2483.5 250-750 2400-2483.5 2400-2483.5

Tasa chip (Kchip/s) 300 600 400 1600 400 1000 2000

Modulacin BPSK BPSK ASK ASK O-QPSK O-QPSK O-QPSK

Tasa bit (Kb/s) 20 40 250 250 100 250 250

Tasa Smbolo (Ksymbol/s) 20 40 12.5 50 62.5 62.5 62.5

Smbolos binario binario 20 bit PSSS 5 bit PSSS 16-ario ort. 16-ario ort. 16-ario ort.

DQPSK DQPSK

250 1000

166.667 166.667

8-ario ort. 64-ario ort.

33

UWB bb (opc) UWB ba (opc)

3244 4742 5944 -10234

Bandas de frecuencia y tasas de bit de la capa PHY

Como puede apreciarse en la tabla, las bandas de 868/915 MHz con modulaciones BPSK y OQPSK emplearn espectro ensanchado DSSS mientras que aquellas con modulacin ASK, emplearn espectro ensanchado por secuencia paralela (PSSS).

La revisin del estndar del 2007 incorpor dos nuevas configuraciones posibles al nivel fsico (que correspondern a las 5 ltimas entradas de la tabla).

La primera de ellas consistir en emplear tcnicas de espectro ensanchado por chirps (CSS) en la banda de 2450 MHz, junto con una modulacin DQPSK de constelaciones 8-arias o 64arias. La segunda configuracin implicar emplear una versin de espectro ensanchado UWB (Ultra Wideband) sobre nuevas bandas de frecuencia.

Ambas configuraciones presentarn la ventaja de que proporcionarn resistencia adicional a los desvanecimientos multitrayecto que tienen lugar con bajas potencias de transmisin. De este modo, como ya se indic con anterioridad, el nivel fsico definir las transmisiones inalmbricas para 16 canales en la banda de 2450 MHz, 30 en la banda de 915 MHz y 3 en la banda de 868 MHz, empleando tcnicas de espectro ensanchado de secuencia directa (DSSS) y secuencia paralela (PSSS). Adicionalmente tambin definir 14 canales de espectro ensanchado de chirps solapados (CSS) en la banda de 2,4GHz y 16 canales UWB (con sus frecuencias centrales en 500MHz y de 3,1 GHz hasta 10,6 GHz).

En cuanto a consideraciones de sensibilidad se refiere, un dispositivo conforme al estndar funcionando en las bandas de 868 o 915 MHz empleando una modulacin BPSK requerir de una sensibilidad mnima de -92 dBm, mientras que si se emplean modulaciones O-QPSK o ASK dicha sensibilidad mnima ser de -85 dBm.

La sensibilidad mnima requerida en la banda de 2,4GHz ser de -85 dBm si se emplean tcnicas de espectro ensanchado DSSS o CSS a una tasa de bit de 1 Mbps. Si se emplea en cambio CSS con una tasa de 250 Kbps, ser necesaria una sensibilidad mnima de -91 dBm.

En cuanto a potencia se refiere, un dispositivo transmisor funcionando bajo las especificaciones del 802.15.4 deber ser capaz de transmitir -3 dBm de potencia y de recibir al menos un mximo de -20 dBm de seal deseada. Sin embargo, los mximos de potencia transmitibles en un canal concreto dependern de la legislacin de cada regin.

34

[Link].

Formato de trama

La estructura de la trama PPDU (PHY Protocol Data Unit), dependiendo de la banda de frecuencias y la tcnica de espectro ensanchado elegida, se presentar en las siguientes figuras:

Formato de la trama PPDU (excepto para UWB y CSS)

Formato de la trama PPDU (para UWB)

Formato de la trama PPDU (para CSS) De este modo, una trama PPDU se compone de los siguientes bloques: SHR (Synchronization Header): cabecera que permitir al dispositivo sincronizarse para una correcta diferenciacin de los distintos bits del mensaje. PHR (PHY Header): cabecera real del mensaje que contendr informacin sobre la longitud de la trama transmitida. En el caso de UWB, tambin incluir informacin acerca de la tasa, el ranking y el prembulo. Datos: campo de longitud variable que transportar la trama del subnivel MAC.

Dentro de la SHR, el campo prembulo se emplear por el transmisor-receptor para sincronizarse a nivel de chip y a nivel de smbolo con el mensaje entrante. El campo SFD (Start of Frame Delimiter) ser el delimitador de inicio de trama e indicar dnde acaba el prembulo y donde comienza la cabecera de la trama en s. Ambos campos presentarn un formato diferente en funcin del nivel fsico empleado.

Dentro de la PHR, el campo de longitud de trama servir principalmente para indicar la longitud exacta de los datos que vienen a continuacin, que puede ser variable.

Finalmente, el campo de datos transportar la trama de nivel superior (MAC).

35

[Link].

Servicios del nivel fsico

El nivel fsico provee de dos servicios hacia la capa superior (la MAC): el servicio de datos (PD), que permitir la transmisin y recepcin PPDUs, y el servicio de gestin (PLME).

Estos dos servicios se gestionarn a travs de un conjunto de primitivas. Para el caso del servicio de datos se dispone de las siguientes:

Primitiva PD-DATA

Tipo 1 Request

Tipo 2 Confirm

Tipo 3 Indication

Primitivas del servicio de datos capa PHY

Estas tres primitivas PD-DATA se encargarn de solicitar el envo de datos por el canal (.request), confirmar el envo o error de estos datos a la capa MAC (.confirm) y de indicar a la capa MAC del dispositivo receptor de la llegada de stos (.indication).

Para el caso del servicio de gestin se dispondr de las siguientes primitivas:

Primitiva PLME-CCA PLME-ED PLME-GET PLME-SET-TRX-STATE PLME-SET PLME-DPS PLME-SOUNDING PLME-CALIBRATE

Tipo 1 Request Request Request Request Request Request Request Request

Tipo 2 Confirm Confirm Confirm Confirm Confirm Confirm Confirm Confirm

Tipo 3 -----Indication ---

Primitivas del servicio de gestin capa PHY

Las primitivas PLME-CCA se encargarn de solicitar una evaluacin de la disponibilidad del canal para enviar datos (.request) y devolvern los resultados de esta evaluacin a la capa MAC (.confirm).

Las primitivas PLME-ED solicitarn (.request) la deteccin de energa de un canal y devolvern esta informacin a la capa superior (.confirm).

Las primitivas PLME-GET y PLME-SET solicitarn (.request) el envo a la capa superior del valor de una variable de entorno de la capa fsica (GET) o cambiarn su valor al especificado por la MAC (SET). El resultado de estas operaciones se reportar a la capa MAC por la primitiva de confirmacin (.confirm) que corresponda.

36

Las primitivas PLME-SET-TRX-STATE se encargarn de solicitar (.request) a la capa fsica que cambie el estado de operacin del transceptor de radio a una de las tres posibles situaciones: Transceptor apagado (TRX_OFF, con el menor consumo de potencia), Transmisor encendido (TX_ON) o Receptor encendido (RX_ON). El resultado de esta operacin se comunicar a la capa superior a travs de la primitiva de confirmacin (.confirm).

Las primitivas PLME-DPS, PLME-SOUNDING y PLME-CALIBRATE son opcionales y slo se emplearn en UWB en procesos de medicin de distancia (ranging).

Cada una de estas primitivas tendr una serie de parmetros que la capa superior ajustar segn los parmetros de la primitiva de nivel superior que reciba. Puesto que el fabricante del chip elegido suministrar las libreras precompiladas de todo el nivel fsico, no ser necesario profundizar ms en estas primitivas para el desarrollo del proyecto.

2.2.5. Nivel de Acceso al Medio (Capa MAC)

Esta capa de la arquitectura gestiona todos los accesos al canal radio fsico y es responsable de:

1. Generar balizas (beacons) si el dispositivo es un coordinador 2. Sincronizarse a las balizas 3. Soportar asociacin y desasociacin con la PAN 4. Soportar seguridad 5. Gestionar el uso de los mecanismos de acceso al medio con contienda ( CSMACA o ALOHA en el caso de disponer de una PHY de UWB) y libres de contienda 6. Gestin y mantenimiento del mecanismo de GTS 7. Proveer de un canal fiable entre dos entidades MAC extremo a extremo

A continuacin se describirn los puntos ms importantes del funcionamiento de esta capa.

[Link].

Mecanismos de Control de Acceso al Medio

El estndar 802.15.4 permite la utilizacin de una estructura de supertrama que define el coordinador de la PAN para el acceso al medio compartido.

Las supertramas estn delimitadas por el envo de balizas (beacons) y pueden tener una regin activa y una regin inactiva. Durante la regin activa el coordinador fijar segn sus necesidades otras dos regiones: regin de acceso por contienda (Contention Access Period,

37

CAP) y regin libre de contienda (Contention Free Period, CFP). Durante la regin inactiva se prohibir el envo de tramas y el coordinador de la PAN podr entrar en bajo consumo o dedicarse a tareas de gestin.

En la CAP los dispositivos accedern al medio mediante contienda por medio de CSMA-CA ranurado mientras que en la CFP (si existe esta regin, puesto que es configurable) se crean canales virtuales en las que el coordinador concede acceso al medio slo a un dispositivo. Estos canales se conocen como GTS (Guaranteed Time Slot) y la informacin acerca de su tamao y dispositivo asociado se enviar en cada baliza.

De utilizarse supertramas, el coordinador dividir la zona activa de cada una en 16 ranuras (slots) iguales de tiempo y transmitir una baliza (beacon frame) en el primer slot de forma que todos los dispositivos asociados a ese coordinador la escucharn y se sincronizarn a sta tal como aparece en la figura siguiente:

Estructura de una supertrama La utilizacin de balizas (y as estructura de supertramas) es opcional y depender de los objetivos de diseo a optimizar tipo de red a implementar. As mismo, en el caso de utilizar supertramas, la utilizacin de slots GTS tambin es una opcin de diseo.

El nivel MAC necesita un tiempo determinado para procesar los datos que le llegan del nivel fsico. Por lo tanto, las tramas enviadas desde un dispositivo deben estar separadas al menos un periodo de tiempo llamado IFS. Si una primera transmisin exige un asentimiento, la separacin temporal entre dicho asentimiento y la segunda transmisin deber ser tambin de al menos un periodo IFS.

La duracin de este periodo IFS depender del tamao de la trama recibida, distinguindose as un periodo corto (SIFS, asociado a tramas recibidas cortas) y otro largo (LIFS, asociado a tramas recibidas largas).

Si se prescinde de balizas, los dispositivos enviarn datos al coordinador mediante CSMA-CA no ranurado y ste responder opcionalmente con tramas de asentimiento (ACK). El envo de datos desde un coordinador a un dispositivo final (RFD) se realizar mediante CSMA-CA no

38

ranurado de forma indirecta: el dispositivo solicitar datos al coordinador, ste asentir esta solicitud y enviar los datos y, finalmente, el dispositivo asentir el envo.

Si se trabaja con balizas (y por tanto supertramas), el envo de datos por parte del dispositivo final al coordinador se realizar de la misma forma que en un entorno sin balizas con la diferencia de que el dispositivo se sincronizar primero con el coordinador y enviar los datos mediante CSMA-CA ranurado durante la CAP. El envo de datos desde el coordinador hacia el dispositivo final asociado ser exactamente igual que sin balizas con la diferencia de que el dispositivo sabr si hay mensajes pendientes para l al sincronizarse y leer las balizas.

En las ocasiones en que se emplee CSMA-CA no ranurado, el dispositivo que desee enviar deber esperar primero un tiempo aleatorio. Una vez haya expirado, se evaluar si el canal est libre realizando un CCA (Clear Channel Assesment), en cuyo caso la transmisin se realizar inmediatamente.

En caso contrario, el dispositivo deber volver a esperar otra cantidad de tiempo aleatorio antes de realizar el siguiente intento. Transcurrido un nmero mximo de intentos sin xito, se dar por finalizado el proceso y se considerar que ha habido un fallo en la transmisin.

El funcionamiento del CSMA-CA ranurado es muy similar a la versin no ranurada, con la salvedad de que en lugar de esperar periodos de tiempo aleatorios, ser necesario esperar un nmero de slots aleatorio.

[Link].

Modelos de Transferencia de datos

El estndar IEEE 802.15.4 contempla tres escenarios distintos de intercambio de datos:

Transmisin de datos de un coordinador a un dispositivo. Transmisin de datos de un dispositivo a un coordinador. Transmisin de datos entre dos dispositivos iguales (peers)

A continuacin, se describir resumidamente el funcionamiento de cada uno, diferenciando los casos de redes con y sin balizas.

Transmisin de datos de un coordinador a un dispositivo

En este escenario suele ser habitual que el dispositivo destino de la transmisin se encuentre en letargo (para ahorrar bateras), de forma que el coordinador no podr enviarle los datos directamente y tendr que almacenarlos hasta que el dispositivo los solicite.

39

Si este escenario tiene lugar en una red con balizas, el dispositivo estar sincronizado con stas y saldr peridicamente de su letargo para escucharlas.

De este modo, el coordinador anunciar en cada baliza un listado de los dispositivos para los que dispone datos almacenados y stos procedern a solicitarlos mediante la emisin de un comando MAC de peticin de datos, empleando CSMA-CA ranurado.

Esta trama de peticin de datos se asentir opcionalmente por el coordinador y a continuacin proceder a transmitir los datos solicitados mediante CSMA-CA ranurado al dispositivo destino que, opcionalmente, tambin asentir su recepcin.

Todo el proceso descrito se ilustra en el caso (a) de la figura siguiente:

Escenarios de envo de datos de un coordinador a un dispositivo Si la transmisin tiene lugar en una red sin balizas, el dispositivo deber solicitar peridicamente datos del coordinador mediante la emisin de tramas MAC de peticin de datos, empleando CSMA-CA no ranurado.

El coordinador asentir opcionalmente dichas peticiones de datos y, en el caso de disponer de datos almacenados destinados al dispositivo en cuestin, proceder a transmitirlos mediante CSMA-CA no ranurado. El dispositivo receptor asentir los datos opcionalmente.

En el caso de no disponer de datos almacenados destinados al dispositivo solicitante, el coordinador lo indicar en el asentimiento de la solicitud o mediante el envo de una trama vaca.

El proceso descrito para una red sin balizas se ilustra en el caso (b) de la figura anterior.

40

Transmisin de datos de dispositivo a un coordinador En este escenario, cuando un dispositivo quiera enviar tramas a un coordinador en una red con balizas, le bastar con sincronizarse con la supertrama y transmitir los datos directamente mediante CSMA-CA ranurado. El coordinador a su vez los asentir opcionalmente.

En el caso de que este escenario tenga lugar en una red sin balizas, el dispositivo transmitir los datos directamente mediante CSMA-CA no ranurado y el coordinador los asentir opcionalmente. En este tipo de redes no ser necesaria una sincronizacin previa entre los dispositivos.

El proceso de transmisin de datos de este escenario se ilustra, para los casos de redes con y sin balizas, en la siguiente figura:

Escenarios de envo de datos de un dispositivo a un coordinador

Transmisin de datos peer-to-peer

En una PAN peer-to-peer, todo dispositivo puede comunicarse con cualquier otro dentro de su esfera de cobertura.

Para que esta transmisin de datos se realice con xito, los dispositivos que deseen comunicarse deben estar sincronizados o continuamente envindose informacin.

En el primer caso, para lograr la sincronizacin entre los dispositivos ser necesario realizar una serie de medidas que el estndar 802.15.4 no especifica.

En el segundo caso, todo dispositivo podr siempre transmitir datos a otro simplemente empleando CSMA-CA no ranurado.

41

[Link].

Formato de Trama

El estndar IEEE 802.15.4 especifica cuatro tipos diferentes de tramas MAC (MPDUs): la trama baliza (beacon), la trama de datos, la trama de asentimiento (ACK) y la trama de comandos MAC.

Todas ellas constan de tres grandes bloques: la cabecera MAC (MHR), situada al comienzo de la trama, la carga de datos (payload), de longitud variable, y por ltimo, la cola (MFR).

El MFR contendr una secuencia de comprobacin de trama (FCS) de 16 bits para correccin y deteccin de errores en la trama recibida, y tendr la misma longitud en todas las tramas. El MHR en cambio, variar de tamao, siendo menor en el caso de tratarse de una trama de asentimiento.

El formato general descrito puede apreciarse en la figura siguiente:

Formato general de trama MAC A continuacin se proceder a describir resumidamente cada uno de los campos de la trama:

El campo de control de trama estar presente independientemente del tipo de trama y contendr informacin sobre el tipo de trama de que se trata, campos de direccionamiento incluidos y otros flags de control.

Campo de control de trama Como puede deducirse de la figura anterior, el campo de control de trama indicar al receptor exactamente el formato de los campos de la trama transmitida, para asegurar as su correcta interpretacin en recepcin. Adicionalmente indicar si quedan an tramas por transmitir destinadas al mismo receptor, y si se solicita el envo de asentimientos de su recepcin.

42

El nmero de secuencia contendr el identificador de secuencia de la trama. Para una trama baliza este campo tendr el valor de secuencia de trama baliza (BSN) y para el resto de tipos de trama, tendr el nmero de secuencia de datos (DSN). Los campos de direccionamiento incluirn, dependiendo del tipo de trama, el identificador de la PAN del dispositivo destino de la trama, su direccin, el identificador de la PAN del dispositivo origen y la direccin de este ltimo.

La cabecera auxiliar de seguridad contendr la informacin necesaria para los procesos relacionados con la seguridad, incluyendo cmo debe de protegerse la trama y qu claves deben ser usadas de la base de datos interna (PIB). Este campo slo parecer si se habilita la seguridad a nivel de MAC.

El campo FCS ser la secuencia de control de trama que permitir evaluar la integridad de la trama en recepcin. El valor del campo se calcular mediante un cdigo de redundancia cclica (CRC) de 16 bits, a partir del MHR y del payload de la trama MAC.

Una vez definido el formato genrico de las tramas MAC, los cuatro tipos existentes se diferenciarn principalmente en el formato del payload de datos y en la inclusin/exclusin de determinados campos de la cabecera (MHR).

Puesto que no se requiere, a efectos de este proyecto, un anlisis ms concienzudo del formato de las tramas MAC, no se profundizar ms en su estudio. Si se desea adquirir un mayor conocimiento sobre este campo, se recomienda la lectura del captulo 7.2 de la bibliografa recomendada [1] y [2].

[Link].

Servicios del nivel MAC

El nivel de acceso al medio (MAC) provee de dos servicios a las capas superiores: el servicio de datos (MCPS), y el servicio de gestin, (MLME). Entre los dos formarn un interfaz entre la capa superior (SSCS) y el nivel fsico (PHY), a travs de sendos puntos de acceso (SAPs).

De igual forma que suceda en el nivel PHY, los servicios se gestionarn a travs de sus puntos de acceso mediante un conjunto de primitivas.

As pues, el servicio de datos (MCPS), emplear las siguientes primitivas:

43

Primitiva MCPS-DATA MCPS-PURGE

Tipo 1 Request Request

Tipo 2 Confirm Confirm

Tipo 3 Indication --

Primitivas del servicio de datos MAC (MCPS)

Las primitivas MCPS-DATA permitirn a la capa superior solicitar a la MAC (.request) el envo de datos a un determinado destino. Como respuesta, la capa MAC generar a la capa superior una primitiva de confirmacin con el resultado de la operacin (.confirm).

En el caso de transmitirse el paquete a la capa fsica correctamente, sta enviar los datos y la capa MAC destino generar una primitiva de indicacin de llegada de datos a la capa superior (.indication). Esta primitiva llevar consigo los datos recibidos, informacin acerca de la calidad del enlace y opciones de seguridad, entre otras cosas.

Las primitivas MCPS-PURGE permitirn a la capa superior solicitar a la capa MAC (.request) la eliminacin de un paquete MSDU (Mac Service Data Unit) de la cola de transaccin. El resultado de esta operacin se notificar a la capa superior mediante la primitiva de confirmacin (.confirm).

De igual forma, el servicio de gestin de la capa MAC (MLME), emplear las siguientes primitivas:

Primitiva MLME-ASSOCIATE MLME-DISASSOCIATE MLME-BEACON-NOTIFY MLME-GET MLME-GTS MLME-ORPHAN MLME-RESET MLME-RX-ENABLE MLME-SCAN MLME-COMM-STATUS MLME-SET MLME-START MLME-SYNC MLME-SYNC-LOSS MLME-POLL

Tipo 1 Request Request -Request Request -Request Request Request -Request Request Request -Request

Tipo 2 Indication Indication Indication -Indication Indication ---Indication ---Indication --

Tipo 3 Response ----Response ----------

Tipo 4 Confirm Confirm -Confirm Confirm -Confirm Confirm Confirm -Confirm Confirm --Confirm

Primitivas del servicio de gestin MAC (MLME)

Las primitivas MLME_ASSOCIATE permitirn a la capa superior solicitar la asociacin con un dispositivo coordinador (.request). Esta solicitud se transferir al dispositivo destino, que estudiar si permitir dicha asociacin y har llegar su decisin a la capa superior del dispositivo

44

solicitante a travs de una confirmacin de la capa MAC (.confirm). Dicha confirmacin incluir tambin los errores que hayan tenido lugar, en caso de producirse alguno.

En el lado del coordinador, la capa MAC transferir a la capa superior una indicacin de la solicitud de asociacin (.indication) y sta decidir si aceptarla o rechazarla. Su decisin se transmitir desde la capa superior a la capa MAC (.response) y sta se encargar de comunicrsela al dispositivo solicitante mediante envo indirecto. Si tuviese lugar algn error a lo largo del procedimiento, ste se informara a la capa superior del dispositivo coordinador mediante la primitiva [Link].

Es necesario recordar que cada solicitud de la capa superior a la capa MAC se traducir habitualmente en una secuencia de transmisiones y recepciones de paquetes de la capa fsica antes de obtenerse ninguna confirmacin o indicacin del proceso.

Las primitivas MLME-DISASSOCIATE permitirn a un dispositivo solicitar (.request) la desasociacin con un coordinador o a un coordinador requerir la desasociacin de un dispositivo. El resultado de la operacin se comunicar luego a la capa superior mediante una primitiva de confirmacin (.confirm). Por otro lado, la capa MAC del destino de la peticin de desasociacin emitir a su capa superior la indicacin (.indication) de haber sido desasociado de la red (en caso de que el dispositivo solicitante sea un coordinador) o de la desasociacin de un dispositivo (en caso de que el dispositivo solicitante no sea el coordinador).

La primitiva [Link] se generar por la capa MAC de un dispositivo hacia su capa superior cuando reciba tramas baliza de un coordinador. Esta primitiva incluir pues la informacin contenida en la baliza.

Las primitivas MLME-GET permitirn a la capa superior solicitar (.request) el valor de algn atributo de la capa MAC (de la PIB, la PAN Information Base). La informacin recuperada se transmitir a la capa superior mediante la primitiva de confirmacin (.confirm).

Las primitivas MLME-SET permitirn a la capa superior fijar (.request) el valor de algn atributo de la capa MAC (PIB). El resultado de esta operacin se transmitir a la capa superior mediante la primitiva de confirmacin (.confirm).

Las primitivas MLME-GTS permitirn a la capa superior de los dispositivos solicitar (.request) la asignacin o desasignacin de un GTS con unas caractersticas determinadas. Una vez ms la MAC transmitir a su capa superior, mediante una primitiva de confirmacin (.confirm), el xito o fracaso del establecimiento del GTS.

45

Cuando la peticin de asignacin o desasignacin sea concedida por un coordinador, la capa MAC de ste notificar a su capa superior este suceso (.indication). Esta primitiva tambin se generar en la capa MAC de un dispositivo al que un coordinador haya desasignado un GTS.

Las primitivas MLME-ORPHAN permitirn indicar (.indication) a la capa superior de un coordinador de que ha recibido una notificacin de dispositivo hurfano. La capa superior evaluar pues si ese dispositivo estaba asociado al coordinador y generar una primitiva de respuesta (.response) a la capa MAC con la informacin al respecto. Si el dispositivo estaba asociado entonces la capa MAC generar un comando de realineacin con el dispositivo y se reasociar. Si no estaba asociado se ignorar esta primitiva. El xito o fracaso del proceso de realineacin con el dispositivo se comunicar a la capa superior del coordinador mediante la primitiva [Link].

Las primitivas MLME-RESET permitirn a la capa superior de un dispositivo reiniciar las variables internas de su capa MAC a su valor por defecto manteniendo (o no) el valor de los atributos del PIB. El xito o fracaso de esta solicitud (.request) se comunicar a la capa superior a travs de la primitiva de confirmacin (.confirm).

Las primitivas de MLME-RX-ENABLE permitirn a la capa superior solicitar que el receptor est encendido durante un periodo finito de tiempo o desactivado. La peticin (.request) provocar la generacin de un considerable nmero de primitivas de capa fsica y el uso de temporizadores. El xito o fracaso de esta operacin (y las causas de ello) se informarn a la capa superior a travs de la primitiva de confirmacin (.confirm).

Las primitivas MLME-SCAN permitirn a la capa superior solicitar (.request) un escaneo de la energa de una lista dada de canales. Esto permitir a la capa superior evaluar la energa que se encuentra localizada en stos, buscar coordinadores PAN (el propio u otros), balizas, etc.

El escaneo puede ser de cuatro formas: deteccin de energa (Energy Detection, ED), escaneo activo, escaneo pasivo o escaneo de hurfanos (Orphan Scan).

El resultado de esta operacin (lista de descriptores de PAN o listas de niveles de energa), as como el xito o fracaso de la misma, se comunicarn a la capa superior mediante la primitiva de confirmacin (.confirm).

La primitiva [Link] permitir informar a la capa superior del estado de una comunicacin. Esta primitiva se generar en muchas situaciones de error de comunicacin o incidencias de seguridad, as como en el proceso (exitoso o no) de asociacin de dispositivos o de realineamiento de dispositivos hurfanos.

46

Las primitivas MLME-START permitirn a un dispositivo FFD solicitar (.request) la creacin de una nueva PAN o el empleo de una nueva configuracin de supertrama. El resultado se informar a la capa superior a travs de la primitiva de confirmacin (.confirm).

La primitiva [Link] permitir a la capa superior solicitar sincronizacin del dispositivo con las balizas enviadas por un coordinador en un canal determinado. Opcionalmente esta solicitud permite especificar si se desea sincronizarse tan slo con la primera baliza que se reciba o con todas las que lleguen adems de la primera.

La primitiva [Link] se generar en la capa MAC de un dispositivo hacia la capa superior en caso de prdida de sincronizacin con un coordinador, indicando adicionalmente las posibles causas.

Las primitivas MLME-POLL permitirn a la capa superior solicitar a un coordinador (.request) el envo de datos pendientes para el dispositivo. La capa MAC del dispositivo solicitante informar a su capa superior del resultado de la peticin (.confirm) y, en caso de haber recibido datos pendientes, se transmitirn seguidamente mediante la primitiva correspondiente (.indication).

Todas las primitivas estudiadas permitirn estimar las prestaciones que las capas fsica y de acceso al medio de 802.15.4 pueden llegar ofrecer.

Para alcanzar un conocimiento en mayor profundidad acerca del exacto funcionamiento de los comandos enviados al medio as como de su formato, sistemas de seguridad, reenvo de tramas, comprobacin de errores y dems detalles de bajo nivel, se recomienda acudir al estndar IEEE 802.15.4. En lo que a este proyecto se refiere, se trabajar con esos aspectos de forma transparente, a travs de los parmetros contenidos en las primitivas ya descritas.

47

2.3.

La especificacin ZigBee

La especificacin ZigBee es un estndar de facto, desarrollado por la ZigBee Alliance (asociacin de decenas de empresas), en busca de la definicin de un protocolo global y abierto para el intercambio de datos inalmbricos en sistemas de automatizacin de hogares y edificios, electrnica de consumo, control industrial, escenarios de monitorizacin y control, entornos socio sanitarios, perifricos de PC y juegos, etctera, entre dispositivos de bajo coste y bajo consumo.

El objetivo principal de ZigBee ser definir los niveles de red, seguridad y aplicacin (modelo OSI de siete capas) en escenarios de redes inalmbricas de sensores, basndose en el nivel fsico y de acceso al medio (MAC) definidos por el estndar IEEE 802.15.4.
[4]

La primera versin de la especificacin vio la luz en diciembre del ao 2004 extenderse en el mercado y a da de hoy se considera obsoleta.

pero no lleg a

La segunda versin de la especificacin se public en octubre del ao 2006

[5]

y presenta

considerables modificaciones con respecto a la versin original, siendo ambas incompatibles. La tercera y ltima versin publicada (octubre del ao 2007 [6]), permite dos perfiles distintos de pila (stack): Perfil de pila 1 (stack profile 1): llamado simplemente ZigBee, diseada para aplicaciones comerciales de control y monitorizacin del hogar, capaces de presentar firmwares ms pequeos para dispositivos de capacidad reducida. Perfil de pila 2 (Stack profile 2): llamado ZigBee PRO, que ofrece nuevas funcionalidades como envos multicast, agilidad de frecuencia, mecanismos de encaminamiento many-to-one (para la recoleccin centralizada de datos), alta seguridad con intercambio de claves simtricas (SKKE), mayor capacidad de fragmentacin de paquetes, etctera. Requiere de dispositivos con mayor capacidad de almacenamiento y memoria. ZigBee 2007 es completamente compatible con ZigBee 2006, de modo que un dispositivo ZigBee 2007 podr asociarse y funcionar correctamente en una red ZigBee 2006 y viceversa. Por el contrario, debido a diferencias incompatibles en el algoritmo de encaminamiento, los dispositivos ZigBee 2006 o ZigBee 2007 slo podrn funcionar en una red ZigBee PRO como dispositivos finales (ZEDs), del mismo modo que los dispositivos ZigBee PRO slo podrn funcionar como dispositivos finales en una red ZigBee 2006 o ZigBee 2007. Adicionalmente, se han publicado algunas revisiones de cada una de las versiones de la especificacin, que se han limitado a incluir clarificaciones del texto y a corregir erratas.

48

Desafortunadamente, debido a la poltica interna de la ZigBee Alliance, ha existido una considerable diferencia temporal entre la publicacin de cada especificacin y su disponibilidad al pblico general (aquellos que no son miembros de la ZigBee Alliance). Este hecho, en conjuncin con los retrasos sucedidos en la publicacin de libreras por parte de los distintos fabricantes, ha ralentizado considerablemente la aparicin de nuevos productos ZigBee en el mercado.

2.3.1. Consideraciones Generales

A continuacin se proceder a describir las caractersticas generales ms significativas de la especificacin ZigBee.

[Link].

Tipos de Dispositivos

De forma similar a como suceda en el estndar IEEE 802.15.4 (y basndose en l), ZigBee define diferentes tipos de dispositivo segn su papel en la red: Coordinador ZigBee (ZigBee Coordinator, ZC). Equivaldr al coordinador de la PAN segn la versin del 2003 del estndar 802.15.4. Siempre deber existir uno por red ZigBee y ser el tipo de dispositivo ms completo. Router ZigBee (ZigBee Router, ZR). Ser un FFD funcionando como coordinador dentro de su espacio de operacin (segn la definicin del estndar 802.15.4-2003), capaz de encaminar mensajes entre dispositivos de la red y de permitir la asociacin a la red de nuevos equipos. Dispositivo final (ZigBee End Device, ZED). Podr ser un RFD o un FFD (segn la definicin del estndar 802.15.4-2003) que no funcione ni como ZC ni como ZR. Poseer la funcionalidad necesaria para comunicarse con su nodo padre (el coordinador o un router), pero no podr encaminar informacin de otros dispositivos. De esta forma, este tipo de nodo puede estar dormido la mayor parte del tiempo, aumentando la vida media de sus bateras. Un ZED suele tener requerimientos reducidos de memoria por lo que habitualmente ser significativamente ms barato. De este modo, todas las redes ZigBee dispondrn siempre de un nico coordinador ZigBee (ZC) y de un nmero indeterminado de routers (ZR) y dispositivos finales (ZEDs).

49

[Link].

Topologas de Red

La capa de red ZigBee (NWK), soportar las topologas de estrella, rbol y malla.

Topologas de red de la especificacin ZigBee [10] En una topologa de estrella la red ser controlada por un nico dispositivo, el coordinador ZigBee (ZC), que ser el responsable del control de la asociacin y mantenimiento del resto de dispositivos en la red, que se comunicarn directamente con este coordinador.

En las topologas de rbol y malla la red se inicializar y controlar por el coordinador ZigBee pero podr ser extendida a travs de routers (dispositivos FFD funcionando como coordinadores).

En las redes de rbol, los routers (ZC) encaminarn los mensajes de datos o control a travs de la red usando una estrategia de enrutado jerrquica y podrn emplear comunicaciones con balizas tal como especifica el estndar 802.15.4-2003 (aunque rbol y estrella sern las nicas topologas que lo permitirn).

Las topologas de malla en cambio permitirn comunicaciones completas punto a punto pero los routers no emitirn balizas peridicamente como define el estndar 802.15.4.-2003.

[Link].

Arquitectura de Referencia ZigBee

La arquitectura ZigBee se basa en el modelo de siete capas OSI, dejando las dos capas inferiores, la fsica y la de acceso al medio (MAC) al estndar 802.15.4 (nicamente a la versin de octubre del 2003).

De este modo, ZigBee especificar nicamente la capa de red, los mecanismos de seguridad a emplear y la interfaz con la capa de aplicacin. Esta ltima estar formada por la subcapa de soporte de la aplicacin (APS), el objeto de dispositivo ZigBee (ZigBee Device Object, ZDO) y los objetos de aplicacin definidos por el fabricante (que se comunicarn con el resto de la

50

arquitectura desde la plataforma de aplicacin (AF) a travs de sus puntos de acceso de servicio).

As pues, a arquitectura de referencia de la especificacin ZigBee se presenta en la siguiente figura:

Plataforma de Aplicacin (AF) Objeto de Objeto de

Aplicacin 240 (EP 240) APSDE-SAP Aplicacin 1 (EP 1) APSDE-SAP

I n t e r f a z

Objeto de Dispositivo ZigBee (ZDO)

(EP 0) APSDE-SAP

Subcapa de Soporte a la Aplicacin (APS)

Gestor de Seguridad APS
NLDE-SAP

Proveedor de Servicios de Seguridad

APS Agente de Mensajes

Gestor de Reflector

Capa de Red (NWK)

Gestor de Seguridad NWK
MCPS-SAP

Plano de Gestin del ZDO

Funcin de capa Interfaz

NWK Agente de Mensajes

Gestor de Rutas

Gestor de Red
MLME-SAP

Capa de Acceso al Medio (MAC)

Definido por el fabricante final Definido por la ZigBee Alliance Definido por IEEE 802.15.4 2,4 GHz
PD-SAP PLME-SAP

Capa Fsica (PHY)

868 915 MHz

Esquema de la arquitectura de referencia de ZigBee La capa de red ZigBee (NWK) incluir los mecanismos necesarios para desempear las funciones de asociacin o desasociacin de una red, aplicacin de seguridad a tramas, encaminamiento de paquetes, descubrimiento y memorizacin de rutas entre dispositivos,

descubrimiento de vecinos adyacentes y almacenamiento de informacin relativa a stos entre otras.

La capa NWK de un coordinador ZigBee ser pues la responsable de establecer una nueva red cuando sea necesario y de asignar las nuevas direcciones a los dispositivos asociados a sta.

La capa de aplicacin (APL) estar formada por la subcapa de soporte de la aplicacin, el objeto de dispositivo ZigBee (ZDO) y la plataforma de la aplicacin.

51

La subcapa de soporte de la aplicacin (APS) se encargar principalmente de mantener tablas de ligaduras (bindings) entre dispositivos con servicios o necesidades similares, convertir direcciones cortas a largas o viceversa, definir direcciones de grupos y procesarlas para el encaminamiento o filtrado de tramas, trocear y reensamblar tramas, y reenviar mensajes entre dispositivos vinculados.

Las responsabilidades del objeto de dispositivo ZigBee (ZDO) consistirn mayormente en la definicin del rol que desempear el dispositivo en la red (coordinador o dispositivo final, por ejemplo), la gestin de las solicitudes o respuestas de ligadura, el establecimiento de sesiones seguras entre dispositivos de la red, y el descubrimiento de dispositivos y los servicios de aplicacin que ofrecen.

A continuacin se proceder a describir con mayor profundidad las diferentes capas.

2.3.2. Nivel de Red

La funcin principal del nivel de red ZigBee debe ser asegurar un correcto uso del nivel MAC especificado en el IEEE 802.15.4-2003 y ofrecer una interfaz adecuada al nivel de aplicacin para que ste pueda hacer uso de sus servicios fcilmente.

Este nivel est formado por dos entidades: la entidad de datos NLDE (Network Layer Data Entity) y la entidad de gestin NLME (Network Layer Management Entity).

La NLDE proporcionar el servicio de transmisin de datos y la NLME se encargar de las operaciones de control y gestin (haciendo uso ocasionalmente de los servicios de la NLDE), para las cuales mantendr una base de datos conocida como Network Information Base (NIB).

Al igual que suceda con 802.15.4, cada entidad presentar un punto de acceso (SAP) a la capa superior para que sta pueda hacer uso de los servicios que ofrece. El modelo se presenta en la siguiente figura:

Modelo de referencia de la capa de Red (NWK)

52

[Link].

Entidad de Datos del Nivel de Red (NLDE)

La NLDE se encargar del transporte de datos de aplicacin (APDU) entre dos o ms dispositivos pertenecientes a la misma red. De este modo, la NLDE proporcionar los siguientes servicios:

Generacin de tramas de nivel de red (NPDU) a partir de las tramas recibidas del subnivel de soporte de aplicacin (ASPDU), mediante la adicin de la cabecera apropiada.

Encaminamiento de mensajes segn sea la topologa especfica que se est usando. Autenticacin y confidencialidad de las comunicaciones.

Para cumplir estos objetivos, la NLDE se amparar en las primitivas NLDE-DATA:

Primitiva NLDE-DATA Tipo 1 Request Tipo 2 Confirm Tipo 3 Indication

Primitivas del servicio de datos capa NWK Estas tres primitivas NLDE-DATA permitirn a la APS solicitar el envo de PDUs destinados a otra u otras APS (.request), que los recibirn mediante la primitiva de indicacin (.indication). El xito o fracaso del envo se notificar a la APS origen mediante una confirmacin (.confirm).

[Link].

Entidad de Gestin del Nivel de Red (NLME)

La NLME se encargar de la gestin del nivel de red, permitiendo al nivel de aplicacin interaccionar con la pila de protocolos. Para ello, ofrecer los siguientes servicios:

Configuracin de la pila de protocolos para un funcionamiento correcto. Establecimiento de una nueva red ZigBee. Asociacin, re-asociacin y abandono de una red. Asignacin de direcciones a los dispositivos que se incorporen a la red. Descubrimiento, seguimiento y notificacin de dispositivos ZigBee adyacentes (vecinos). Descubrimiento de rutas para el encaminamiento de paquetes en la red. Control del estado activo/inactivo del receptor. Encaminamiento de paquetes mediante diferentes mecanismos: Unicast, broadcast, multicast, o many-to-one para el intercambio eficiente de datos en la red.

Una vez ms, estos objetivos se alcanzarn mediante el empleo de un nmero considerable de primitivas que, debido a su nmero y complejidad, solamente se enumerarn a continuacin:

53

NLME-NETWORK-DISCOVERY,

NLME-NETWORK-FORMATION,

NLME-PERMIT-JOINING,

NLME-START-

ROUTER, NLME-ED-SCAN, NLME-JOIN, NLME-DIRECT-JOIN, NLME-LEAVE, NLME-RESET, NLME-SYNC, NLMESYNC-LOSS, NLME-GET, NLME-SET, NLME-NWK-STATUS y NLME-ROUTE-DISCOVERY.

[Link].

Formato de Trama de Red

El formato de la trama de nivel de red (NPDU) se representa en la siguiente figura:

Formato genrico de trama de red (NWK) Como puede apreciarse en la figura, bsicamente se pueden distinguir dos secciones: la cabecera y la carga de datos.

En el campo de control de trama se especificar el tipo de trama (trama de datos o comando NWK), la versin del protocolo empleada, y la activacin o desactivacin de los mecanismos de: descubrimiento de ruta, envo multicast, seguridad de nivel de red, inclusin de direcciones de 64 bits (largas) origen y/o destino y la inclusin/exclusin de la ruta de origen.

Los campos de direccin de 16 bits incluirn diferentes valores segn sea el tipo de envo realizado (Unicast, multicast, broadcast, etc.)

El campo de radio especificar el nmero mximo de saltos que el paquete puede realizar por la red. Cada dispositivo intermedio que retransmita la trama decrementar en uno su valor.

El resto de campos de la cabecera: direcciones de 64 bits, control multicast y la subtrama de origen de ruta, slo aparecern en caso de activarse dichos mecanismos.

Especial mencin requiere el campo de subtrama de origen de ruta ya que de activarse, contendr una lista de los dispositivos intermedios que han ido reencaminando la trama. Este mecanismo permitir al receptor reencaminar la respuesta a la trama hacia su origen sin requerir de nuevos descubrimientos de ruta, lo cual reducir las tablas necesarias en memoria de los dispositivos intermedios.

En ltimo lugar, el campo de datos contendr la trama recibida del nivel de soporte a la aplicacin (de tratarse de una trama de datos) o un comando de nivel de red (en el caso de tratarse de un comando NWK).

54

Los comandos NWK son lo suficientemente complejos, y su relacin con el mbito de este proyecto demasiado distante, como para no profundizar en ellos en esta memoria. Sin embargo se enumeran a continuacin: Route request, Route reply, Network Status, Leave, Route Record, Rejoin request, Rejoin response, Link Status, Network Report, y Network Update.

2.3.3. Nivel de Aplicacin

El nivel de aplicacin (APL) est situado en la parte ms alta del modelo de capas definido por la especificacin ZigBee y se compone de los siguientes subniveles: el subnivel de soporte de aplicacin (APS), la plataforma de aplicacin (AF) y el objeto de dispositivo ZigBee (ZDO).

A continuacin se proceder a describir resumidamente dichas subcapas y los conceptos relacionados ms significativos.

[Link].

Subnivel de Soporte de Aplicacin (APS)

La subcapa de soporte de la aplicacin (APS) proveer de un interfaz entre la capa de red (NWK) y la capa de aplicacin (APL), a travs de un conjunto de servicios que las aplicaciones definidas por los fabricantes compartirn con el ZDO.

De forma anloga a como suceda en otras capas, en la APS se distingue entre una entidad de datos (APSDE) y una entidad de gestin (APSME), ambos con sus respectivos puntos de acceso (SAP).

Como su nombre indica, la APSDE proveer del servicio de transmisin de datos entre dos objetos de aplicacin de dos dispositivos pertenecientes a la misma red, otorgando adems capacidades fiabilidad (mediante reintentos de nivel de aplicacin), filtrado de direcciones de grupo, rechazo de mensajes duplicados, fragmentacin de paquetes y comunicacin a travs de ligaduras (bindings). As mismo, la APSME proveer de diversos servicios a los objetos de aplicacin, entre los cuales se incluye la seguridad, la gestin de grupos (para mensajes multicast) y los bindings entre dispositivos. Adicionalmente se encargar de mantener una base de datos (AIB) de los objetos gestionados.

Para alcanzar dichos objetivos, el APS har uso de la siguiente serie de primitivas: APSDEDATA, APSME-BIND, APSME-UNBIND, APSME-GET, APSME-SET, APSME-ADD-GROUP, APSME-REMOVE-GROUP y APSME-REMOVE-ALL-GROUPS.

55

[Link].1.

Ligaduras (Bindings)

Las ligaduras son enlaces virtuales que se establecern entre clusters de dos objetos de aplicacin complementarios (ver apartado [Link]).

Esto quiere decir que ser una asociacin lgica entre una funcionalidad de una aplicacin actuando como servidor y otra funcionalidad compatible de otra aplicacin actuando como cliente.

Un ejemplo habitual podra ser el establecimiento de una ligadura entre las actuaciones de encendido/apagado de un interruptor de pared y el encendido/apagado de una bombilla. Este ejemplo se ilustrar en la siguiente figura:

Ejemplo del establecimiento de bindings entre dispositivos del perfil Home Automation

Como puede observarse en la figura, gracias a los bindings un interruptor puede estar ligado a ms de una bombilla y controlar su luminosidad simultneamente. De la misma forma una bombilla podra estar controlada por ms de un interruptor.

La informacin de los endpoints y sus clusters asociados que estn enlazados mediante ligaduras se almacenar en una tabla al efecto que debe conservarse ante posibles reinicializaciones de los dispositivos. Por esta razn dichas tablas se almacenarn habitualmente en el coordinador ZigBee, y slo se crearn nuevas ligaduras en los escenarios que dispongan de una red ZigBee operativa cuando las restricciones de seguridad aplicadas lo permitan. Habitualmente los bindings se establecern de forma que sea muy sencillo para el usuario/instalador: mediante la pulsacin de un switch de los dispositivos implicados, mediante comandos emitidos desde una aplicacin controladora, etctera.

Esto permitir efectuar la asociacin lgica entre dispositivos de funcionalidades similares de forma casi plug&play, lo cual otorgar a la red ZigBee de un gran potencial, escalabilidad e interoperabilidad sin necesidad de instalaciones complicadas y costosas.

56

[Link].2.

Transmisin de Mensajes de Capa de Aplicacin

El nivel APS facilitar dos mecanismos para el envo de mensajes entre diferentes endpoints: envo directo y envo indirecto.

El envo directo asume que se ha realizado un descubrimiento de dispositivo y de servicio previamente y se ha identificado un dispositivo y punto final determinado que puede proporcionar el servicio complementario al que enva los mensajes. Para realizarlo se debe indicar la direccin corta del dispositivo, el cluster y el identificador del endpoint destino.

Para los dispositivos ms simples, la necesidad de incluir toda esta carga de direccionamiento puede ser contraproducente, por lo que suelen emplear el mecanismo de envo indirecto, mediante el cual slo se especifica la direccin del dispositivo y endpoint origen y la tabla de ligaduras averiguar el destino o destinos finales. Obviamente la ligadura debe haberse realizado previamente.

Adicionalmente, se permitir el envo de mensajes unicast (mediante los mecanismos ya descritos), multicast (mediante el empleo de direcciones de grupo de 16 bits) y broadcast (destinados a todos los dispositivos de la red).

Finalmente, como ya se ha mencionado, la capa APS otorgar una comunicacin segura y fiable mediante el envo de reintentos y tramas de asentimiento de aplicacin (ACK opcionales), adems de responsabilizarse de la fragmentacin y reensamblado de paquetes cuando sea necesario.

[Link].

Plataforma de Aplicacin (AF)

La plataforma de aplicacin es el entorno sobre el cual se alojarn los objetos de aplicacin ZigBee y que otorgar la interfaz imprescindible para que stos puedan comunicarse con el resto de las capas que conforman la pila y con los objetos de aplicacin de otros dispositivos de la red.

Aunque cada nodo de una red ZigBee estar dotado de una direccin larga de 64 bits y recibir adicionalmente una direccin corta de 16 bits (identificador de nodo) al asociarse a sta, se requiere un mecanismo para direccionar cada uno de los distintos objetos de aplicacin que pueden residir dentro de un mismo nodo. De este modo, cada objeto de aplicacin se identificar mediante un endpoint (punto final) numerado con un valor entre 1 y 240. Los valores 0 y 255 identificarn el ZDO y la interfaz de transmisiones broadcast respectivamente, mientras que el resto de valores entre 241 y 254 se reservarn para usos futuros.

57

Adicionalmente, cada objeto de aplicacin asociado a un endpoint podr describirse a travs de un identificador de tipo de dispositivo que ser nico dentro de cada perfil de aplicacin (ver siguiente subapartado) y mediante el conjunto de clusters y atributos que contiene (ver subapartado [Link].2).

[Link].1.

Perfiles de Aplicacin (Profiles)

Los perfiles de aplicacin (profiles) son acuerdos de comandos, formatos de mensaje y acciones de procesado, que permitirn a los desarrolladores la creacin de una aplicacin interoperable distribuida entre las entidades de aplicacin residentes dentro de dispositivos de diferentes fabricantes.

Los perfiles de aplicacin son una de las caractersticas ms interesantes del protocolo ZigBee ya que permitirn a diferentes tipos de dispositivos (y a las aplicaciones contenidas en ellos) el intercambio de comandos, solicitudes de datos, y el procesado de los mismos.

Un ejemplo de perfil de aplicacin ZigBee podra ser el Home Automation Profile, que permitir a distintos tipos de dispositivos el intercambio de mensajes de control para el establecimiento de una aplicacin inalmbrica de automatizacin del hogar. De este modo, los dispositivos pertenecientes a la red podrn enviar tramas conocidas para apagar/encender luminarias, emitir medidas de temperatura a termostatos, o el envo de alarmas por deteccin de movimiento, por ejemplo.

Otro ejemplo vlido podra ser el perfil de dispositivo ZigBee (ZDP), soportado por todos los dispositivos ZigBee, y que definir las acciones comunes que tendrn lugar entre dispositivos ZigBee como son las asociaciones a la red y el descubrimiento de dispositivos y servicios.
[10]

El primer perfil de aplicacin publicado fue el Home Automation

, en el ao 2007, y define

un escenario sencillo, fiable, escalable y de coste moderado para el control de la iluminacin, el consumo de energa, el entorno y la seguridad en hogares o pequeas oficinas.
[11]

El segundo perfil publicado fue el Smart Energy

, en mayo del ao 2008, y ofrece a

empresas y a proveedores de energa un sistema sencillo y seguro para la gestin inalmbrica del consumo energtico en redes de rea del hogar (HAN). De este modo se podrn programar, de forma sencilla, aplicaciones de gestin y eficiencia energtica para adecuarse a los requisitos impuestos por el gobierno.

Otros perfiles de aplicacin para escenarios tan variados como la automatizacin de edificios (Building Automation Profile) o aplicaciones socio-sanitarias (Health Care Profile), se encuentran en proceso de desarrollo y se espera su publicacin inminente.

58

[Link].2.

Racimos (Clusters)

Los racimos (clusters) son conjuntos de atributos y comandos relacionados que definen un interfaz de comunicacin entre dos dispositivos, uno de los cuales emplear las funcionalidades que ofrece como cliente el cluster mientras que el otro har uso de las herramientas que ofrece como servidor.

Los clusters se identificarn de forma unvoca dentro mediante un identificador de 16 bits que ser nico dentro de un determinado perfil de aplicacin.

Para los perfiles desarrollados por la ZigBee Alliance, sta ha creado una librera de racimos pblica (ZigBee Cluster Library
[24]

) que provee de una definicin e identificacin comn para

los clusters ms comunes (y para los atributos que stos incluyen). Esta librera se encuentra en constante evolucin y mantenimiento, habindose publicado ya dos versiones de la misma.

Como ejemplo, se pueden mencionar los clusters para la identificacin de dispositivos (Identify cluster), para la conmutacin de estados (On/Off cluster), para la medida de temperaturas (Temperature Measurement cluster), para la deteccin de presencia (Occupancy cluster) y un largo etctera.

No obstante, los fabricantes podrn definir sus propios perfiles de aplicacin con sus clusters y descripciones de dispositivos propietarias (previa negociacin con la ZigBee Alliance) al igual que podrn incluir determinadas extensiones propietarias dentro perfiles pblicos.

Los dispositivos ZigBee, al publicar los servicios que ofrecen, debern incluir la informacin relativa al perfil que implementan y a los clusters especficos que soportan. As mismo la creacin de ligaduras (bindings) entre diferentes endpoints se realizar siempre entre dos clusters compatibles, uno siguiendo el rol de servidor y el otro el de cliente.

[Link].

Objeto de Dispositivo ZigBee (ZDO)

El objeto de dispositivo ZigBee se comportar como el interfaz existente entre los objetos de aplicacin (aplicaciones programadas por el fabricante), el perfil del dispositivo y la plataforma de soporte de la aplicacin (APS).

El ZDO satisfacer los requisitos comunes de todas las aplicaciones que operen empleando la pila de protocolos ZigBee. De este modo, ser responsable de:

Inicializar la capa de soporte de aplicacin (APS), la capa de red (NWK) y el proveedor de servicios de seguridad (SSP).

59

Recopilar informacin de configuracin de los objetos de aplicacin para desempear adecuadamente las funciones de descubrimiento de dispositivos y servicios, gestin de seguridad, gestin de red y gestin de bindings.

De este modo el ZDO actuar de interfaz pblico para la plataforma de aplicacin (AF), permitiendo a los distintos objetos de aplicacin el control del dispositivo fsico y el acceso a las funciones de red propias del protocolo.

El objeto de aplicacin se localizar siempre en el endpoint 0, desde donde se comunicar con las capas inferiores de la pila del protocolo a travs de sus puntos de acceso (APSDE-SAP para transmisin de datos y APSME-SAP para mensajes de control). El servicio de descubrimiento de dispositivos ser el proceso mediante el cual un sensor ZigBee podr conocer otros dispositivos de la red. Para ello permitir el envo de peticiones de direccin corta o larga de larga de un dispositivo en la red (transmisiones broadcast y unicast respectivamente) y transmitir las respuestas al solicitante.

El descubrimiento de servicios ser el proceso mediante el cual las capacidades de un determinado dispositivo se publicarn hacia otros dispositivos. Existen varios mecanismos para lograr este objetivo: mediante envos de solicitudes de informacin dirigidos a cada endpoint de un dispositivo, o mediante el envo del listado de servicios requeridos de un dispositivo y su comparacin con los que ste tiene disponibles (match procedure).

As pues se podr resumir que el ZDO se otorgar las funcionalidades bsicas que debe poseer todo coordinador, router o dispositivo final ZigBee para funcionar dentro de la red. De este modo, cada objeto de aplicacin se centrar en definir su comportamiento particular.

Existen infinidad de aspectos adicionales de la especificacin ZigBee que podran ser desarrollados, sin embargo, no se profundizar ms en ellos debido a su relacin dbil o nula con el objetivo final de este proyecto. De modo que si se desea adquirir un mayor conocimiento acerca de ZigBee, se recomienda encarecidamente la lectura de la especificacin [6].

60

2.4.

Plataformas ZigBee Disponibles en el Mercado

La ZigBee Alliance especifica los niveles de la capa de red hasta la capa de soporte de aplicaciones que, combinados con las capas inferiores de IEEE 802.15.4, permiten proporcionar una gama inalmbrica completa.
[25] [26] [27]

Fabricantes de semiconductores como Microchip

, Atmel

y Freescale

suministran

mdulos completos de desarrollo que comprenden las capas de ZigBee y IEEE 802.15.4 e integran un microcontrolador para almacenar el firmware del protocolo y el de las aplicaciones.

Mediante estos mdulos, los ingenieros podrn completar diseos funcionales sin conocimientos especializados en RF y/o en layout de placas. A su vez, las placas de desarrollo que soportan estos mdulos ofrecern un punto de partida idneo para el desarrollo y evaluacin de aplicaciones.

En la actualidad, muchos fabricantes de chips ZigBee venden radios integradas y microcontroladores dentro de un mismo chip (single chip) con una capacidad de entre 60 KB a 128 KB de memoria Flash. Tal es el caso del JN5148 (Jennic), el MC13213 (Freescale), el EM250 (Ember) o el CC2430 (Texas Instruments). Habitualmente la radio tambin puede adquirirse de forma separada, permitiendo a los desarrolladores elegir el microprocesador que deseen.

De forma adicional, la mayora de fabricantes de chips ZigBee suministrarn la pila de protocolos (802.15.4 y ZigBee) e incluso las fuentes de su cdigo para los chips que venden.

Una seleccin adecuada de un determinado kit de desarrollo ZigBee estar determinada por la profunda evaluacin de los siguientes factores:

1. Costes de las licencias del entorno de desarrollo y de la pila de protocolos. 2. Coste y eficiencia del servicio tcnico (soporte). 3. Coste de los analizadores de protocolo (sniffers), de ser necesarios. 4. Completitud de la pila de protocolos suministrada (cosa poco habitual). 5. Inclusin (o no) de perfiles pblicos de aplicacin en la pila (cosa an menos habitual). 6. Usabilidad del IDE y del depurador. 7. Inclusin de ejemplos de aplicacin (que acelerarn el proceso de desarrollo). 8. Inclusin de herramientas grficas para la configuracin y generacin de aplicaciones de ejemplo personalizadas (para un hardware y comportamiento especficos). 9. Inclusin de un mecanismo de carga remota (junto con un bootloader) para la actualizacin inalmbrica del firmware de los equipos.

61

10. Disponibilidad de una documentacin completa de las libreras, ejemplos de aplicacin y entornos de desarrollo.

De este modo, existe en la actualidad un nmero considerable de empresas que suministran chips ZigBee, OEMs, kits de desarrollo, mdulos de radio, o soluciones de integracin de los chips de otros fabricantes. Muchos de estos productos se encuentran ya certificados por la ZigBee Alliance, pero no todos.

En la siguiente tabla se ilustran las principales caractersticas de los productos ofrecidos por los fabricantes de chips ms importantes (que adems permanecen activos desde antes del inicio de este proyecto):
Compaa Productos MC13211 (8 bits) MC13212 (8 bits) Freescale
[14]

Notas

Parte de Motorola hasta el 2004. Suministra chips ZigBee (soluciones single chip o dual chip), transceptores radio, kits de desarrollo, pilas de protocolos (BeeStack),

MC13213 (8 bits) MC13224V (32 bits, ARM7 ) EM250 (8 bits) EM260 (8 bits)

aplicaciones de ejemplo y herramientas SW.

Una de las empresas fundadoras de la ZigBee Alliance. Suministra chips ZigBee (SoC o coprocesador separado), kits de desarrollo, pilas de protocolo (EmberZNet), aplicaciones de ejemplo,

Ember

[15]

EM351 y EM357 (32 bits, ARM) CC2430/1 (8 bits)

analizador de protocolos y herramientas SW.

Duea de Chipcon y promotora de la ZigBee Alliance. Suministra chips ZigBee (soluciones single chip, dual chip o coprocesador separado), transceptores radio, kits de desarrollo, pilas de protocolos (ZStack), aplicaciones de ejemplo y herramientas SW. Empresa participante de la ZigBee Alliance. Suministra chips ZigBee (soluciones single chip o coprocesador separado), kits de desarrollo, pilas de protocolos y herramientas SW.

Texas Instruments
[16]

CC2530 (8 bits) CC2480 (8 bits) MSP430X JN5148 (32 bits)

Jennic

[28]

JN5139 (32 bits) JN5121 (32 bits)

Principales fabricantes de chips ZigBee Basndose en los chips mencionados, se encuentran en la actualidad multitud de empresas que suministran soluciones ZigBee de todo tipo (completas o parciales).

Algunas de las ms importantes sern: CEST (con soluciones basadas en chips de Texas Instruments), MeshNetics (basadas en los transceptores radio de Atmel, ZigBits), MaxStream/Digi (basados originalmente en Freescale y ahora en Ember), Telegesis (basados en Ember) o Crossbow (basados en Atmel).

62

En el caso de Espaa, una de las soluciones ms atractivas, por la variedad de productos disponibles y por el tiempo que permanece en el sector, es la empresa NLaza Soluciones [19].

NLaza, en su lnea de productos NDimension, suministra dispositivos 802.15.4 y ZigBee basados en el chip MC13213 de Freescale para una gran variedad de escenarios como son la domtica, las aplicaciones socio-sanitarias, la seguridad, el control de consumo energtico, etc.

Aunque en la actualidad resulta sencillo el acceso y adquisicin de los kits de desarrollo y productos finales 802.15.4 y ZigBee mencionados, esto no suceda as hace unos aos (cuando se inici este proyecto), ya que la tecnologa an era inmadura y no tena de tantos seguidores.

En las fechas en que se eligi el fabricante las nicas referencias slidas eran Freescale (anteriormente parte de Motorola
[29]

) y Texas Instruments. Exista una tercera compaa,

Ember, que an siendo una de las fundadoras de la ZigBee Alliance, no se tena claro si tendra la capacidad de superar la crisis del sector (aunque luego se ha convertido en uno de los referentes del sector).

Freescale suministraba entonces un kit de desarrollo muy completo para el chip MC13213 (mucho ms que el de la competencia), satisfaciendo adecuadamente los 10 requisitos enumerados anteriormente. Simultneamente, NLaza Soluciones era una de las pocas empresas espaolas que fabricaban sus dispositivos ZigBee basndose en ella.

Kit de Desarrollo MC13213 de Freescale

De este modo, la eleccin de la plataforma ZigBee de Freescale (Kit MC13213) y los dispositivos de NLaza Soluciones (Interfaz RS232 ND07) como base para la realizacin de este proyecto fueron claramente la decisin a tomar en ese momento.

63

2.5.

Soluciones de Autoconfiguracin de Dispositivos

Como ya se ha mencionado al principio de esta memoria, y se desarrollar con profundidad a lo largo de los siguientes captulos, las redes ZigBee requieren de un mecanismo que permita la actualizacin/configuracin remota de los dispositivos que la integran.

Este mecanismo estar formado por un protocolo de carga remota y un cargador de arranque (bootloader) capaz de actualizar el firmware del dispositivo.

Puesto que no hay una especificacin regulatoria al respecto, el protocolo empleado puede ser cualquiera que otorgue las suficientes garantas de velocidad, fiabilidad y seguridad. Soluciones habituales del mercado suelen basarse en protocolos inalmbricos como TFTP o XModem-CRC. An as este campo es todava objeto de estudio en la actualidad.

Sin embargo, el cargador de arranque es absolutamente dependiente del hardware concreto que est destinado a actualizar, de modo que su funcionamiento ser especfico a cada tipo de dispositivo ZigBee.

Es por ello que, si se desea desarrollar un bootloader muy potente, capaz de detectar mltiples situaciones de error y protegerse ante ellas (como disponer de un estado radio de recuperacin del dispositivo) ser necesario disponer de mucha memoria y de acceso completo al cdigo fuente de las libreras ZigBee, situacin harto improbable (salvo para el fabricante).

Recientemente, Ember ha incluido dos tipos de bootloader para los chips que suministra (EM250 y EM260 principalmente), el application bootloader y el standalone bootloader.

El application bootloader es un pequeo trozo de cdigo que se compila junto con la aplicacin principal permitiendo la actualizacin remota de dispositivos siempre y cuando

dispongan de una memoria auxiliar integrada (de unas marcas concretas) para el almacenamiento de los nuevos firmwares. Este bootloader ocupar poca memoria Flash pero depender completamente de la aplicacin principal para la obtencin de las nuevas imgenes de firmware mediante la recepcin de paquetes de nivel de aplicacin (que recibir mientras se encuentra activo en la red ZigBee).

Por el contrario, el standalone bootloader es una aplicacin completa (ocupa mucha ms memoria) que se suministra precompilada y que se almacena en el chip de forma separada al programa principal. Esta aplicacin permitir la actualizacin del firmware mediante comandos de bajo nivel (capa de enlace de 802.15.4) a travs de un protocolo simple basado en XModem-CRC. Proveer de un mecanismo de recuperacin (radio y serie) ante situaciones de corrupcin del firmware pero, en cambio, no permitir (al no emplear una memoria auxiliar) el

64

funcionamiento en red del dispositivo mientras est siendo actualizado.

Estos dos ejemplos ilustran la problemtica del escenario: a mayor complejidad del protocolo o proteccin frente a errores, ser necesario el uso de ms memoria y acceso a las libreras internas del protocolo. Adicionalmente, en todos los casos, el funcionamiento de la solucin de actualizacin ser completamente dependiente del hardware a actualizar.

Freescale en cambio, no dispone a priori de un mecanismo inalmbrico de actualizacin de dispositivos, pero anuncia la disponibilidad de un bootloader serie
[30] [31]

, capaz nicamente de

transferir imgenes a un receptor a travs de una comunicacin RS232. Este bootloader no es un mecanismo de actualizacin remota de dispositivos, y se suministra precompilado y hermtico.

Es en este escenario cuando el bootloader objetivo de este proyecto cobra radical importancia, ya que viene a cubrir una funcionalidad esencial de la tecnologa que faltaba por incorporar.

De este modo, en el escenario concreto que representan el chip MC13213, un acceso limitado a los cdigos fuentes de las libreras de Freescale, y los perifricos y la memoria auxiliar incluidos en el ND07, se ha desarrollado un bootloader robusto y eficiente, independiente y compatible con cualquier protocolo inalmbrico (o cableado) que se emplee para recuperar las imgenes del nuevo firmware.

As pues, el bootloader desarrollado en este proyecto permitir a desarrolladores de aplicaciones disponer de un mecanismo de carga remota de dispositivos que sern capaces de seguir funcionando en red mientras reciben la nueva imagen de firmware a travs del protocolo programado (TFTP, X-Modem, propietario, etc.) y dentro del tipo de red seleccionado (802.15.4 o ZigBee).

En los siguientes captulos se desarrollar en profundidad el funcionamiento del bootloader desarrollado y los mecanismos empleados para su depuracin y validacin.

65

Captulo 3 Escenario de Aplicacin y Requisitos

66

3.1.

Introduccin

En este captulo se proceder a describir en primer lugar los requisitos que una red de sensores inalmbricos de bajo consumo impone a la hora de elegir una plataforma hardware concreta.

Posteriormente se plantearn los requisitos que han de satisfacerse para lograr que una aplicacin de actualizacin remota de dispositivos, y en concreto la parte relativa al bootloader, pueda ser instalada con xito en el hardware elegido.

A continuacin se introducir el escenario de aplicacin formado principalmente el dispositivo ZigBee, el microcontrolador que integra, las libreras de Freescale y el entorno de desarrollo que se han seleccionado con el fin de cumplir con los requisitos anteriormente expuestos. En ltimo lugar se introducirn dos protocolos de comunicacin, el bus I2C y el estndar RS232, cuyo estudio ser necesario para la correcta programacin de las aplicaciones que se pretenden desarrollar en este proyecto.

3.2.

Requisitos de una Red de Sensores de Bajo Consumo

Las redes de sensores de bajo consumo representan una subclase especial dentro de las redes de sensores inalmbricos, debido a sus interesantes propiedades y a las limitaciones que imponen.

Como su nombre indica, una de las prioridades de este tipo de redes ser minimizar al mximo el consumo de cada dispositivo de forma que su instalacin represente un ahorro considerable frente a otras soluciones posibles.

Gracias a esta propiedad de bajo consumo, ser posible que la mayor parte de los dispositivos integrantes de la red sean alimentados mediante bateras en lugar de a travs de la red elctrica (ya que la duracin de stas ser lo suficientemente prolongada como para que compense el esfuerzo de cambiarlas o recargarlas peridicamente).

Esto no slo representar una ventaja monetaria, sino que tambin otorgar de mayor flexibilidad y versatilidad al dispositivo, ya que su instalacin ser mucho ms sencilla y no precisar, en la mayora de los casos, de realizar una obra complicada para extender la alimentacin hasta el nuevo emplazamiento del sensor.

Otra propiedad buscada habitualmente en los dispositivos de las redes de sensores de bajo

67

consumo (dependiendo del mercado al que est dirigido el dispositivo) es que sea de tamao reducido y de funcionamiento sencillo, simplificando al mximo el procedimiento de configuracin y el impacto visual que produce en el entorno (algo realmente importante en entornos domticos, por ejemplo).

Se espera que las redes de sensores sean escalables, de forma que un sistema pueda ir incorporando nuevas funcionalidades y mejorando el servicio mediante la inclusin de nuevos dispositivos. Para que esto sea posible, la red deber ser capaz de soportar el funcionamiento de un nmero muy elevado de dispositivos de forma simultnea y el coste individual de stos deber ser reducido.

Adicionalmente, se espera que estas redes sean capaces de proporcionar un sistema seguro y robusto, capaz de asegurar unas comunicaciones fiables y una fuerte proteccin frente a interferencias. Para alcanzar este objetivo ser necesario seleccionar un protocolo capaz de cumplir con dichos requisitos y que precise de una cantidad reducida o moderada de recursos para lograrlo. La especificacin ZigBee ha sido especficamente diseada para ese fin.

De este modo las redes de sensores inalmbricos de bajo consumo dispondrn de una considerable ventaja competitiva frente a otras redes cableadas puesto que el coste unitario de cada dispositivo (al disponer de un hardware muy sencillo su precio debera de ser bajo) y el de instalacin sern considerablemente ms asequibles.

Es por todo esto que las redes de sensores de bajo consumo son atractivas para un conjunto tan variado de sectores como son: la domtica y automatizacin del hogar, entornos socio sanitarios, seguridad de edificios e infraestructuras, monitorizacin del entorno, sensorizacin industrial, control de trfico, aplicaciones militares, y un largo etctera.

No obstante, no todo son ventajas y la reduccin de consumo y tamao de los dispositivos de la red se traducir habitualmente en un aumento de la latencia de las comunicaciones, una reduccin del ancho de banda y un empeoramiento de la calidad de servicio.

El reducido tamao de los dispositivos puede llegar a ser una desventaja para muchas aplicaciones industriales, donde el factor esttico y la alimentacin mediante bateras no son caractersticas determinantes.

Por otro lado, la consecucin del bajo consumo suele implicar el desarrollo de aplicaciones software ms complicadas, capaces de encaminar paquetes dentro de sistemas seguros de alta latencia, debida a que un gran nmero de dispositivos apagar su interfaz radio la mayor parte del tiempo para ahorrar bateras.

68

Se puede concluir pues, que la eleccin de un dispositivo adecuado para funcionar dentro de una red de sensores de bajo consumo suele implicar que disponga de las siguientes caractersticas:

Soporte de un protocolo de comunicaciones inalmbricas robusto, fiable, seguro y relativamente sencillo, para poder programarlo sobre dispositivos de memoria reducida Presente un consumo reducido o disponga de mecanismos para reducirlo la mayor parte del tiempo que dure su vida til Tamao reducido Largo o medio alcance de sus transmisiones de paquetes Sencillez de instalacin y configuracin Bajo coste unitario Fcil de adquirir (muchos dispositivos en fases de desarrollo o productos del mercado son difciles de conseguir sin acuerdos comerciales o un pedido de gran magnitud de por medio)

Como se explicar ms adelante, el dispositivo ND07 de NLaza Soluciones y la plataforma que integra (MC13213 de Freescale) cumplen todos los requisitos expuestos y representarn por ello una base ptima sobre la que desarrollar este proyecto.

3.3.

Requisitos de una Aplicacin de Actualizacin de Firmware

Una vez se dispone de una red de sensores de bajo consumo surge la necesidad de desarrollar un sistema para su adecuado mantenimiento y actualizacin. Estas actualizaciones sern imprescindibles para la correccin de errores y la incorporacin de nuevas funcionalidades.

Desafortunadamente, este proceso de actualizacin puede llegar a ser muy complicado, ya que dichas redes pueden llegar a estar compuestas por centenares o miles de dispositivos, repartidos en todo tipo de reas. Si adems se tiene en cuenta la alta latencia de determinadas comunicaciones, la tarea de identificar los dispositivos a actualizar podra llegar a ser un problema de difcil solucin.

A todo esto han de sumarse aquellos escenarios en los que los dispositivos estn emplazados en localizaciones de difcil acceso, ocultos del pblico (intencionadamente o no), protegidos de agentes externos dentro de cajas de registro, etctera.

Por otro lado, debido a la gran diversidad de sensores disponibles en el mercado, no es posible garantizar la disponibilidad de un mecanismo de actualizacin manual comn a todos los

69

dispositivos que, con el fin de reducir costes, minimizarn la integracin de perifricos al mximo. De este modo es imposible contar con que la mayora de sensores dispondr de un puerto serie RS232, una conexin USB o similar. El nico mecanismo siempre disponible para su configuracin, que sea comn a todos ellos, ser la comunicacin inalmbrica.

De este modo, parece ponerse de manifiesto que la actualizacin manual de los dispositivos ser desaconsejable en casi todos los escenarios posibles. Todo apunta a que la solucin ptima (de existir una) ser siempre una solucin inalmbrica.

Por otro lado, toda aplicacin de actualizacin de software se puede separar en dos partes: el protocolo de carga remota (encargado de obtener el nuevo firmware) y el bootloader (encargado de actualizar la memoria del dispositivo y reiniciarlo).

Puesto que la carga remota bsicamente ser una funcionalidad aadida sobre la aplicacin principal del dispositivo (independiente del hardware sobre el trabaje), su instalacin requerir esencialmente del cumplimiento de ciertos requisitos de espacio libre en memoria y coexistencia con el resto del software del dispositivo. Ninguno de estos requisitos ser necesariamente sencillo de alcanzar puesto que:

La memoria disponible en dispositivos de bajo consumo suele ser un recurso escaso. La coexistencia dentro de un mismo dispositivo entre una aplicacin que requiere la transferencia de un elevado volumen de datos (carga remota) y una aplicacin principal de bajo consumo (que suele apagar la radio para reducir el consumo) suele ser un proceso delicado.

Sin embargo el bootloader, objetivo de este proyecto, al tener una fuerte dependencia con el hardware sobre el que se instale, impondr los mismos requisitos que el protocolo de carga remota ms los adicionales relativos al dispositivo fsico a actualizar. As pues, los requisitos que una determinada plataforma ha de satisfacer para poder instalar adecuadamente un bootloader sobre ella sern los siguientes:

Disponer de una memoria auxiliar con capacidad suficiente como para almacenar una imagen de firmware (a ser posible capacidad para la imagen ms grande que se vaya a generar).

Disponer de un mecanismo de grabacin/recuperacin de dicha imagen sobre/desde la memoria auxiliar (usualmente mediante un protocolo de comunicacin entre circuitos integrados: UARTs, I2C, SPI, etc.).

Disponer de suficiente memoria RAM como para poder leer los datos desde la memoria auxiliar y procesarlos para actualizar el firmware del dispositivo.

70

Disponer de suficiente memoria no voltil (ROM o Flash) para almacenar el cdigo del bootloader junto con el de la aplicacin principal. Disponer de un mecanismo de borrado y sobrescritura de la memoria no voltil (ROM o Flash) en tiempo real de ejecucin. Disponer de un mecanismo software que permita resetear el dispositivo, para as reinicializar automticamente su estado una vez se ha finalizado la actualizacin.

De forma equivalente, las caractersticas que presentan las redes de sensores de bajo consumo as como el hardware y el software de los equipos que las conforman, determinarn en gran medida el diseo final del bootloader. As pues, el desarrollo adecuado de la aplicacin del bootloader sobre un modelo de dispositivo concreto depender de:

Las libreras del protocolo inalmbrico instalado (ZigBee y 802.15.4, a efectos de este proyecto). La documentacin disponible sobre ellas y la posibilidad de modificarlas o acceder a sus fuentes.

La secuencia de arranque de los diversos componentes del chip y la posibilidad de emplazar el bootloader dentro de ella. El funcionamiento de los diversos mdulos que integra el dispositivo y el funcionamiento de las libreras que los controlan. La posibilidad de funcionar de forma transparente al resto de las aplicaciones programadas en el dispositivo (coexistiendo con ellas sin afectarlas negativamente). Esto depender principalmente del acceso que se disponga al sistema operativo del microprocesador integrado.

Adicionalmente, dada la naturaleza del escenario de aplicacin, el bootloader deber perseguir siempre los siguientes objetivos:

Minimizar el consumo de memoria (RAM y ROM) y de capacidad de proceso en el desempeo de todas sus funciones. Minimizar su impacto sobre el resto de aplicaciones del dispositivo. De esta forma el bootloader ser ms escalable y flexible (pudindose modificar el mecanismo de carga remota en un momento dado, sin alterar el bootloader).

Dado el escenario de aplicacin descrito y todos los requisitos impuestos por los componentes involucrados en el sistema, es necesario poner nfasis en que el nmero de soluciones posibles depender exclusivamente de los parmetros anteriormente enumerados.

A lo largo de este proyecto se demostrar que, empleando ZigBee como protocolo inalmbrico de bajo consumo y los dispositivos ND07 como soporte hardware de la aplicacin, es posible desarrollar una solucin robusta de bootloader que cumpla con los requisitos expuestos.

71

3.4.

Dispositivo NLaza NDimension ND07

El mdulo ND07, de la familia de productos domticos NLaza NDimension, es un dispositivo diseado para funcionar como coordinador de red ZigBee capaz de inicializar una red inalmbrica y de gestionarla mediante los comandos recibidos a travs de una comunicacin serie RS232.

La aplicacin ms habitualmente programada en el ND07 permitir configurar los dispositivos pertenecientes a la red que ha generado y se encargar de almacenar los datos emitidos por stos (principalmente sensorizaciones) para despus comunicarlos al exterior va RS232 hacia una aplicacin compatible.

De este modo, cuando el ND07 se programe para integrarse dentro de una red ZigBee que cumpla el perfil de automatizacin del hogar (HA), lo ms habitual ser que acte como un dispositivo de Interfaz Combinado (HA Combined Interface). Esto quiere decir que funcionar principalmente como una pasarela entre la red ZigBee y otra red o aplicacin externa, facilitando la comunicacin entre ambas mediante una comunicacin serie RS232.

As pues, las principales caractersticas del dispositivo son las siguientes:

Incorpora la plataforma MC13213 de Freescale integrada en la PCB. Dispone de una memoria auxiliar externa EEPROM AT24C512 de 64KB. Puerto Serie RS232 con conector DE-9 hembra. Antena fractal omnidireccional capaz de emitir en la banda de frecuencias sin licencia de 2,4GHz. Incluye un pulsador para resetear el dispositivo y otro configurable. Integra un indicador LED para notificar el estado de la aplicacin. Presenta un consumo muy reducido. Alimentacin mediante transformador a 4,5v. Dispositivo pequeo, portable e intuitivo.

Dispositivo NLaza NDimension ND07 (con caja) A continuacin se proceder a describir con mayor detalle sus especificaciones.

72

3.4.1. Especificaciones Elctricas y Mecnicas [32]

El ND07 es un dispositivo de consumo reducido diseado para funcionar como coordinador de una red ZigBee, de forma que requerir de un suministro de corriente constante proveniente de la red elctrica.

De este modo, sus principales especificaciones se resumirn en la siguiente tabla: Parmetro Tensin de Alimentacin Tensin de Alimentacin (por pines de la placa) Frecuencia de Portadora Alcance Consumo Medio Velocidad de Transmisin RS232: Bits de Datos RS233: Bits de Paridad RS233: Bits de Parada RS233: Control de Flujo Dimensiones
[VII] [VI] [IV]

Condicin

Valor Mnimo 3.3 2.5 2405 25

Valor Tpico 4.5 [I] 2.7 [II] 2475 [III] 30 60[V] 4800 8 0 1 Hardware 71x66x28

Valor Mximo 6.5 2.7 2480 35

Unidades V V MHz m mA baudios bits bits bits mm

[I]: Tensin continua de salida del adaptador. [II]: Este modo de alimentacin carece de circuito de proteccin y puede daarse el dispositivo permanentemente. No se recomienda emplearlo salvo por desarrolladores expertos mientras dure el proceso de programacin y depuracin. [III]: Frecuencia del canal 25 de 802.15.4/ ZigBee. Puede llevar cualquiera de los 16 canales posibles configurado de fbrica. [IV]: Alcance medido en condiciones de espacio libre y en canal 25. [V]: Consumo medio medido en situacin estable, con el dispositivo asociado a la red ZigBee. [VI]: Aunque el microcontrolador MC13213 junto con el chip MAX3232 integrado soportan velocidades serie superiores, sta es la velocidad media recomendada para una ptima coexistencia con la aplicacin ZigBee. [VII]: Es imprescindible habilitar el control de flujo Hardware en la aplicacin externa que recibe las tramas enviadas por el ND07 para asegurar un correcto funcionamiento.

73

Como puede observarse en la siguiente imagen, aunque el ND07 es un dispositivo de dimensiones reducidas, ha sido diseador para ser muy intuitivo y cmodo a la hora de desarrollar aplicaciones para l:

Placa ND07 con el chip MC13213 Cuando el ND07 se presenta con su encapsulado habitual, el LED luminoso y los pulsadores sern accesibles mediante unos pequeos orificios situados en la parte posterior de la caja.

El ND07 dispone de un conector serie DE-9 hembra para conectarse al puerto serie de un ordenador (a travs de una comunicacin RS-232) mediante un cable apropiado. El patillaje ser el siguiente:

Patillaje del conector DE-9 hembra del ND07

El dispositivo se conectar a la red elctrica mediante un adaptador a 4.5 voltios en escenarios normales de operacin. Sin embargo, mientras dure el proceso de desarrollo y depuracin, ser necesario alimentarlo a travs de los pines de la placa mediante una fuente de alimentacin regulada a 2,7 voltios.

74

Adicionalmente, el ND07 dispone integrado en placa de una memoria EEPROM de 64KB (AT24C512 de Atmel) que permitir el almacenamiento dinmico de datos no voltiles en tiempo de ejecucin. Este chip se comunicar con la plataforma MC13213 mediante un bus I2C, y se conectarn tal y como se presenta en la siguiente figura:

Esquema de Conexionado MC13213 y AT24C512 mediante bus I2C

Como puede observarse del esquema anterior, el conexionado de los pines A0, A1 y A2 de la memoria EEPROM AT24C512 fijar la direccin de este integrado dentro del bus I2C.

La hoja de especificaciones de la EEPROM indica que el pin A2 debe dejarse al aire, sin conectar, y que sern los pines A0 y A1 los nicos que influirn en la direccin I2C final del dispositivo.

Puesto que ambos pines estn conectados a tierra, los dos bytes menos significativos de la direccin del AT24C512 sern cero. Los 5 bytes ms significativos restantes los fuerza el propio dispositivo al valor 10100 (en binario).

De este modo la EEPROM empleada en el ND07 dispone de la direccin binaria I2C 1010000 (7 bits en binario) dentro del bus. Este dato ser fundamental ms adelante en el desarrollo del proyecto para direccionar correctamente el integrado.

75

3.4.2. Plataforma MC13213 System-On-Chip de Freescale

La caracterstica ms destacable de un dispositivo ZigBee ser sin duda alguna el microcontrolador que integra, ya que ser ste el que definir los protocolos inalmbricos que se podrn instalar y los perifricos que se podrn controlar.

De este modo, a efectos de este proyecto, ser imprescindible dedicar tiempo al estudio de la plataforma MC13213 (ya los mdulos que incluye), ya que ser la base del funcionamiento del ND07 de NLaza Soluciones.

La solucin MC13213 de Freescale es una plataforma ZigBee de segunda generacin que incorpora un transceptor radio de baja potencia en la banda de frecuencias de 2,4 GHz y un microcontrolador de 8 bits todo dentro de un encapsulado de 71 pines y dimensiones de 9x9x1 mm. La combinacin de estos dos componentes dentro del mismo chip de reducidas dimensiones permite obtener un producto muy verstil, sencillo y de coste reducido.

Esta plataforma puede ser empleada para desarrollar productos que van desde simples aplicaciones propietarias que permitan conectividad punto a punto hasta soluciones completas ZigBee de red mallada conformes a la especificacin.

As pues, las aplicaciones ms habituales para las que se suele emplear el MC13213 incluyen escenarios de automatizacin residencial o comercial, control industrial, socio sanitarios y bienes de consumo.

Este chip ha sido especficamente diseado con la intencin de albergar aplicaciones basadas en los protocolos 802.15.4 y ZigBee mediante las libreras 100% compatibles (MAC y BeeStack) suministradas por Freescale. Adicionalmente provee soporte para otras libreras de SMAC (Simple MAC), SynkroRF y ZigBee RF4CE.

Una de sus caractersticas ms destacables es que contiene un transceptor radio capaz de operar en la banda de frecuencias sin licencia de 2,4GHz, en diecisis canales distintos y con una potencia de salida regulable.

Este transceptor radio incluye un amplificador de bajo ruido, un switch integrado de transmisin/recepcin, regulacin de la alimentacin de la placa, y la capacidad de codificar y decodificar seales de espectro ensanchado. La potencia nominal de salida ser de 1mW.

La plataforma tambin contiene un microcontrolador basado en la familia de MCUs HCS08 que dispone de 60KB de memoria Flash y 4KB de memoria RAM. Este controlador tendr la

76

suficiente capacidad como para que la pila de comunicaciones y la aplicacin desarrollada residan ambas dentro del mismo encapsulado (System in Package, SiP).

De este modo, en la arquitectura del MC13213 se pueden distinguir dos bloques claramente diferenciados, el mdem radio (802.15.4) y el microcontrolador de 8 bits 9S08GB60. Dicha distincin de bloques y los mdulos incluidos en cada uno pueden apreciarse en la siguiente figura:

Diagrama de bloques de la plataforma MC13213 [33]

A la vista de esta figura, se pueden enumerar pues las caractersticas ms representativas de la MCU contenida en la plataforma MC13213:

Microcontrolador alimentado mediante voltajes de 2 a 3.4 voltios, que dispone de una CPU HCS08 de bajo consumo a 40 MHz. 60KB de memoria Flash (permite su borrado y regrabado en tiempo real mediante un nico valor de alimentacin) con capacidades de proteccin y securizacin de bloques. Permite hasta 100.000 ciclos de borrado y reprogramacin en condiciones tpicas. El mdulo software NVM (explicado en el captulo 4) permitir emplear esta memoria Flash adicionalmente para el almacenamiento de datos de contexto no voltiles.

4KB de memoria RAM securizable. Mltiples modos de bajo consumo (3 modos de hibernacin y uno de espera). Interfaz SPI conectado internamente al mdem 802.15.4. Diversos temporizadores hardware de 16 bits altamente configurables.

77

Puerto con capacidad de configurar interrupciones KBI (interrupciones de teclado). Conversor analgico-digital (ADC) de 8 canales configurables de 8 a 10 bits. 2 Interfaces para comunicaciones serie independientes. Permitirn configurar al menos una UART para la comunicacin RS232 con el exterior. Mltiples fuentes de reloj posibles: generado a partir del reloj interno (243kHz), generado a partir de un cristal externo u oscilador, generado a partir del reloj del mdem (muy preciso), mediante el reloj de arranque (~8MHz), etc.

Interfaz I2C a 100kbps de velocidad. Permitir comunicar la plataforma MC13213 con la memoria auxiliar externa EEPROM integrada en el ND07. Potente interfaz hardware para la programacin y depuracin de cdigo sobre el chip. Implementado mediante el mdulo DBM (Background Debug Module). Mecanismos hardware para la proteccin del sistema: interrupcin programable para la deteccin de cadas de la alimentacin (Low Voltage Interrupt, LVI), temporizador watchdog (COP), detectores de comandos ilegales (que permitirn resetear el dispositivo va software), etc.

Hasta 32 lneas de entada/salida de propsito general configurables. Circuito de reset hardware.

De forma anloga, se pueden resumir las principales caractersticas del mdem radio:

Transceptor 100% compatible con el estndar 802.15.4 capaz de emitir datos a modulados mediante O-QPSK, una velocidad de 250kbps, sobre 16 canales de 5 MHz en la banda de 2,4GHz, y empleando tcnicas de espectro ensanchado.

Potencia de salida nominal de -1 a 0dBm, programable de -27dBm a 3dBm. Sensibilidad menor de -92dBm con un 1% de PER (ante paquetes de 20 bytes). Conmutador integrado para las lneas de transmisin y recepcin. Posibilidad de configurar diferentes lneas para la transmisin y para la recepcin de paquetes (funcionamiento dual). Posibilidad de acoplarle a esas lneas etapas de amplificadores de potencia y amplificadores de bajo ruido.

Soporta tres modos de bajo consumo para el ahorro de bateras. Salida de reloj de frecuencia configurable (que habitualmente se emplear como fuente externa para la generacin del reloj de referencia de la MCU). Modos configurables de emisin: chorro de bits (stream) y paquetes (packet). 7 lneas de entrada/salida de propsito general adicionales.

Puesto que los mdulos anteriormente enumerados son demasiado numerosos como para que todos sean explicados en profundidad en esta memoria, se dedicarn los primeros apartados del captulo 4 para la descripcin detallada de slo aquellos que estn directamente relacionados con el desarrollo del bootloader y del cargador RS232.

78

A partir de la descripcin general de los mdulos integrados en la plataforma MC13213, as como las caractersticas del ND07, parece ms que evidente que este dispositivo ser idneo para el desarrollo y depuracin de las aplicaciones de este proyecto, ya que:

Dispone de una memoria auxiliar EEPROM, con capacidad suficiente como para almacenar imgenes firmware (ver apartado 4.1.3), que se comunicar con el microcontrolador mediante un bus I2C (mdulo que integra la plataforma MC13213).

Dispone de suficiente memoria RAM y ROM como para que sea instalable en la mayora de las aplicaciones ZigBee generables a parir de las libreras de la BeeStack 1.0.5 (ver subapartados 3.6 y 3.7).

La memoria no voltil del dispositivo permite su borrado y sobrescritura en tiempo de ejecucin y las libreras de la BeeStack 1.0.5 suministran un API con ese fin. El MC13213 soporta un mecanismo para la deteccin de comandos invlidos que resetea el dispositivo (otorgando la capacidad de reinicializar el ND07 mediante comandos software).

Las libreras suministradas para 802.15.4 y ZigBee otorgan un considerable acceso a las capas inferiores del protocolo y a la secuencia de arranque del dispositivo (aunque no suministran las fuentes de cdigo de las libreras) facilitando pues el desarrollo de una aplicacin de bajo nivel altamente dependiente del hardware como es el bootloader.

Adicionalmente, es importante destacar que en el momento en que se comenz el desarrollo de este proyecto, Freescale suministraba abundante documentacin para todos los componentes hardware y software de esta plataforma, adems de un servicio tcnico va web.

3.4.3. Configuracin del Dispositivo (Funcionamiento y Desarrollo)

Una vez seleccionado el mdulo ND07 como dispositivo ZigBee sobre el que se desarrollarn las aplicaciones del bootloader y del cargador RS232 (aunque todava se justificar an ms esta decisin en los siguientes subapartados), ser necesario estudiar las diferentes configuraciones de los dispositivos implicados que se observarn a lo largo del proyecto.

As pues, cabe distinguir principalmente dos escenarios: funcionamiento normal del dispositivo (con las aplicaciones instaladas en el firmware) y funcionamiento de test (mientras dure el proceso de desarrollo y depuracin de las aplicaciones en memoria).

79

El primer escenario presenta la configuracin ms sencilla: el ND07 se alimentar a travs de la red elctrica mediante un transformador a 4,5 voltios y se conectar su salida RS232 al puerto serie de un ordenador mediante el cable adecuado.

En este caso, la alimentacin se suministrar al dispositivo a travs de su conector especfico accesible desde el exterior de su caja (jack NEB 21 R con pin de 1.95mm). Esta entrada estar protegida y soportar variaciones moderadas del valor de la alimentacin.

La imagen siguiente muestra la configuracin de los dispositivos implicados:

Escenario 1: Funcionamiento normal del ND07 (sin caja) Este escenario ser habitual durante las ltimas fases del proceso de desarrollo y en instalaciones de campo reales.

Ocasionalmente se incluir en el sistema un sniffer para la captura de tramas radio que permita comprobar el correcto funcionamiento del protocolo ZigBee programado en el ND07.

El segundo escenario ser el que se observar ms habitualmente a lo largo del proceso de desarrollo y requerir de la inclusin de varios dispositivos adicionales que permitan la correcta alimentacin, programacin y depurado del ND07.

En primer lugar ser necesario adquirir al menos un USB MultiLink (suministrado dentro de los kits de desarrollo de Freescale) e instalar sus drivers en el ordenador que se emplear para desarrollar las aplicaciones.

80

El USB MultiLink es un dispositivo que permitir la programacin y depuracin de aplicaciones programadas para las placas de desarrollo de la plataforma MC13213 de Freescale a travs de su mdulo DBM.

USB MultiLink Este dispositivo se combinar habitualmente con el depurador (debugger) integrado dentro del IDE CodeWarrior for Microcontrollers a para disponer de un entorno grfico, potente y flexible, para la bsqueda y eliminacin de errores.

Sin embargo, el MultiLink dispone de un conector que no es directamente compatible con el ND07 y que requiere pues de un dispositivo intermedio.

Este dispositivo, llamado programador/depurador NLaza-Freescale, requerir a su vez de una alimentacin externa que se lograr acoplando una fuente de alimentacin regulada a 2,7 voltios.

Programador/Depurador NLaza-Freescale De este modo, siempre que se desee programar o depurar aplicaciones del ND07, ser necesario conectar el programador/depurador NLaza-Freescale a los pines de la placa (PCB),

81

accesibles slo mediante la apertura de la caja del dispositivo. El programador/depurador se conectara a su vez a un USB MultiLink y se alimentar mediante a 2,7 voltios constantes.

Desafortunadamente, con el objetivo de minimizar el nmero de componentes del ND07 (y por tanto el precio total del dispositivo), la placa no dispone de ningn tipo de circuito de proteccin desde los pines ni de un mecanismo de regulacin de tensin adecuado.

As pues, es imprescindible respetar la polaridad de los pines del programador/depurador y mantener la alimentacin externa en torno a los 2,7 voltios (aproximadamente) o de lo contrario es posible daar el dispositivo de forma permanente.

De forma anloga al primer escenario, para el correcto funcionamiento de la aplicacin del cargador RS232, ser necesario conectar la salida DE-9 hembra del ND07 al puerto serie de un ordenador.

Una vez este escenario est preparado, el CodeWarrior permitir programar y depurar aplicaciones sobre el ND07 de forma potente y verstil.

Las siguientes imgenes muestran la configuracin y conexin de los dispositivos habitualmente implicados en el segundo escenario:

Escenario 2: Desarrollo y depuracin (serie y radio)

82

De igual forma que en el primer escenario, ocasionalmente se incluir un sniffer radio para capturar las tramas emitidas por el dispositivo y as evaluar su correcto funcionamiento.

Escenario 2: Desarrollo y depuracin (serie y radio) Finalmente, es necesario hacer hincapi en que ambos escenarios son incompatibles ya que alimentar los dispositivos implicados simultneamente mediante dos mecanismos diferentes (red a 220 voltios y fuente de alimentacin continua a 2,7 voltios) puede daar los equipos de forma permanente.

3.5.

Entorno de Desarrollo: CodeWarrior for MicroControllers v5.1

El CodeWarrior es el entorno de desarrollo integrado (IDE) suministrado por Freescale para la programacin de aplicaciones destinadas a funcionar sobre los microcontroladores de la familia HC(S)08 [34].

La plataforma MC13213 integrada en el ND07 pertenece a dicha familia, de modo que ser el CodeWarrior el IDE elegido para desarrollar los firmwares de este proyecto.

83

Como todo entorno de desarrollo que se precie de serlo, el CodeWarrior for MicroControllers incluye un conjunto de herramientas imprescindibles para trabajar de forma eficiente:

Un compilador configurable para microcontroladores de la familia HC(S)08. Un ensamblador (assembler) y un enlazador (linker) considerablemente configurables Un depurador (debugger) capaz de programar la memoria flash de dispositivos y controlar la ejecucin de sus aplicaciones con el fin de buscar y corregir errores. Para su correcto funcionamiento es necesario instalar previamente un perifrico

programador/depurador llamado USB MultiLink. Un entorno de programacin amigable con potentes opciones de bsqueda de funciones, adecuada navegacin entre ficheros del proyecto y con coloreado de sintaxis para cdigo en C (syntax highlighting).

La siguiente captura de pantalla muestra el entorno de desarrollo tal como se presenta a un programador de aplicaciones destinadas a la plataforma MC13213:

Captura de pantalla del IDE CodeWarrior for Microcontrollers v5.1. [35]

El CodeWarrior dispone adems de la capacidad de importar proyectos generados con la herramienta BeeKit (ver apartado siguiente), de forma que es posible comenzar a programar firmware de dispositivos a partir de aplicaciones de ejemplo previamente configuradas en dicha

84

herramienta.

Esto

acelerar

drsticamente

el

proceso

de

desarrollo

reducir

considerablemente el time-to-market del producto.

Esta propiedad del CodeWarrior se emplear tambin en este proyecto ya que la aplicacin del Cargador RS232 (ver captulo 4.2) se programar modificando una aplicacin de ejemplo de interfaz combinado (HA Combined Interface) generada con el BeeKit.

A lo largo del desarrollo de este proyecto, el IDE del CodeWarrior tambin ha ido evolucionando, partiendo desde la versin 3.1 (plagada de errores) hasta la versin 6.2, la ltima publicada.

Sin embargo, las versiones posteriores a la versin 5.1, otorgaban soporte para muchos nuevos chips y las licencias adquiridas no eran compatibles. De este modo, la mayor parte del tiempo se ha trabajado con la versin 5.1 que, an presentando algunas limitaciones y errores, es un IDE bastante potente y robusto.

Es necesario remarcar que el CodeWarrior es un IDE considerablemente flexible y robusto, mejor que otros entornos evaluados de la competencia. Por ejemplo, el IDE suministrado por Ember para desarrollar aplicaciones para su chip EM250 (que sera el equivalente aproximado al MC13213 en cuanto a prestaciones) es con diferencia mucho menos amigable para el programador.

Este entorno de Ember, llamado Xide, carece de las funcionalidades bsicas necesarias para la navegacin sencilla entre funciones y ficheros y adems su compilador es menos de la mitad de eficiente que el incluido en el CodeWarrior (de modo que un firmware requerir del doble de memoria flash para ser almacenado en el caso de Ember que en el caso de Freescale).

As pues, se concluye que la herramienta CodeWarrior for MicroControllers v5.1 cumplir todos los requisitos de robustez, potencia y flexibilidad necesarios para desarrollar adecuadamente las aplicaciones objetivo de este proyecto.

3.6.

Generacin de Aplicaciones ZigBee de Ejemplo: Beekit

BeeKit es una herramienta que provee de un interfaz grfico de usuario (GUI) mediante el cual un usuario puede crear, modificar, guardar y actualizar soluciones inalmbricas basadas en las pilas de protocolos suministradas por Freescale. Una de sus caractersticas ms atractivas es que incluye un asistente que permite al usuario configurar rpidamente los parmetros de una aplicacin antes de generar el proyecto,

85

reduciendo considerablemente configurndolos manualmente.

la

necesidad

de

navegar

entre

ficheros

individuales

Captura de pantalla de la ventana principal del BeeKit Wireless Connectivity Toolkit [36] Mediante el amplio repositorio de libreras de comunicaciones inalmbricas, plantillas y aplicaciones de ejemplo que el Beekit incluye, el usuario podr generar los ficheros adecuados para su entorno de trabajo que sern despus importados desde el IDE del CodeWarrior para continuar su desarrollo y depurado. Los proyectos de ejemplo generados con esta herramienta suelen ocupar entre 45KB y 55KB de memoria Flash y unos 3,5KB de memoria RAM, dependiendo de la configuracin elegida. Esto significa que el desarrollador dispondr habitualmente de menos de 1KB de memoria RAM y de 5KB a 15KB de memoria Flash para programar sus modificaciones de la aplicacin principal (incluyendo el bootloader, para el caso de este proyecto). BeeKit es una aplicacin fcilmente escalable diseada para dar soporte a nuevas libreras y funcionalidades segn se van publicando.

86

Aunque la descarga de esta aplicacin incluye una licencia para el uso ilimitado de las libreras de SMAC y 802.15.4, la licencia de la pila BeeStack (para ZigBee, ver apartado siguiente) caducar a los 90 das y ser necesario adquirirla si se desea seguir utilizando la herramienta. No obstante, puesto que BeeKit es una herramienta ideada para acelerar el desarrollo continuo de nuevas aplicaciones, no debera ser necesario su uso una vez se haya configurado y generado la aplicacin plantilla sobre la que se desarrollar el bootloader y el cargador RS232. Esta plantilla ser, a efectos de este proyecto, un ejemplo de un coordinador ZigBee programado sobre una aplicacin de interfaz combinado, del perfil de automatizacin del hogar (HA Combined Interface). Desafortunadamente, a lo largo del proceso de desarrollo del bootloader, se han sucedido actualizaciones crticas de la librera BeeStack que slo eran accesibles mediante la descarga e instalacin completa del BeeKit, de forma que si se deseaba corregir los errores e incluir las posibles mejoras era de nuevo imprescindible adquirir una licencia. De este modo, a lo largo del desarrollo de este proyecto ha sido necesario instalar las sucesivas versiones del BeeKit segn se iban publicando para as evaluar las nuevas libreras de 802.15.4 y ZigBee que inclua. Esto ha representado por lo menos una actualizacin cada dos meses desde principios del 2007 (versin 1.0.0) hasta principios del 2008, cuando Freescale dej de publicar revisiones de la pila de ZigBee 2006 (ver apartado 4.1.6). La ltima revisin publicada a da de hoy es la versin 1.9.10 (septiembre 2009), e incluye soporte para las libreras de los protocolos SMAC, ZigBee, ZigBee PRO, RF4CE y SynkroRF, adems de para los perfiles Home Automation y Smart Energy.

3.7.

Librera ZigBee 2006 de Freescale: BeeStack 1.0.5.

3.7.1. Introduccin
Tras numerosos retrasos en su publicacin, la especificacin pblica ZigBee 2006 finalmente vio la luz en diciembre de ese mismo ao. Desafortunadamente, an fue necesario esperar varios meses para disponer de las primeras libreras ZigBee 2006 compatibles con el chip MC13213 de Freescale: la BeeStack 1.0.0.

Sin embargo, las libreras 802.15.4 para dicha plataforma llevaban ya ms de un ao en el mercado y sirvieron para ir familiarizndose con las capas que lo conforman (es necesario recordar que ZigBee 2006 se basa en el nivel fsico y de acceso al medio del estndar IEEE 802.15.4-2003) y con el entorno de desarrollo comn CodeWarrior for Microcontrollers.

87

A principios del ao 2007 se publicaron pues la primera versin de las libreras y, slo un par de meses ms tarde, su primera revisin, la BeeStack 1.0.1.

Fue poco despus cuando Freescale decidi incluir las actualizaciones de la librera ZigBee 2006 dentro de una nueva herramienta diseada para generar aplicaciones de ejemplo de automatizacin del hogar mediante ZigBee 2006 y su protocolo propietario, SMAC. Dicha herramienta recibira el nombre de BeeKit (ver apartado anterior) y requerira de una licencia adicional para poder acceder a las actualizaciones.

De este modo, a partir de mediados del ao 2007, Freescale publicara una revisin de las libreras 802.14.5 y ZigBee cada 4 meses aproximadamente para las que era necesario descargarse e instalar una nueva versin del BeeKit, generar un proyecto de una aplicacin de ejemplo similar a la que se estaba empleando, portar sus libreras y comprobar que el API no haba sufrido cambios significativos (desafortunadamente, esto no siempre sucedera).

Este ltimo paso requerira del empleo de aplicaciones de comparacin de ficheros como el WinMerge
[20]

y de una considerable comprensin del funcionamiento de todo el API de la

BeeStack para poder aplicar correctamente las actualizaciones del cdigo.

De este modo, la BeeStack sufrira modificaciones de mayor o menor importancia hasta poco antes del verano del ao 2008, cuando se averiguara a travs de conversaciones con el servicio tcnico de Freescale, que la compaa abandonaba todo soporte a las libreras ZigBee 2006 para destinar sus esfuerzos al desarrollo de las libreras de ZigBee PRO (BeeStack 2.0.0 en adelante).

De este modo, la BeeStack 1.0.5 (ltima revisin obtenida) ser la versin ms estable publicada de las libreras ZigBee 2006 para el chip MC13213 y, por tanto, la base sobre la que se fundamentar este proyecto.

En el siguiente subapartado se describir pues la arquitectura de capas que conforman la BeeStack 1.0.5 y el API suministrado para la programacin del bootloader y el cargador RS232, objetivos finales de este proyecto.

En ltimo lugar se incluir una descripcin de los errores encontrados en las libreras a lo largo del desarrollo del proyecto y los problemas que stos acarrearn.

88

3.7.2. Descripcin de Capas y API

Segn Freescale, el trmino BeeStack se emplear para describir todo el software que se programar en los dispositivos ZigBee destino a excepcin del cdigo especfico de la aplicacin.

La pila BeeStack est formada principalmente por componentes de red, destinados a establecer la conexin y la comunicacin entre dispositivos ZigBee, y por componentes especficos de la plataforma, que proveern a la aplicacin de un interfaz de operacin y acceso al hardware del equipo.

La siguiente figura muestra los mdulos que conforman la pila [35]:

UART

Plataforma de Aplicacin
Objeto de Aplicacin 240 (EP 240) APSDE-SAP Objeto de Aplicacin 1 (EP 1) APSDE-SAP

Temporizadores LED Display LCD

I n t e r f a z

Objeto de Dispositivo ZigBee (ZDO)

(EP 0) APSDE-SAP

Proveedor de Servicios de Seguridad

Subcapa de Soporte a la Aplicacin (APS)

NLDE-SAP

Capa de Red (NWK)

MCPS-SAP MLME-SAP

Plano de Gestin del ZDO

Teclado Mdulo NVM Programador de Tareas (TS)

Capa de Acceso al Medio (MAC)

PD-SAP PLME-SAP

Capa Fsica (PHY) Componentes de la librera ZigBee BeeStack 1.0.5.

El funcionamiento ordenado de todos los mdulos que componen la BeeStack se basa principalmente en la gestin que realiza un programador de tareas (Task Scheduler, TS) que se suministra en cdigo fuente para posibilitar su edicin por el desarrollador.

De este modo, la librera cuenta con que el programador de tareas se encargue de repartir el tiempo de ejecucin de forma equitativa (sin dejar ningn mdulo en estado de inanicin) pero dando mayor prioridad a las capas y componentes ms crticos para el correcto mantenimiento del dispositivo dentro de la red (por lo general los niveles ms cercanos a la capa fsica suelen ser los ms prioritarios).

89

De forma muy parecida pues a la que se definen las diferentes capas funcionales en la especificacin ZigBee 2006, se pueden distinguir las siguientes tareas dentro de la librera BeeStack 1.0.5:

La tarea encargada de la capa de red, responsable del encaminamiento de paquetes, del descubrimiento de rutas, de la transmisin de tramas unicast o broadcast, del envo unicast o broadcast y del descarte de los datos cuyo destino no sea el propio dispositivo o la red a que pertenece.

La tarea encargada de la subcapa de soporte a la aplicacin (APS), responsable de la entrega y recepcin de datos de aplicacin, del establecimiento de bindings entre distintos endpoints y del asentimiento de paquetes extremo a extremo. Adicionalmente se ocupa de realizar todo el proceso de autenticacin en redes securizadas, incluyendo la gestin del centro de confianza en los nodos que sean coordinadores de red ZigBee.

La tarea encargada de la plataforma de aplicacin (AF), responsable de la entrega de indicaciones de datos (data indications) y confirmaciones (data confirms) a los distintos endpoints de las aplicaciones del nodo, segn se vayan recibiendo.

La tarea encargada del objeto de dispositivo ZigBee (ZDO), encargada de mantener y gestionar el estado del dispositivo en la red, as como de los procedimientos de asociacin o abandono ordenado de sta.

Por otro lado, adems de las tareas asociadas a las capas de la especificacin ZigBee, la librera incluye por defecto otras tareas fundamentales para el correcto funcionamiento del protocolo y de los mdulos integrados en el chip MC13213:

La tarea del perfil del dispositivo ZigBee (ZDP), encargada de tratar las peticiones y respuestas para una serie de comandos comunes a todos los dispositivos ZigBee y destinados a gestionar los diversos nodos dentro de la red (por ejemplo consultas de direcciones, servicios disponibles, endpoints activos, etc.).

Las tareas relacionadas con la gestin de los componentes de la plataforma (PLM), encargadas de interactuar con los elementos hardware como pulsadores (mediante polling o interrupciones KBI), LEDs (mediante encendidos, apagados, parpadeos, etc.), displays numricos o grficos (gestin de LCDs) o temporizadores (TMR). Todos los componentes de la PLM pueden ser modificados para cumplir las especificaciones impuestas por el desarrollador.

90

As pues, el rbol de directorios y ficheros que compone un proyecto basado en las libreras de la BeeStack 1.0.5 tambin puede describirse de forma sencilla atendiendo a una clasificacin funcional por capas y mdulos.

Para realizar dicha descripcin nos basaremos en el rbol de directorios generado por el BeeKit al exportar un proyecto de ejemplo de una aplicacin de Interfaz Combinado del perfil de automatizacin del hogar (HA Combined Interface). Esta aplicacin de ejemplo ser la base desde la que se partir para programar el bootloader y el cargador RS232 de este proyecto. La figura siguiente muestra pues el rbol de directorios de una aplicacin ZigBee 2006 habitual, basada en la librera BeeStack 1.0.5:

Directorios y ficheros de la aplicacin HA Combined Interface (BeeStack 1.0.5)

Como puede observarse a primera vista, un proyecto ZigBee 2006 puede dividirse en los siguientes bloques funcionales: Libs, ZigBee, BeeApps, MacPhy, SSM y PLM.

El directorio Libs contiene nicamente una librera necesaria para el funcionamiento de cualquier aplicacin programada en C para este chip.

El directorio ZigBee, como su nombre indica, contiene la librera ZigBee 2006 especfica del tipo de dispositivo elegido (dispositivo final, router o coordinador) y los interfaces (API) entre la

91

capa de aplicacin y el resto de capas de la arquitectura ZigBee (red, soporte de aplicacin, ZDO, etc.).

El directorio BeeApps contendr pues todos los ficheros relacionados con la aplicacin principal que se ejecutar en el dispositivo. De este modo incluir todo el cdigo relacionado con los endpoints, el ZDO, la ZigBee Cluster Library (ZCL, necesaria para los perfiles), con el tipo de dispositivo elegido dentro del perfil de automatizacin del hogar (HA) y con la aplicacin ZigBee principal en general. El directorio MacPhy contendr las libreras y el API correspondientes a las capas de acceso al medio (MAC) y fsica (PHY) basadas en 802.15.4 que sern necesarias para el correcto funcionamiento del protocolo.

El directorio SSM contendr el programador de tareas (TS) y el interfaz necesario para poner en marcha una herramienta especial de Freescale empleada para depurar el funcionamiento de las comunicaciones entre las diferentes capas de la BeeStack: la ZigBee Test Client (ZTC).

Finalmente, el directorio PLM contendr todos aquellos ficheros que estn relacionados con la gestin de un mdulo del chip, un componente hardware, o un perifrico del dispositivo. De este modo, este directorio incluir el API para: la UART, los temporizadores software, el mdulo NVM (para almacenamiento de datos no voltiles), el mdulo de bajo consumo (LPM), los LEDs, los pulsadores (Keyboard), el display (LCD) as como todos los parmetros para su correcta inicializacin y configuracin.

Adicionalmente, este directorio incluir todos los ficheros relacionados con el arranque del dispositivo, de modo que un estudio en profundidad de su cdigo ser necesario para la correcta inclusin del bootloader dentro de la secuencia de arranque del equipo.

Puesto que el API para establecer, asociarse y mantener una red ZigBee est debidamente incluido en la BeeStack, la funcin principal de un desarrollador de aplicaciones ZigBee habitualmente consistir en modificar tan slo algunos ficheros del directorio BeeApps y del directorio PLM y probablemente incluir algunos nuevos. Rara ser la ocasin en que un programador de aplicaciones necesite modificar ficheros incluidos dentro de los directorios Libs, ZigBee, MacPhy o SSM.

Desafortunadamente, aunque el cargador RS232 realmente no requerir trabajar con directorios adicionales, el bootloader es lo suficientemente intrusivo como para que sin requerir de la modificacin de ficheros alojados en directorios diferentes al PLM o al BeeApps, s que requerir de un conocimiento profundo acerca del funcionamiento de todos sus mdulos para evitar cualquier tipo de colisin (ver captulo 4 para las conclusiones sobre cada mdulo).

92

Es necesario recordar que el bootloader no se comportar nunca como un programa de la capa de aplicacin ZigBee, sino como un componente del propio sistema operativo que se ejecutar antes incluso que el programador de tareas.

El API de comunicaciones ZigBee incluido en la BeeStack 1.0.5 es muy extenso y se sale del mbito de esta memoria. No obstante ser necesario disponer al menos de unas nociones acerca de su funcionamiento para la programacin del cargador RS232, para lo cual se recomienda la lectura de las referencias [35], [37] y [38] de la bibliografa.

3.7.3. Bugs Conocidos y Reconocidos por Freescale

Desde la primera librera de ZigBee 2006 que public Freescale para el chip MC13213 a principios del ao 2007 hasta que dej de darle soporte a mediados del 2008, se han ido detectando y subsanando un considerable nmero de errores crticos de la pila que hacan que sta no cumpliese la especificacin ZigBee (paradjicamente todas sus versiones han obtenido la certificacin ZigBee 2006).

A lo largo de este proyecto se detectarn casi una decena de errores de las libreras y de las aplicaciones de ejemplo suministradas por Freescale. De este modo el escenario de aplicacin del bootloader habr de considerarse como un entorno en constante supervisin y perfeccionamiento, con la inestabilidad ocasional que eso en ocasiones representa.

Ser necesario pues familiarizarse con el servicio tcnico de Freescale, con el que habr que ponerse en contacto en numerosas ocasiones para identificar, reportar y obtener soluciones de contingencia para los errores detectados.

Aunque muchos de estos errores eran de extrema gravedad para el correcto funcionamiento del protocolo ZigBee y su compatibilidad con otros dispositivos que cumpliesen el estndar, slo se ha descubierto uno de ellos que afectase directamente al bootloader.

Este error grave consistir en que el envo de tramas radio con asentimiento (ACK) desde la aplicacin provocar que un flag interno de la pila se quede activado indefinidamente.

Este flag (denominado mNvCriticalSectionFlag dentro de las libreras) est diseado para bloquear la actualizacin peridica automtica de los datos no voltiles almacenados en el mdulo NVM (de estar habilitado dicho componente) mientras tenga lugar cualquier otra operacin prioritaria que consuma muchos recursos. El componente NVM se explicar ms adelante en el apartado [Link].5.

93

Esto se debe a que la operacin de actualizacin de los datos almacenados en la NVM es una operacin lenta y crtica, que no debe interrumpirse en la medida de lo posible.

Al provocarse este error, y el flag nunca desactivarse, las variables almacenadas en la NVM nunca se actualizarn y el dispositivo ser incapaz de mantener eficientemente su contexto dentro de la red (direcciones de hijos, asociaciones, etc.).

De este modo el almacenamiento del flag de actualizacin del bootloader, que idealmente se habra localizado dentro de las pginas reservadas para la NVM (cosa ms que lgica), tendr que portarse a la EEPROM. Esto representar una considerable prdida de eficiencia ya que ser imprescindible la inicializacin del API de comunicacin I2C durante el arranque del dispositivo para consultar el flag de regrabacin en EEPROM, cuando de haber estado en la NVM su lectura habra resultado inmediata.

Este problema (que a fin de cuentas tiene una solucin sencilla), fue considerablemente difcil de detectar por la aleatoriedad de su aparicin y represent una considerable cantidad de tiempo perdido durante el proceso de depurado del bootloader aplicado a situaciones reales (con dispositivos ZigBee funcionando en red). La ineficiencia y lentitud del servicio tcnico de Freescale (ver apartado 4.1.5) tambin influyeron negativamente en la deteccin del error.

Aunque este error fue descubierto fruto del desarrollo de este proyecto y se notific a Freescale a travs de su servicio tcnico, ste tard muchos meses en reproducir el problema y reconocerlo pblicamente. Poco despus se anunciaba el cese de soporte a las libreras ZigBee 2006 por parte de Freescale para centrar sus esfuerzos en las nuevas libreras de ZigBee PRO. Probablemente sea sta la razn por la que la ltima versin de las libreras ZigBee 2006 publicadas, la BeeStack 1.0.5, carezca del parche necesario.

As pues, para las aplicaciones ZigBee 2006 de Freescale, la NVM ser siempre un recurso inestable de dudosa fiabilidad. Aunque una vez migrado el flag de regrabacin a la EEPROM este bug dejar de ser un problema a efectos del bootloader, s que lo seguir siendo para todas las aplicaciones ZigBee 2006 que transmitan paquetes radio con asentimientos, como es el caso del cargador RS232 de este proyecto.

De este modo, siempre que se disee una aplicacin que emplee las libreras de la BeeStack 1.0.5 o inferiores, ser necesario elegir entre la transmisin de asentimientos o el almacenamiento de datos no voltiles mediante el mdulo NVM.

Suponiendo que las libreras ZigBee PRO incluyesen el parche buscado, sera necesario migrar las aplicaciones a nueva pila (BeeStack 2.0.0 en adelante) la cual, desafortunadamente,

94

precisa de tanta memoria RAM y Flash que no suele haber suficiente disponible en el MC13213 (a menos que la aplicacin ZigBee sea muy sencilla, incapaz de enrutar paquetes).

Estas nuevas libreras se han programado evidentemente pensando en otros chips ms modernos de Freescale que disponen de mayor capacidad, de forma que los dispositivos que integren el chip MC13213 slo podrn actuar como ZEDs (dispositivos finales, que requieren de mucha menos memoria) si desean funcionar dentro de una red ZigBee PRO 100% compatible sin bugs.

No obstante, la evaluacin inicial de dichas libreras ZigBee PRO y la lectura de los foros de discusin de Freescale sugiere que su publicacin ha sido demasiado precipitada (y por ello de baja calidad) debido principalmente a razones comerciales. Esta apreciacin parece confirmarse cuando se observa que en menos de un ao se han publicado demasiadas revisiones de la librera, migrando desde la BeeStack 2.0.0 hasta la BeeStack 3.0.5 (septiembre 2009).

De este modo se puede concluir que, debido a la naturaleza de las libreras ZigBee de Freescale, que proporcionan un API para un protocolo novedoso an en constante evolucin, el proceso de desarrollo de las aplicaciones requeridas para este proyecto implicarn no slo la programacin de cdigo, sino tambin la frecuente deteccin, aislamiento, notificacin y correccin de bugs dentro de las pilas suministradas.

95

3.8.

Bus I2C (Inter-Integrated Circuit) y TWI (Two Wire Interface)

IC es un bus de comunicaciones serie desarrollado por Philips en 1992 capaz de alcanzar velocidades hasta 3.4 Mbit/s (aunque su modo estndar, el ms ampliamente extendido, proporciona una velocidad de 100Kbit/s). Es importante resaltar que esta velocidad de bit no ser la velocidad de transferencia efectiva de datos, que puede llegar a ser menos de la mitad, ya que tambin se transmiten las cabeceras del protocolo, los bits de asentimiento, las direcciones de dispositivo y registro destino, etctera. Este bus est muy extendido en la industria, que lo emplea principalmente para comunicar microcontroladores con sus perifricos en sistemas integrados (Embedded Systems) o incluso para comunicar entre s circuitos integrados que coexisten en la misma placa de silicio. ste ltimo caso ser justo uno de los principales objetivos de este proyecto: comunicar mediante un bus I2C la plataforma MC13213 y la memoria EEPROM AT24C512 integradas ambas en la placa del dispositivo ZigBee NLaza ND07. Esta comunicacin habr de permitir la lectura de las imgenes de firmware almacenadas en la EEPROM con el fin de actualizar la aplicacin que se encuentra en ejecucin. I2C es la base de otros protocolos como pueden ser: [Link] El interfaz VESA Display Data Channel (DDC) System Management Bus (SMBus) Power Management Bus (PMBus) Intelligent Platform Management Bus (IPMB)

Estos buses se basan en I2C pero definen algunos de sus parmetros y comandos de forma especfica para el objetivo que quieren lograr. Es habitual que trabajen con rangos diferentes de voltaje y frecuencia e incluso empleen lneas adicionales de interrupcin.

3.8.1. Diseo de Referencia

I2C emplea dos lneas para transmitir la informacin: una para los datos (lnea SDA) y otra para la seal de reloj (lnea SCL). Este bus emplea adicionalmente una tercera lnea como referencia del sistema, que ser tierra (lnea GND). En casos como en el ND07, en que los componentes integrados que desean comunicarse mediante el bus I2C comparten la misma placa (y masa), esta tercera lnea no ser necesaria. Las lneas SDA y SCL son salidas de drenador abierto, lo cual significa que necesitan una resistencia de polarizacin en el drenador para funcionar. Esto suele ser muy til en situaciones

96

en que se pretende comunicar circuitos lgicos cuyos niveles altos son distintos. En el caso del ND07, su circuito integra una resistencia de pullup de 10K para cada lnea hasta la tensin regulada Vcc=2.5V. El nmero mximo de dispositivos que pueden estar conectados simultneamente al mismo bus est limitado por el espacio de direcciones y por la capacitancia total de la lnea que no debe de superar los 400 pF. En el caso del ND07 esto no supone ninguna limitacin ya que slo existen dos integrados conectados va I2C, el microcontrolador y la memoria EEPROM, y se encuentran separados tan slo unos centmetros. El siguiente esquema ilustra el esquema de un sistema interconectado mediante bus I2C:

Ejemplo de conexionado de un bus I2C con resistencias de pull-up [39] Los dispositivos conectados al bus I2C suelen funcionar como maestros o como esclavos, o incluso alternar dichos comportamientos (si el dispositivo posee esa funcionalidad) y para ello disponen de una direccin nica que los identifica unvocamente (de 7 bits en las versiones habituales y hasta de 10 bits en las versiones ms modernas del bus). Adicionalmente, I2C es un bus multimaestro, lo que significa que permite la existencia de mltiples dispositivos conectados al mismo bus empleando el rol de maestro. Un dispositivo, ya sea maestro o esclavo (o pueda funcionar con cualquiera de los dos roles), intercalar a lo largo de su vida til dos modos posibles de funcionamiento: modo transmisin y modo recepcin. Cuando un dispositivo desea iniciar una comunicacin, se convierte en maestro (en modo transmisin), genera la seal de reloj sobre la lnea SCL y transmite los datos sobre la lnea SDA. El receptor de esta transferencia ser pues, un dispositivo esclavo funcionando en modo recepcin. Para iniciar una transmisin, un dispositivo maestro enviar por la lnea SDA un patrn llamado start condition (bit START, explicado ms adelante) seguido de los 7 bits de direccin del dispositivo (en casos de direcciones de slo 7 bits, como en el ND07) con el que se quiere comunicar y luego un bit adicional que indicar su propsito de escribir (a 0) o leer (a 1) del esclavo.

97

Si existe un dispositivo con esa direccin, ste responder con un bit ACK (un bit a 0) en el siguiente nivel alto de reloj (lnea SCL). Esto provocar que el dispositivo maestro contine en modo transmisin (si ha solicitado una escritura sobre el dispositivo esclavo) o pase a modo recepcin (si ha solicitado leer del dispositivo esclavo). Obviamente el dispositivo esclavo pasar al modo de transmisin/recepcin complementario al del maestro. Los bytes enviados mediante el bus I2C se transmitirn de forma que el bit ms significativo se enviar primero y el bit menos significativo el ltimo. Esto se aplicar tanto para bytes de direcciones como para bytes de datos. Existen dos tipos especiales de bit empleados para indicar el inicio (bit de START) o fin (bit de STOP) de una transmisin. El bit de START se indica mediante una transicin de nivel alto a nivel bajo de la lnea SDA cuando la lnea SCL se encuentra a nivel alto. El bit de STOP se indica mediante una transicin de nivel bajo a nivel alto mientras el reloj (SCL) se encuentra a nivel alto.

Condiciones START y STOP de una transmisin I2C [40] Si el transmisor desea escribir ms de un byte sobre el dispositivo esclavo le basta con seguir transmitiendo bytes despus de cada bit de ACK recibido del esclavo. Cuando el dispositivo maestro desee finalizar el proceso de escritura le bastar con emitir un bit de STOP despus del ltimo ACK recibido. Si el dispositivo maestro desea leer ms de un byte del dispositivo esclavo le basta con emitir un bit de ACK despus de cada byte de datos recibido, lo que indica su deseo de continuar con la lectura. Una vez ledo el ltimo byte deseado, el maestro contestar con un bit de STOP en lugar de un ACK para finalizar la lectura. El dispositivo maestro puede, en un momento dado, querer mantener el control de bus para realizar una nueva transferencia de datos (un mensaje combinado). Para ello, en lugar de enviar un bit de STOP enviar un nuevo bit de START (procedimiento de START repetido).

As pues, I2C define tres tipos bsicos de mensaje, cada uno de los cuales comienza con un cdigo de START y termina con un cdigo de STOP:

98

Mensaje simple de escritura desde dispositivo maestro a esclavo Mensaje simple de lectura de dispositivo esclavo (enviado desde dispositivo maestro) Mensajes combinados, en los que el dispositivo maestro realiza dos o ms lecturas y/o escrituras a uno o varios dispositivos esclavos.

En un mensaje combinado, despus del envo del primer bit de START y de un mensaje normal, se envan nuevos bits de START (repetidos) no precedidos previamente de un bit de STOP. Esto permite informar a los dispositivos receptores que toda la transferencia de datos anterior y futura (hasta que reciban un byte de STOP) pertenece al mismo mensaje. Llegados hasta este punto, es importante mencionar que es habitual que cada dispositivo esclavo estrictamente compatible con I2C responda nicamente a mensajes particulares definidos en su hoja de producto. Esto es debido a que ni I2C ni TWI definen la semntica de los mensajes, tales como pueden ser el significado de los bytes transmitidos en los tramas. Esta semntica ser especfica de cada producto o fabricante. As pues, en la prctica, la mayor parte de los dispositivos esclavos adoptarn un modelo de peticin/respuesta, en donde uno o dos bytes transmitidos despus de un comando de escritura, se tratarn como una direccin (por ejemplo un registro de una memoria) o un comando. Esos bytes determinarn cmo se tratarn los siguientes datos emitidos para escritura o cmo habr de responder el esclavo ante las siguientes lecturas.

3.8.2. Capa Fsica

En el bus I2C, forzar una salida a tierra se considera un cero lgico mientras que dejar la lnea SDA flotante a Vcc se considera un uno lgico. Este sistema permite un control de acceso al canal: cuando un dispositivo quiere escribir un uno lgico en la lnea de datos, ha de dejar el hilo flotando y despus comprobar que no sigue a masa; de estar a tierra, significar que ha habido colisin con otro dispositivo maestro que ya estaba utilizando el bus. No obstante, este suceso es poco probable puesto que todo maestro que ha ledo un cdigo START de la lnea de datos SDA, no trata de acceder al canal hasta que escucha un STOP. As pues esto slo suceder en el caso de que dos dispositivos empiecen a emitir simultneamente y se traducir en que uno de los dos detectar este suceso y dejar de transmitir (prdida de arbitraje) pero el otro seguir como si nada hubiese sucedido (y sus datos no perdern integridad). Este mecanismo de escritura en un canal y posterior comprobacin del nivel de ste puede ser empleado en las dos lneas del bus con distintos objetivos:

99

En la lnea del reloj (SCL) un dispositivo actuando como esclavo puede mantener a nivel bajo el reloj para indicar que necesita tiempo para procesar los datos que ha recibido hasta ahora. De este modo el dispositivo maestro ha de esperar hasta que el esclavo libere la lnea para seguir envindole datos. A este mecanismo de control de flujo para los dispositivos esclavos se le denomina Clock Stretching.

En la lnea de datos (SDA) como sistema de deteccin de colisin. Aqu este procedimiento (denominado arbitraje) asegura que slo existe un transmisor de datos en la lnea cada vez.

Las transiciones de nivel para los bits en el canal de datos (SDA) han de realizarse siempre mientras la lnea de reloj (SCL) est a nivel bajo (ver figura siguiente). Las transiciones que tengan lugar mientras el reloj se encuentre en nivel alto (Vcc) se interpretarn como los cdigos de START (transicin de nivel alto a bajo de SDA) y STOP (transicin de nivel bajo a alto).

Transiciones de nivel en la lnea SDA [40]

3.8.3. I2C vs. TWI

El Interfaz TWI (Two Wire Interface) es esencialmente el mismo bus I2C implementado en diversos procesadores system-on-chip diseados por Atmel y otras compaas. As pues es compatible con el diseo de referencia y capa fsica I2C descritos en los apartados anteriores. Muchos fabricantes emplean el nombre TWI en lugar de I2C debido a cuestiones de licencias de copyright. A da de hoy, el bus I2C se ha convertido en un estndar de facto y ya no es necesario adquirir licencias para emplearlo. A efectos de este proyecto, el ND07 integra en su placa la plataforma MC13213 de Freescale, que dispone de un controlador serie I2C, y la EEPROM de Atmel AT24C512, cuya hoja de producto especifica que se comunica mediante un bus TWI. Las pequeas diferencias que podran existir entre I2C y TWI se daran sobre todo en lo relativo a las velocidades mximas que es capaz de alcanzar el bus I2C en sus ltimas revisiones (que an no incorpora o ratifica TWI). Adicionalmente, aquellos dispositivos incapaces de adoptar

100

todas las especificaciones del bus I2C se considerarn a s mismos como adoptantes del bus TWI en lugar del I2C. No obstante la EEPROM AT24C512 otorga una velocidad mxima de 400 Kbit/s (mediante la alimentacin suministrada en placa) de modo que a efectos de este proyecto TWI e I2C representarn el mismo concepto. As pues, a lo largo de este documento se emplear siempre la nomenclatura I2C en lugar de TWI para referirse al bus por ser de entre los dos el bus ms extendido y conocido en el mercado (pero se referirn siempre al mismo tipo de bus).

3.8.4. I2C en el AT24C512

El bus empleado para comunicar el microcontrolador MC13213 de Freescale y la EEPROM AT24C512 de Atmel es compatible con la definicin de bus I2C (o TWI) estudiado anteriormente. Sin embargo la EEPROM, como ya se ha sugerido con antelacin para muchos dispositivos esclavos, emplea una semntica especfica para modificar o acceder mediante el bus I2C a los datos que almacena. As pues, el microcontrolador deber seguir los siguientes pasos para comunicarse con la EEPROM dependiendo de si se desea leer o escribir sobre sta:

[Link].

Escritura sobre la EEPROM AT24C512

El microcontrolador (que actuar siempre como dispositivo maestro) comienza la comunicacin enviando un bit START. Esto alertar a la EEPROM esclava, ponindola a la espera de una transaccin.

El maestro se dirige al dispositivo con el que quiere comunicarse (la EEPROM), enviando un byte que contiene los siete bits que componen su direccin (en el caso del ND07, la EEPROM tiene la direccin 1010000. Ver apartado 3.5), y el octavo bit de menor peso que se corresponde con la operacin deseada: en este caso escritura (bit a 0).

La direccin enviada es comparada por la EEPROM con su propia direccin y, si ambas coinciden, la memoria se considera direccionada como dispositivo esclavoreceptor (ya que el bit R/W indicaba escritura).

La EEPROM responde enviando un bit de ACK que le indica al microcontrolador que sta reconoce la solicitud y que est en condiciones de comunicarse. A continuacin el microcontrolador enviar la posicin de memoria de la EEPROM sobre la que quiere escribir (puesto que es una memoria de 64KB esta direccin ser de 2 bytes).

101

El dispositivo esclavo responder con un bit de ACK despus de cada byte de posicin de memoria correctamente recibido. Ahora el microcontrolador puede empezar a escribir bytes de datos sobre la posicin de memoria de la EEPROM auxiliar y sus posiciones consecutivas. Todos los bytes de datos deben constar de 8 bits y el nmero de bytes que pueden ser enviados en una misma transmisin no debe superar el mximo especificado por el dispositivo destino. En el caso de la EEPROM AT24C512 este mximo se sita en 128 bytes. Por encima de ese nmero los datos se sobrescribirn sobre s mismos.

Cada byte escrito por el dispositivo maestro debe ser obligatoriamente reconocido por un bit de ACK por la EEPROM. Cuando la comunicacin finaliza, el maestro transmite un bit de STOP para dejar libre el bus. Despus del bit de STOP, es obligatorio para el bus estar inactivo durante unos microsegundos.

Escritura secuencial I2C en memoria [41]

[Link].

Lectura de la EEPROM AT24C512

Para leer posiciones de memoria almacenadas en la EEPROM AT24C512 es preciso que el microcontrolador realice previamente una peticin de escritura sobre el bus indicando la posicin de memoria sobre la que se desea efectuar la adquisicin de datos. As pues, para realizar lecturas de la EEPROM es imprescindible realizar previamente los seis primeros pasos descritos en el apartado anterior correspondientes a la escritura de datos sobre la memoria.

Una vez informada la EEPROM acerca de la posicin de su memoria sobre la que se desea trabajar, sta responder con un bit de ACK y esperar que los datos que se enven a continuacin sirvan para sobrescribir la posicin de memoria apuntada.

Es en este momento en que el microcontrolador vuelve a emitir un bit de START (START repetido) indicando que se trata de un mensaje compuesto y que pretende leer en lugar de escribir sobre la memoria.

Para ello, despus del bit de START repetido, el microcontrolador vuelve a enviar a la EEPROM un byte con su direccin y con el bit R/W indicando modo lectura (bit a 1).

102

La EEPROM responde enviando un bit de ACK que le indica al microcontrolador que sta reconoce la solicitud y que est en condiciones de enviar las lecturas solicitadas. A continuacin la EEPROM proceder a enviar bytes sucesivamente partiendo de la posicin de memoria fijada previamente al principio de la comunicacin. El microcontrolador asentir cada byte de datos enviando un bit ACK hasta que no desee leer ms (esta lectura puede durar indefinidamente), momento en que no enviar el bit de ACK (o lo que es lo mismo enviar un bit de NACK) y despus transmitir un bit de STOP para finalizar la comunicacin y dejar libre el bus.

Despus del bit de STOP, es obligatorio para el bus estar inactivo durante unos microsegundos.

Lectura I2C de un nico byte concreto en memoria [41]

Lectura I2C secuencial de bytes en memoria [41] As pues, concluida la introduccin acerca del funcionamiento del bus I2C, nos encontraremos en el escenario adecuado para afrontar el desarrollo del interfaz de comunicacin entre el ND07 y su memoria EEPROM a travs del mdulo I2C de la plataforma MC13213.

Una vez concluido dicho interfaz, se emplear para el almacenaje y posterior lectura de imgenes de firmware destinadas a actualizar la memoria del ND07.

103

3.9.

Estndar RS232

El estndar RS-232 (Recommended Standard 232) define una interfaz para el intercambio serie de datos binarios entre un DTE (equipo terminal de datos) y un DCE (equipo de comunicacin de datos).

Aunque fue publicado por la EIA (Electronic Industries Alliance) en los aos sesenta, el estndar ha sufrido pocas modificaciones y an se emplea habitualmente en los puertos serie de ordenadores. La revisin ms extendida es la RS-232C (1969) y la ltima que se ha publicado es la RS-232E.

Las recomendaciones publicadas por la ITU (International Telecommunication Unit) ITU-T V.24 junto con la ITU-T V.28 son equivalentes al RS232.

El estndar define los siguientes parmetros:

Caractersticas elctricas de las seales transmitidas: niveles de voltaje, velocidad, temporizaciones y forma de las seales, mxima capacitancia de la lnea, etctera. Caractersticas mecnicas del interfaz: conectores e identificacin de pines. Funcin de cada circuito del conector.

Sin embargo, deja abiertas cuestiones como:

Codificacin de los caracteres (ASCII, EBCDIC, etc.) Formato de tramas en el flujo de datos: bits por carcter, bits de inicio/fin (cuando se realizan comunicaciones asncronas), bits de paridad, etc. Protocolos para la deteccin de errores o algoritmos para la compresin de datos Velocidades de transmisin de bits (que actualmente pueden llegar a superar los 115,200 bps)

Habitualmente parmetros como la codificacin de los caracteres o la velocidad de transmisin son controlados por el hardware del puerto serie, que suele ser un circuito integrado que implementa una UART capaz de convertir un determinado trfico de datos en paralelo a un flujo serie asncrono de bits.

Por otro lado, una etapa especial en los extremos de la comunicacin se encargar de adecuar los niveles lgicos de voltaje que emplea la UART a los niveles de seal que emplea RS232.

104

A continuacin se presenta un esquema de la comunicacin serie RS232 que tendr lugar entre el PC y el ND07, a travs del chip MAX3232 que integra. A su vez, el chip MC13213 se comunicar con el integrado MAX3232 a travs de su UART (mediante seales TTL).

Comunicacin RS232 entre un PC (DTE) y el chip MAX3232 (DCE) integrado en el ND07

RS232 soporta la transmisin sncrona y asncrona de datos y, puesto que el estndar define diferentes circuitos fsicos unidireccionales para transmitir bits desde el DTE hacia el DCE y viceversa, el interfaz provee de una comunicacin full-duplex.

A continuacin se describirn los parmetros de la comunicacin que el estndar RS232 estipula.

3.9.1. Niveles de Voltaje

El estndar RS232 estipula una serie de parmetros relacionados con los niveles de voltaje y con los circuitos de adaptacin de las seales que se resumirn a continuacin.

Un uno binario se denominar marca (mark) y se representar por un voltaje de -3 a -15 voltios.

Un cero binario se denominar espacio (space) y se representar por un voltaje de +3 a +15 voltios.

Cualquier voltaje entre -3 y +3 voltios se considerar invlido. Las seales de control sern activas a nivel bajo. Esto quiere decir en este caso que se activarn mediante seales con un voltaje de +3 a +15 voltios.

Mientras no se enven datos la seal se debe mantener en estado de marca (un uno lgico, conocido tambin como RS-232 idle state)

Se soportar un voltaje mximo de 25 voltios en circuito abierto.

Debido a que los voltajes empleados son muy superiores a los niveles lgicos empleados habitualmente por circuitos integrados, suele ser necesario emplear circuitos especiales de

105

adaptacin (drivers) que realizarn dicha transformacin de niveles. Adicionalmente, se encargarn de suministrar la corriente necesaria a los circuitos para asegurar la correcta transmisin de seales y protegern al sistema frente a cortocircuitos y frente a efectos transitorios del interfaz.

En la imagen siguiente puede apreciarse un ejemplo de transmisin de un byte a travs de una comunicacin RS232 que cumple los requisitos anteriormente mencionados:

Ejemplo de transmisin del carcter K (0x4B) con 8 bits de Datos, 1 de Parada y 1 de Start

Una limitacin del estndar es que, debido a que ambos extremos de la comunicacin dependen de compartir una tierra comn, pueden llegar a darse problemas de transmisin cuando el DTE y el DCE se encuentren muy alejados, e incluso generarse bucles de masa (corrientes indeseadas en un conductor entre dos puntos que se presuponen al mismo voltaje).

3.9.2. Conectores y Seales

Aunque el estndar define dos tipos de dispositivos (el DTE y el DCE) para poder distinguir el sentido de las seales de cada circuito, no requiere el uso de un conector determinado (pero recomienda el DB-25).

106

Por lo general (aunque existen excepciones), los equipos clasificados como DTEs (terminales, ordenadores, etc.) dispondrn de conectores machos con las funciones de los pines asociadas a dicha clasificacin. Por otro lado, los equipos clasificados como DCEs (mdems, etc.) dispondrn de conectores hembras y su correspondiente identificacin de pines.

Aunque el estndar define 20 lneas de seal diferentes, los sistemas ms habituales slo emplean un grupo reducido de stas, de modo que se han popularizado muchos conectores diferentes como son: DB-25, DE-9, EIA/TIA 561, Yost, etc. A efectos del escenario de aplicacin de este proyecto, se espera que el ordenador conectado con el ND07 adopte el rol de DTE y disponga de un puerto serie con conector DE-9 macho para acoplarse al ND07 mediante un cable RS232 estndar (ya que el ND07 actuar siempre como DCE y dispone de un conector DE-9 hembra). De este modo, las seales implementadas ms habitualmente en los conectores sern las siguientes:

Pin (DE-9) 1 2 3

Seal Carrier Detect Receive Data Transmitted Data Data Terminal Ready Signal Ground Data Set Ready Request To Send Clear To Send Ring Indicator

Etiqueta DCD RxD TxD

Descripcin Empleada por el DCE para indicar que se ha establecido una conexin con un equipo remoto Datos del DCE al DTE Datos del DTE al DCE Empleada por el DTE para indicar que est listo para conectarse. Esta seal se emplea para sacar al DCE de estados de hibernacin. Tierra del circuito Empleada por el DCE para indicar que est alimentado y listo para recibir conexiones y transmisiones de datos Empleada por el DTE para notificar al DCE su deseo de transmitirle datos Empleada por el DCE para asentir el RTS y permitir al DTE comenzar a transmitirle datos Empleada por el DCE para indicar al DTE que tiene una llamada

DTR

5 6 7 8 9

G DSR RTS CTS RI

Seales / pines de un conector serie RS232 DE-9

La revisin RS232-E del estndar contempla un funcionamiento especial (simtrico) para los pines CTS y RTS denominado RTS/CTS handshaking, en el que se define una nueva seal,

107

Ready to Receive (RTR), sobre el circuito RTS de forma que tanto el DTE como el DCE pueden permitir o denegar la recepcin de datos.

3.9.3. Configuracin
As pues, se puede concluir que el estndar RS232 especifica una serie de parmetros (la capa fsica) de la comunicacin entre un DTE y DCE y recomienda el uso de una serie de conectores y protocolos sobre sus pines. Sin embargo, queda claro que el resto de parmetros de la comunicacin: empleo de seal sncrona o asncrona (y con ella, si procede, el nmero de bits de inicio y parada), velocidad de transmisin, codificacin de caracteres (nmero de bits de datos y paridad), control de flujo (hardware, mediante las lneas CTS/RTS o software, mediante los caracteres especiales Xon y Xoff), etctera.

A lo largo de este proyecto se emplear siempre una comunicacin serie RS232 entre un PC (DTE) y un ND07 (DCE) asncrona, de 19200 baudios, con 8 bits de datos, un bit de parada y sin bit de paridad. Adicionalmente ser necesario configurar el uso de control de flujo hardware sin CTS/RTS handshaking.

108

Captulo 4 Bootloader y Aplicaciones Auxiliares

109

4.1.

Bootloader

En este captulo se tratar principalmente de explicar el trabajo desarrollado para lograr programar el bootloader, objetivo ltimo de este proyecto, as como la aplicacin ZigBee cargador RS232 que permiti depurar y validar el correcto funcionamiento de ste.

De este modo, el primer paso a dar ser definir ms profundamente el concepto de bootloader y su alcance, facilitando as la comprensin de los pasos efectuados para completar su diseo (los cuales se desarrollarn a lo largo del resto de aparatados de este captulo).

A continuacin, ser imprescindible dedicar varios subapartados a describir todos aquellos componentes hardware del MC13213, mdulos de las libreras ZigBee y caractersticas del firmware en general cuyo funcionamiento afecta directamente al bootloader de un modo u otro. De cada uno de estos apartados se concluirn decisiones de diseo y especificaciones de configuracin (que se programarn en el cdigo definitivo) que sern imprescindibles para desarrollar un bootloader flexible que sea instalable en aplicaciones ZigBee.

Inmediatamente despus, se estudiar el formato de datos empleado por las imgenes de firmware (registros S19) y basndonos en l se disear el formato ptimo que se emplear para almacenar las mismas en la memoria auxiliar EEPROM mientras dure el proceso de una actualizacin (o distribucin de imgenes). Una vez ms, este diseo condicion el modo en que se implementaron las aplicaciones finales del bootloader y del cargador RS232.

Posteriormente, estudiados ya todos los elementos relacionados con el proyecto, se proceder por fin a describir la arquitectura y el funcionamiento de los bloques que conforman la aplicacin desarrollada, demostrando el cumplimiento de las especificaciones requeridas como bootloader, objetivo ltimo de este proyecto.

Dentro de este subapartado ser necesario incluir tambin el trabajo realizado que ha sido necesario para otorgar a la aplicacin del bootloader de las propiedades de flexibilidad, robustez e independencia de la aplicacin principal ZigBee que eran requisitos imprescindibles de diseo. Fruto de este trabajo se desprenden los subapartados de validacin de la actualizacin, configuracin del compilador y del linkador, traduccin del cdigo a ensamblador, etctera.

Para concluir el apartado, se han incluido tambin las restricciones de diseo y trabajo adicional que el servicio tcnico de Freescale y la publicacin de actualizaciones de libreras han representado para alcanzar el objetivo final buscado. .

110

4.1.1. Introduccin: Conceptos Bsicos

Un cargador de arranque (boot loader en ingls) es un programa sencillo diseado exclusivamente para preparar todo lo que necesita el sistema para funcionar pero que no suele disponer de todas las funcionalidades de un sistema operativo. Normalmente se utilizan los cargadores de arranque multietapa, en los que varios programas pequeos se suman los unos a los otros, hasta que el ltimo de ellos carga el sistema operativo. En los ordenadores modernos, el proceso de arranque comienza con la CPU ejecutando los programas contenidos en la memoria ROM en una direccin predefinida (se configura la CPU para ejecutar este programa, sin ayuda externa, al encender el ordenador). El ltimo de estos programas se encargar de cargar el sistema operativo propiamente dicho y de transferirle el control. El proceso de arranque se considera completo cuando el ordenador est preparado para contestar a los requerimientos del exterior. El tpico ordenador moderno arranca en, aproximadamente, un minuto (del cual, 15 segundos son empleados por los cargadores de arranque preliminares y, el resto, por el cargador del sistema operativo), mientras que los grandes servidores pueden necesitar varios minutos para arrancar y comenzar todos los servicios. En cambio, la mayora de los sistemas empotrados deben arrancar casi instantneamente ya que, por ejemplo, esperar un minuto para poder ver la TV se considera inaceptable. Por ello, tienen el sistema operativo grabado en la ROM o memoria Flash, gracias a lo cual puede ejecutarse de forma casi instantnea. Este es el caso de los dispositivos ZigBee con los que se ha desarrollado este proyecto. Sin embargo, en los entornos de redes de sensores ZigBee del mercado, es bastante habitual encontrarse el trmino bootloader en las hojas de producto de libreras y de dispositivos referenciando a la capacidad de que disponen de actualizar su firmware en tiempo de ejecucin (principalmente de forma inalmbrica). De este modo, es comn que se confunda el proceso de arranque de un dispositivo con el conjunto formado por el protocolo de carga remota de dispositivo (OTAP [18]) y el Bootloader. Las libreras ZigBee que Freescale suministra para la plataforma MC13213 (integrada dentro del dispositivo ZigBee NLaza ND07, sobre el que se desarrolla este proyecto) proveen de un cargador de arranque bsico que carece de la funcionalidad de actualizacin del firmware del equipo. Adicionalmente, este cargador de arranque (diseado para funcionar sobre placas de desarrollo de Freescale) ha de ser modificado para contemplar todas las funcionalidades adicionales que implica la integracin del microcontrolador MC13213 junto con los diversos perifricos del dispositivo NLaza ND07.

111

El objetivo final de este proyecto ser modificar el cargador de arranque ya existente, introducindole una etapa adicional capaz de detectar si se encuentra almacenado nuevo firmware listo para sustituir al actual y, si es as, realizar dicho reemplazo. Ser esta nueva etapa pues, la que de ahora en adelante denominaremos Bootloader. El modo en que el nuevo firmware es transmitido hasta el dispositivo a actualizar y la forma en que se comprueba su integridad para luego almacenarse en la memoria auxiliar quedan pues fuera del alcance de este proyecto.

En cambio, el formato del firmware almacenado en la memoria auxiliar s ser otro objetivo de diseo de este proyecto ya que su definicin y optimizacin son fundamentales para el entendimiento entre la aplicacin principal, encargada de recibir y almacenar la nueva imagen, y el bootloader, encargado de procesarla para actualizar el firmware del equipo.

De este modo, el firmware de una aplicacin sencilla ZigBee dotada de la capacidad de actualizacin de su firmware seguir un esquema similar al de la figura siguiente:

Firmware Dispositivo ZigBee

Aplicacin Principal ZigBee Seccin dependiente del SW

Funcionalidad de Carga Remota (Aplicacin conforme a un determinado protocolo de OTAP)

Control de perifricos

Cargador de Arranque (con Bootloader)

Seccin dependiente del HW

Diagrama funcional del firmware de un dispositivo ZigBee con bootloader Como puede observarse, el cargador de arranque ser distinto segn sea el hardware sobre el que se programe. Por otro lado, el protocolo que la aplicacin principal emplee para recibir el nuevo firmware podr ser desarrollado de forma casi transparente a la electrnica concreta del dispositivo a actualizar.

112

Ser esta propiedad terica del bootloader, su independencia de la aplicacin ZigBee principal y del protocolo de adquisicin de imgenes de firmware, uno de los principales objetivos de diseo que se buscarn a la hora de programarlo. De este modo, la instalacin del bootloader en un dispositivo ZigBee permitir a la aplicacin principal actualizar de forma flexible su firmware, incluso si sta modifica secciones del cargador de arranque o el protocolo de adquisicin de imgenes (o incluso si ste deja de ser inalmbrico).

Es necesario tener en cuenta que el proceso de actualizacin del firmware de un dispositivo plantea un claro inconveniente: la aplicacin no puede sobrescribirse en tiempo de ejecucin. Esto quiere decir que un dispositivo no puede actualizar su memoria paulatinamente segn va recibiendo secciones del nuevo firmware ya que la sobrescritura de sectores de memoria al azar podra provocar que la aplicacin se corrompiese (actualizndose a medias) y el equipo quedase inutilizable.

Para solucionar este problema, la aplicacin principal deber encargarse (cuando proceda) de recibir, comprobar la integridad y almacenar el nuevo firmware completo para despus reiniciar controladamente el equipo (reset ordenado). Ser durante su siguiente secuencia de arranque (antes de reincorporarse a la red ZigBee), cuando el bootloader tomar el control del dispositivo y actualizar completamente su firmware (a excepcin de la pequea seccin de memoria Flash ocupada por el propio bootloader).

Esta actualizacin ser inicializada por el bootloader ante una seal emitida por la aplicacin principal (mediante la activacin de un flag en la memoria auxiliar y el reseteo del equipo) siempre que se haya completado con xito la recepcin y el almacenamiento del nuevo firmware que pretende sustituir al actual. Dicha notificacin desde la aplicacin principal hacia el bootloader mediante un flag en memoria ser lo ms parecido a una comunicacin que se dar entre ambas secciones de cdigo.

Aunque el bootloader ser siempre una funcionalidad muy interesante a instalar en todo dispositivo ZigBee, habitualmente se har uso de l pocas veces a lo largo de su vida til. Es por esta razn que es vital que los recursos que consuma (en trminos de memoria ocupada) sean lo ms reducidos que sea posible. ste ser pues el ltimo objetivo claro de diseo a la hora de programar el bootloader.

4.1.2. Elementos Relacionados con el Bootloader

A lo largo de los subapartados siguientes se explicarn todos aquellos componentes

hardware del MC13213, mdulos de las libreras ZigBee y caractersticas del firmware en general cuyo funcionamiento afecta al bootloader de un modo u otro.

113

De este modo, fruto del estudio de cada componente en particular se extrae al final de cada subapartado una serie de conclusiones: Decisiones de diseo del bootloader para asegurar el funcionamiento buscado. Configuraciones que es necesario programar en el mdulo bajo estudio para asegurar la compatibilidad con el bootloader. Recomendaciones de diseo de aplicaciones ZigBee y configuracin de mdulos del MC13213 para desarrolladores que deseen instalar el bootloader dentro del cdigo programado.

Las conclusiones obtenidas en estos subapartados determinarn no slo el modo en que se disear la aplicacin del bootloader sino tambin los requisitos que habrn de cumplirse en el resto de mdulos para que el funcionamiento de ste sea el ptimo.

[Link].

Mdulos de la Secuencia de Arranque

Como ya se ha mencionado, las libreras ZigBee y 802.15.4 suministradas por Freescale para la plataforma MC13213 incluyen cdigos de aplicaciones de ejemplo diseados para acelerar el desarrollo y el time-to-market de los dispositivos que integren este chip.

Puesto que el dispositivo NLaza ND07 integra en su placa la plataforma MC13213, lo ms lgico ser comenzar a desarrollar las aplicaciones ZigBee para este equipo a partir de los ejemplos suministrados por Freescale (con su correspondiente secuencia de arranque de ejemplo). Es por esto que a lo largo de todo el proyecto se desarrollar un bootloader que se integrar dentro de dicha secuencia de arranque de ejemplo.

Aunque no se explicar concienzudamente cada uno de los elementos implicados en el arranque del dispositivo por no ser ste objetivo del proyecto, ha sido imprescindible estudiar cada uno de ellos por separado para adaptarlos correctamente al hardware concreto del ND07 y para evaluar su posible influencia sobre el correcto funcionamiento del bootloader. Esto se debe a que la configuracin por defecto de los cdigos de ejemplo est preparada para funcionar con placas de desarrollo de Freescale.

No obstante, se han realizado pocas modificaciones de la secuencia de arranque original ya que sta, a excepcin de la configuracin del mdulo I2C y algunos puertos y registros, era considerablemente compatible.

As pues la secuencia de arranque del ND07, antes de la inclusin del bootloader dentro de ella (decisin que se discutir en el apartado [Link].2), seguir los siguientes pasos:

114

PASOS:

_Startup
Configuracin de Registro SOPT para preparar: 1.- El Watchdog 2.- La capacidad de dormir el dispositivo 3.- El pin de grabacin (BKGD) Inicializacin de la pila Inicializacin de los Parmetros Hardware: 1.- Frecuencia del reloj y calibracin 2.- Frecuencia del mdem radio y calibracin 3.- Direccin MAC del dispositivo 4.- Tipo de antena acoplada (dual o simple) 5.- Potencia mxima de emisin por canal de frecuencia Ajustada la frecuencia del reloj interno (SCM) Inicializacin de la RAM: 1.- Poner a cero el espacio disponible. 2.- Inicializar variables locales. 3.- Copiar a RAM desde ROM el valor inicial de todas las variables globales. Inicializacin de la plataforma: Configuracin de puertos GPIO Inicializacin de la plataforma: 1.- Configuracin del interfaz SPI para comunicarse con el mdem. 2.- Inicializacin Transceptor Radio. Configuracin Reloj del Sistema: 1.- Configuracin reloj del mdem. 2.- Generacin de reloj de sistema a partir del reloj del mdem. Inicializacin de las capas fsica y MAC de la librera 802.15.4

9 10 11 12

Inicializacin gestor de Tareas Inicializacin Temporizadores Software Inicializacin de las capas de Red y Aplicacin ZigBee (BeeStack) Ejecucin del Gestor de Tareas y de la Aplicacin ZigBee Principal
Pasos de la secuencia de arranque de una aplicacin ZigBee

115

Como puede deducirse del esquema anterior, la secuencia de arranque del ND07 comprende principalmente la inicializacin de diversos mdulos del MC13123 mediante la configuracin de registros concretos de la memoria Flash.

El orden de los elementos dentro de la secuencia no es arbitrario y se debe principalmente a los siguientes factores:

Existen mdulos, como el encargado de la proteccin de sectores de la memoria o el watchdog, que requieren ser configurados en las primeras etapas del encendido del dispositivo.

La inicializacin de la memoria voltil, compuesta por la pila (memory stack) y el resto de la RAM, es un paso que ha de ser dado previo a la ejecucin de cualquier aplicacin que haga uso de variables y constantes.

Cuanto ms tarde se inicialice un mdulo ms expuesto estar a sufrir posibles interrupciones por parte de otros mdulos ya inicializados. Es por ello que las operaciones crticas tendern a inicializarse lo antes posible dentro de la secuencia de arranque, hacindolas razonablemente independientes del resto de la aplicacin (esto se aplicar tambin al bootloader).

La configuracin de los puertos de entrada/salida (GPIO) no es prioritaria pero deber de realizarse sin duda antes que la inicializacin de los mdulos que pretendan hacer uso de ellos.

La plataforma MC13123 puede generar su reloj de referencia empleando para ello diversas fuentes, sin embargo la mayor parte de ellas requieren de un periodo de estabilizacin y sincronizacin previo a su uso. Es por ello que para poder arrancar el equipo, la plataforma emplea inicialmente como reloj del sistema una seal interna de baja precisin y frecuencia. De este modo slo aquellos mdulos que no requieran de una precisin muy rigurosa o alta velocidad podrn inicializarse en las primeras fases del arranque.

Lo ms habitual ser que, para aumentar la frecuencia y precisin del sistema, a lo largo del arranque se vaya preparando un reloj de referencia alternativo (empleando para ello una seal externa como un cristal o la salida del modem radio) y se comience a utilizar poco antes de otorgarle el control a la aplicacin principal. De este modo, todos los mdulos que requieran de velocidad de proceso y de un sistema estable se ejecutarn en las ltimas fases del arranque (o ya despus de terminar ste).

Aunque el mdulo SPI de la plataforma MC13213 se utiliza fundamentalmente para comunicarse con el mdem radio del chip y esto no debera ser un factor prioritario, se inicializar relativamente pronto dentro de la secuencia de arranque. Esto se debe a que el mdem radio 802.15.4 proveer de una seal de salida que habitualmente se emplear como referencia para generar un reloj de sistema rpido y preciso (32MHz).

116

Este reloj ser el elegido siempre por defecto en todas las aplicaciones ZigBee del ND07. Slo en una entorno con un reloj de sistema preciso y rpido podr ejecutarse el gestor de tareas (que se basa principalmente en gestionar el control de diversas secciones de cdigo basndose en temporizadores software y hardware) y los mdulos y capas (MAC, Red y Aplicacin) que pretenden funcionar sobre ste.

Como conclusin, parece obvio que la secuencia de pasos de arranque de la plataforma MC13213 es bastante coherente tal y como se presenta en las aplicaciones de ejemplo suministradas por Freescale y ha requerido pues de pocas modificaciones para adaptarla al caso concreto del hardware del ND07 (aunque s ha sido necesario un considerable estudio de los mdulos implicados).

De este modo, la nica modificacin significativa que se realizar sobre la secuencia de pasos del arranque ser la inclusin dentro de sta del bootloader desarrollado a lo largo del proyecto.

Las razones que justificarn la eleccin del que ser su emplazamiento definitivo dentro de la secuencia de arranque se discutirn en el apartado [Link].2, cuando se hayan desarrollado previamente todos los mdulos implicados en el proyecto.

[Link].

Memoria del MC13213

El chip MC13213 de Freescale integrado en las placas ND07 sobre las que se desarrolla este proyecto, dispone de 64 KB de memoria direccionables repartida entre RAM, Flash y registros de entrada/salida o control/estado.

La figura siguiente muestra los bloques mencionados y su direccionamiento.

117

Mapa de direcciones de memoria de la plataforma MC13213 [33] La memoria del MC13213 est compuesta por 128 pginas de 512 bytes que pueden agruparse en los siguientes bloques:

1.- Registros de Acceso Directo (primer cuarto de la pgina nmero 0). De este modo los 128 primeros bytes de la memoria correspondern a los registros de acceso ms frecuente (puertos, temporizadores, controladores serie, I2C y SPI, frecuencia de reloj, etc.) que al residir en la parte ms baja del mapa posibilitan direccionamiento directo en ensamblador (direccionamiento ms eficiente que reducir el tamao total del cdigo generado). 2.- Memoria RAM, 4KB emplazados entre el segundo cuarto de la pgina nmero 0 y el primer cuarto de la pgina nmero 8 (ambos inclusive). 3.- Bloque Bajo de Memoria ROM. Pequeo segmento de Flash que ocupa desde el segundo cuarto de la pgina nmero 8 hasta el final de la pgina nmero 11. 4.- Registros de Paginacin Alta. Bloque de memoria reservado para aquellos registros de uso muy poco frecuente. Slo ocupan los primeros 44 bytes de la pgina nmero 12 de la memoria del MC13213.

118

5.- Bloque Alto de Memoria ROM. Esta seccin de la memoria est compuesta por las 116 pginas restantes (desde poco despus del principio de la pgina 12 hasta el final de la pgina 127). Es en esta seccin donde se almacenar la mayor parte del cdigo de aplicacin.

Al final de la ltima pgina (nmero 127) se encuentran los registros no-voltiles de la Flash y los vectores de interrupcin y reset (incluyendo el vector de interrupcin de la I2C necesario para mantener la comunicacin con la memoria auxiliar EEPROM externa). Es por ello que este sector ser el ltimo en borrarse y regrabarse (como ya se explicar en mayor profundidad ms adelante).

Las caractersticas genricas ms destacables de la memoria del MC13213 a efectos del bootloader y la actualizacin de firmware son las siguientes:

Limitacin de un mximo de 100.000 ciclos de borrado y reprogramacin de la Flash. Capacidad de proteccin de sectores de memoria Flash contra borrado/regrabado accidental o intencionado. Posibilidad de redireccionar los vectores de interrupcin a posiciones de memoria no protegidas.

Seguridad para acceso no autorizado a determinados sectores de memoria. No es necesaria una alimentacin especial para el borrado y regrabado de la memoria. Basta con la misma que se utiliza para alimentar el circuito durante sus ciclos normales de funcionamiento.

Interfaz sencillo para la programacin de ciclos de borrado y actualizacin de bloques de memoria Flash.

No obstante la memoria Flash de la plataforma MC13213 presenta una serie de restricciones generales que han de respetarse obligatoriamente:

La frecuencia del reloj del mdulo Flash registro ha de configurarse para que presente un valor de entre 150 KHz a 200 KHz a partir de la frecuencia de reloj del bus del MC13213. Esta operacin ha de realizarse siempre antes de la cualquier solicitud de ejecucin de comandos al controlador Flash y slo puede efectuarse una vez despus de cada reseteo. Esto ser posible mediante el registro de configuracin FCDIV que se explicar ms adelante.

Nunca se podrn borrar bloques de memoria menores que una pgina de 512 bytes (a excepcin de las pginas 8 y 12 que son ms pequeas de lo habitual) Nunca se deber programar una misma posicin de memoria ms de una vez despus de una operacin exitosa de borrado de la pgina que la contiene. Si se desea reescribir de nuevo esa posicin, ser imprescindible borrar la pgina entera

119

previamente (o borrar la memoria completa). No respetar esta restriccin puede acarrear la corrupcin de los datos almacenados en la Flash.

A continuacin se proceder a describir resumidamente las propiedades incluidas y las herramientas disponibles en la plataforma MC13213 que tienen alguna relacin con la gestin de la memoria del dispositivo y pueden influir de algn modo en el diseo final del bootloader.

[Link].1.

Memoria Flash del MC131213. Algoritmos de Sobrescritura

Como se acaba de introducir, la Flash (ROM) de la plataforma MC13213 consiste en algo menos de 60 KB repartidos entre dos bloques de memoria separados por los registros de paginacin alta.

Para poder emplear dicha memoria para el almacenamiento de aplicaciones, el MC13212 provee de un interfaz (integrado por registros e indicadores) que permite el borrado y sobrescritura de los datos grabados en ella. Este interfaz se utiliza durante el proceso de programacin inicial del dispositivo justo antes de salir al mercado pero puede emplearse adicionalmente para actualizar ms tarde los dispositivos en cualquier momento de su vida til apoyndose para ello en un bootloader como el desarrollado a lo largo de este proyecto.

As pues, la memoria Flash del MC13213 ofrece una serie de registros sobre los que se apoyar la aplicacin del bootloader para realizar las operaciones de borrado y regrabado de sta y cuyo esquema completo de funcionamiento se describir ms adelante en el subapartado [Link]. A continuacin se describen resumidamente:

El FLASH Clock Divider Register (FCDIV) es el registro encargado de configurar el reloj interno del mdulo Flash a una frecuencia de entre 150 a 200 KHz para que ste pueda funcionar correctamente. Antes de poder emitir comandos de escritura o borrado sobre la memoria no voltil de la plataforma MC13213, es imprescindible configurar previamente este registro. Este objetivo se logra programando el registro FCDIV con la configuracin deseada a partir de la frecuencia del bus y una serie de factores de preescalado.

De este modo, el valor que el bootloader programar en el registro FCDIV ser muy dependiente de su posicin en la secuencia de arranque ya que, a lo largo de sta, las distintas fases del arranque irn modificando el reloj de referencia del chip (aumentando de frecuencia) hasta alcanzar la frecuencia del mdem radio (32 MHz de reloj y 16MHz de frecuencia de bus).

Una limitacin de la Flash ser que el registro FCDIV slo puede ser programado una nica vez entre cada reseteo del dispositivo, de modo que dicha operacin suele realizarse durante el

120

arranque del primer mdulo con capacidades de regrabado de la Flash. De ahora en adelante, el registro FCDIV de programar en la fase inicial de la ejecucin del bootloader (pero slo cuando haya que actualizar el firmware del dispositivo y se indique mediante el flag de regrabado activo en la EEPROM). En el caso de no realizarse una actualizacin del firmware, la configuracin de dicho registro se realizar durante la inicializacin del mdulo NVM (explicado al final de este apartado), varios pasos en la secuencia de arranque ms adelante.

Adicionalmente, es necesario resaltar que la configuracin del registro FCDIV slo deber realizarse despus de limpiar previamente los registros de estado del mdulo Flash.

El FLASH Status Register (FSTAT) es el registro encargado de informar acerca del estado de procesado del ltimo comando enviado al controlador de la memoria Flash. As pues, su lectura permite obtener informacin acerca de los siguientes parmetros relacionados con la actualizacin de la memoria:

Detectar si ha tenido lugar algn error en el procesado del comando (mediante lecturas de su cuarto bit, ACCERR) al no respetarse el protocolo de ejecucin de un comando. Comprobar si el buffer de comandos est lleno o puede continuarse un proceso de escritura por rfagas (mediante la lectura del sptimo bit, FCBEF) Comprobar si ha terminado el procesado del ltimo comando solicitado (mediante la lectura del sexto bit, FCCF) Detectar errores causados por el intento de sobrescribir sectores de memoria Flash securizados (mediante la lectura del quinto bit, FPVIOL)

Adicionalmente, este registro permite realizar una serie de operaciones crticas relacionadas con la grabacin de la memoria Flash segn se escriba en un determinado bit del registro:

Forzar el comienzo del procesado de un comando Flash (bit FCBEF a 1) Reinicializacin del estado del registro mediante la escritura de un 1 sobre cada bit de estado que ha indicado un suceso

Antes de realizar cualquier operacin sobre la Flash, ser necesario comprobar y limpiar este registro, FSTAT, para reiniciar el mdulo en el caso de presentar un estado de error (bit FACCERR).

El FLASH Command Register (FCMD) es el registro encargado de recibir y gestionar peticiones de procesado de comandos al controlador Flash. Para hacer uso de esta funcionalidad basta con escribir sobre dicho registro uno de los 5 siguientes posibles valores (cualquier otro valor dara error):

121

Comando Flash Comprobacin de Pgina Limpia * Escritura Estndar (1byte)

FCMD 0x05 0x20 0x25 0x40 0x41

Escritura por Rfagas (1 byte) * Borrado de Pgina (512 bytes)

Borrado Completo de Flash *

*: Comandos no empleados en el bootloader (ver ms adelante)

Una vez enviado el comando deseado al registro FCMD, ser necesario activar el bit FCBEF (bit nmero 7) del registro FSTAT para que ste comience a ejecutarse (como se explic justo en los prrafos anteriores relativos al registro FSTAT).

Aunque el bootloader desarrollado en este proyecto emplea la escritura estndar en memoria Flash que se realiza byte a byte, existe otra modalidad de programacin de la memoria Flash mediante el comando de escritura por rfagas que emplea un algoritmo similar al primero aunque ms complejo.

Las temporizaciones aproximadas de los comandos que se emplearn para actualizar la memoria Flash del MC13213 se describen en la siguiente tabla:

Parmetro

N de Ciclos de Reloj del Mdulo Flash (FCLK)

Tiempo Estimado (suponiendo FCLK=200KHz) 45 s 20 s1 20 ms

Escritura Estndar (1 byte) Escritura a Rfagas (1 byte) Borrado de Pgina (512 bytes)
1

9 4 4000

Excluyendo los incrementos de tiempo asociados a la escritura del primer byte de la rfaga

Como puede apreciarse, el comando de escritura por rfagas permite tericamente reducir el tiempo total de grabacin a un poco menos de la mitad pero requiere de una serie de prerrequisitos para poder aplicarlo de forma eficaz. Estos sern los siguientes:

1. Necesidad de suministrarle ristras de datos (menos de 64 bytes) contiguos 2. La rfaga ha de pertenecer a una fila concreta de la Flash (sectorizando la memoria en 1024 filas de 64 bytes). De lo contrario el cambio de fila implicar un cambio de velocidad durante la duracin de escritura de un byte a la velocidad estndar

122

3. Para poder mantenerse el modo de grabacin por rfagas, cada byte nuevo de datos ha de suministrarse antes de la finalizacin del grabado del anterior. De lo contrario el algoritmo regresa al modo estndar de grabacin (con su velocidad asociada)

Si se realizan unos clculos rpidos, en el mejor de los casos (con la mnima frecuencia de reloj configurable, 150KHz) la sobrescritura de la memoria Flash completa mediante rfagas tardara algo menos de 2 segundos que empleando la grabacin estndar. Lo ms habitual ser que debido al almacenamiento en EEPROM de registros S19 modificados de menos de 32 bytes y su disposicin en posiciones de memoria no consecutivas ni contenidas enteramente dentro de un mismo sector de 64 bytes, las diferencias de emplear un mtodo frente al otro no sean muy significativas en cuanto a tiempo se refiere.

No obstante, el cumplimiento de los prerrequisitos y control de errores necesarios para realizar la grabacin por rfagas complicara muy considerablemente el algoritmo de actualizacin del firmware llevado a cabo por el bootloader y, con ello, sus requerimientos de memoria ROM y RAM. Es por esto que este proyecto emplear el modo estndar de grabacin (descartado la escritura por rfagas) para llevar a cabo su objetivo de reemplazar el firmware en uso del dispositivo.

Enviar un comando (de grabacin o borrado) al controlador del mdulo Flash del MC13213 puede provocar errores de lectura de cualquier cdigo almacenado en ROM (incluyendo al cdigo relativo al bootloader) mientras dure la ejecucin de la operacin solicitada. Es por ello que se hace imprescindible emplazar la rutina de escritura de bytes y borrado de pginas Flash en la memoria RAM del dispositivo de forma previa al envo de cualquiera de ambos comandos al controlador. Esta caracterstica del mdulo Flash complicar el cdigo del bootloader y aumentar los requisitos mnimos de memoria RAM y ROM necesarios para su funcionamiento.

De este modo, el bootloader desarrollado en este proyecto har uso de las herramientas suministradas por el MC13213 para el borrado y regrabado de su memoria Flash (descartando el modo por rfagas, como ya se ha justificado), y respetar todas las restricciones que se han ido comentando en este apartado y sus predecesores. El resultado de este desarrollo y su descripcin detallada (incluyendo el algoritmo completo de borrado y actualizacin de la memoria Flash) tendrn lugar en el apartado [Link] en la parte correspondiente al bloque de sobrescritura de la memoria ROM.

123

[Link].2.

Proteccin de Bloques de Memoria Flash

El MC13213 provee de un mecanismo de proteccin de bloques de memoria Flash que previene borrados y/o reprogramaciones accidentales (o provocadas) sobre las posiciones configuradas.

As pues el chip permite proteger un bloque del final de la memoria Flash (desde una posicin determinada hasta la posicin 0xFFFF), proteger la totalidad de la memoria o por el contrario desprotegerla completamente.

Con este fin, los bits del registro no voltil NVPROT (cuyo valor se graba en el dispositivo y ya no puede ser modificado sin previamente borrar la pgina entera) y los del registro FPROT (sito en RAM y cuyo contenido es una copia del de NVOPT que se realiza automticamente durante el arranque del dispositivo) permitirn configurar el funcionamiento del mecanismo de proteccin de la memoria Flash.

De este modo, la configuracin del MC13213 acerca de la proteccin de sectores de su memoria Flash vendr fijada de forma permanente en el registro NVPROT, pero podr ser temporalmente modificada mediante la edicin del registro FPROT a travs de comandos especiales enviados por el puerto de depuracin (pin BKGND del chip) pero nunca desde la aplicacin en ejecucin. Una vez el dispositivo se reinicie se volver a restaurar la configuracin original almacenada en NVPROT. Es por todo esto que una vez que el dispositivo est instalado en localizacin determinada y ya no se realicen procesos de depuracin sobre l, mantendr una configuracin de proteccin de bloques que se mantendr constante durante toda su vida til.

Si por cualquier razn se trata de reprogramar o borrar una posicin de memoria perteneciente a un bloque protegido, se activar un bit indicador del error (bit FPVIOL) en el registro FSTAT y el comando se descartar sin mayores consecuencias.

El funcionamiento del mdulo de proteccin ser el siguiente: un bit del registro NVPROT (bit FPOPEN) permitir el regrabado de las posiciones de memoria no protegidas, otro bit (bit FDIS) activar o desactivar el mecanismo de proteccin de sectores y otros 3 bits (bits FPS) configurarn el tamao del bloque de memoria protegido (en el caso de protegerse alguno).

La utilidad ms interesante de esta propiedad de la memoria del MC13213 consiste en la proteccin del cargador de arranque (y el bootloader incluido dentro) si se almacena en un bloque de memoria prximo al final de la Flash, de forma que el bootloader pueda borrar el resto de la memoria y reprogramarla sin peligro de daar su propio cdigo. Adicionalmente, si

124

tuviese lugar algn problema de alimentacin del dispositivo mientras est siendo actualizado, el cargador de arranque no sufrira nunca ningn dao y el equipo podra recuperarse.

Desafortunadamente a efectos de este proyecto, para que este sistema de proteccin de memoria fuese realmente eficaz a la hora de proteger el cargador de arranque del dispositivo, ste debera estar localizado ntegramente dentro del mismo bloque de memoria protegida en todas las aplicaciones diseadas para el ND07 y no podra modificarse en ninguna de las actualizaciones que se fueran enviando al dispositivo. Esto implicara el desarrollo de un cargador de arranque completo y hermtico en ensamblador (no slo la parte del bootloader encargada de actualizar el firmware) capaz incluso de asociar el dispositivo a una red ZigBee para recuperar su firmware en caso de error de actualizacin o similar. Esto puede no ser deseable en situaciones en que se desee incluir o descartar dinmicamente (entre distintas actualizaciones de firmware) funcionalidades del dispositivo (no incluir el control de LEDs, UART, etctera) e implicara tomar importantes decisiones de diseo acerca de cmo habrn de funcionar de ahora en adelante todas las aplicaciones ZigBee sobre el ND07, algo completamente fuera de la competencia de este proyecto.

A da de hoy el cargador de arranque del ND07, empleado en todas las aplicaciones desarrolladas para este proyecto, se basa en programas de ejemplo que suministra Freescale (muy funcionales y verificados) cuyo cdigo se compila ocupando aleatoriamente la ROM del dispositivo de forma que precise de la cantidad mnima de memoria o sea lo ms rpido posible (el compilador permite emplear uno u otro criterio a la hora de generar el cdigo ensamblador final). La inclusin de todo este cdigo junto con el bootloader y con el encargado de dejar la red ZigBee operativa (y lista para recuperar el dispositivo en caso de darse un error de actualizacin) forzara a crear un bloque de memoria protegido y hermtico de un tamao muy elevado, dejando muy poco espacio libre para el diseo de la aplicacin final y restringiendo muy considerablemente el funcionamiento final de sta.

Como ya se ha mencionado en repetidas ocasiones, el objetivo final de este proyecto es disear y programar un bootloader ptimo, robusto y cerrado que sea a la vez lo suficientemente flexible como para que se pueda incluir en muy diversas aplicaciones creadas para el ND07 u otros dispositivos basados en el chip ND07.

Las ventajas principales de la proteccin de bloques consisten el proteger un cargador de arranque completo (no slo la parte del bootloader) capaz de arrancar el dispositivo y asociarlo a la red dejndolo funcionando normalmente o preparado para recuperarse en caso de suceder un fallo de actualizacin. Programar y proteger este cargador de arranque dista mucho de los objetivos buscados, ya que nos forzaran a tomar decisiones muy restrictivas acerca de cmo habr de ser el funcionamiento en red del dispositivo y esto se encuentra fuera de nuestra competencia.

125

Puesto que la proteccin slo del bloque de memoria relativa al bootloader no plantea ventajas significativas (ya que si tienen lugar errores en la actualizacin de los bloques de memoria relativos al cargador de arranque, el dispositivo no podra recuperarse) y en cambio s que plantea un considerable nmero de complicaciones y restricciones (forzara a situar el bootloader siempre en una posicin fija de memoria en todas las aplicaciones y a controlar muchas posibles situaciones de error adicionales), se ha decidido no incluir el mecanismo de proteccin de bloques de memoria en el diseo del bootloader.

Es por todo esto que de ahora en adelante, en todas las aplicaciones desarrolladas se configurarn los valores de los registros NVPROT (y por ende FPROT) de forma que siempre se deshabilite el mecanismo de proteccin de bloques.

[Link].3.

Redireccin de los Vectores de Interrupcin

Puesto que toda configuracin de la memoria Flash que proteja bloques de memoria implica automticamente la proteccin de los vectores de interrupcin y de reset (sitos en la ltima pgina de la Flash, como se explica al principio del apartado [Link]), el valor de stos en principio ya no podra ser actualizado nunca entre distintas versiones de firmware. Es por ello que se hace necesario un mecanismo que permita al desarrollador modificar su contenido (o una alternativa al problema) sin desbloquear el cdigo del bootloader presuntamente localizado dentro del bloque protegido. Con este objetivo se emplea la funcionalidad de redireccin de vectores del MC13213.

Para

activar

la

redireccin

de

los

vectores

de

interrupcin

(el

vector

de

reset

desafortunadamente no puede ser redirigido), basta con programar (a cero) un bit (el bit FNORED) del registro no voltil NVPROT y activar la proteccin de un bloque de memoria Flash (ver sub apartado anterior). Las nicas excepciones se darn con la proteccin completa de la memoria o la desproteccin total de la Flash que no admitirn redireccin de vectores alguna. Siempre que se active la proteccin de un bloque de Flash se proteger automticamente al menos la ltima pgina de la memoria, que incluye a los vectores de interrupcin, al vector de reset y a la de seccin de registros no voltiles, de modo que ya no podrn ser actualizados.

Una vez se activa la redireccin de los vectores de interrupcin (configuracin fijada en el momento de grabacin del primer firmware en el ND07), las posiciones de memoria del rango 0xFFC0 a 0xFFFD (vectores de interrupcin) se redireccionarn a las posiciones de Flash desprotegidas ms cercanas al bloque protegido. De esta forma, la nueva posicin de los vectores de interrupcin depender directamente del tamao del bloque de memoria que se haya protegido previamente)

126

De este modo, empleando la redireccin de vectores, una aplicacin de bootloader sita en el bloque de memoria protegido podra reprogramar completamente la memoria Flash no protegida del dispositivo incluyendo nuevos valores para los vectores de interrupcin sin modificar el cdigo del bootloader ni los valores originales de la tabla de interrupciones.

Desafortunadamente, como puede deducirse de los manuales del chip y de los foros de discusin de Freescale
[42]

, este mecanismo de redireccin de los vectores de interrupcin es

demasiado poco flexible, ya que al mantener el bit de redireccin en un registro no voltil (dentro del registro NVOPT, en la posicin protegida 0xFFBF), no permite elegir de forma dinmica qu conjunto de vectores se emplear. Esto provoca que cuando se programa un chip con la redireccin de vectores activada, si la aplicacin almacenada en la seccin de memoria protegida (presumiblemente un bootloader) pretende actualizar el resto de la memoria no protegida, no podr emplear vectores de interrupcin (ya que esas posiciones se borrarn y actualizarn), reduciendo drsticamente su funcionalidad.

Por otro lado, si se programase un chip sin redireccin de vectores y se protegiese un bloque de memoria que incluya un bootloader, las imgenes de aplicaciones almacenadas en la EEPROM que sustituirn a la aplicacin principal debern mantener sus cdigos de atencin a las interrupciones en las misma localizaciones de memoria que las que tuvo el primer programa grabado en el ND07 o dejarn de funcionar. De este modo, los desarrolladores tendran que emplear mecanismos complicados para que el compilador localizase las rutinas de atencin siempre en las mismas posiciones, interfiriendo muy negativamente en su libertad y dificultando gravemente la elaboracin de aplicaciones. Adicionalmente, si se protege algn bloque de memoria queda automticamente protegido el registro que permite configurar la redireccin de vectores, de forma que si una aplicacin no emplea un tipo de interrupcin para nada, cualquier futura aplicacin que actualice a sta primera tampoco podr implementar posteriormente una rutina de atencin para ella ya que el vector siempre estar vaco.

As pues, el mecanismo de redireccin de vectores del MC13213 no permite disponer simultneamente de dos tablas de vectores de interrupcin y alternar dinmicamente entre ellas. Para lograr un funcionamiento similar sera necesario implementar para cada vector de interrupcin una pequea rutina de atencin (sito en la seccin protegida de Flash) que comprobase un indicador (flag) que le permita decidir cul de los vectores disponibles para esa interrupcin ha de ejecutar.

Es por todo esto, y por la decisin tomada en el subapartado anterior de no proteger bloques de memoria del chip, que se ha concluido no incluir el mecanismo de redireccin de vectores del MC13213 en este proyecto. El nico vector de interrupcin empleado por el bootloader (el asociado al bus I2C) al emplearse nicamente para leer la EEPROM del ND07, apuntar

127

perennemente a la misma posicin de memoria de ste (y el desarrollador habr de respetar dicha limitacin en todos los firmwares que disee para actualizar dispositivos ND07). En las situaciones en que se produzcan interrupciones I2C durante la ejecucin de la aplicacin principal (mientras el bootloader no se est ejecutando), stas se debern principalmente al proceso de recepcin y almacenamiento de imgenes en la memoria auxiliar. La rutina de atencin I2C del bootloader ha sido programada para detectar estas situaciones y redireccionar excepcionalmente (de forma manual) el vector de interrupcin a otra posicin de memoria Flash para que el desarrollador pueda programar su propia funcin de control.

De nuevo pues, de ahora en adelante todas las aplicaciones desarrolladas para el ND07 habrn de configurar los registros relativos a la redireccin de vectores de interrupcin de forma que esta propiedad quede siempre deshabilitada.

[Link].4.

Seguridad de la memoria

La plataforma MC13213 incluye circuitos para prevenir el acceso no autorizado a los contenidos de su memoria RAM y Flash.

Cuando la seguridad est activada, las memorias Flash y RAM son consideradas recursos seguros y los registros de acceso directo, registros de paginacin alta y la entrada de depuracin (lnea por donde se depura la aplicacin durante el proceso de desarrollo software) son considerados recursos inseguros.

Cuando se activa la seguridad, el acceso a la memoria RAM y Flash slo puede realizarse de forma normal desde recursos de memoria considerados como seguros. De este modo, un programa ejecutndose desde posiciones seguras de memoria tendr acceso a todos los recursos disponibles del microcontrolador, as como a todas sus posiciones de memoria. Por otro lado, el intento de leer o escribir sobre dichas posiciones desde regiones (o dispositivos externos) consideradas como no seguras resultar en lecturas de ceros y escrituras ignoradas.

El microcontrolador provee de dos registros de control idnticos para activar o desactivar la seguridad del chip llamados NOVPT y FOPT sitos en la regin de registros no voltil (posicin 0xFFBF) y en la regin de registros de paginacin alta (0x1821) respectivamente. La nica diferencia entre ambos es que el primero (NVOPT), mantiene su valor grabado en Flash de fbrica y ste no puede ser alterado de ningn modo salvo mediante el borrado completo de la memoria no voltil. En cambio el registro FOPT, que almacena el valor del registro NVOPT que se copia desde ste durante el proceso de arranque del dispositivo,

128

permite modificar temporalmente el estado de la seguridad del sistema durante la duracin de la ejecucin de la aplicacin principal (pero al resetearse el dispositivo volver al estado original que almacenaba el registro no voltil).

As pues, si se desea activar (o desactivar) a seguridad del dispositivo bastar con configurar de fbrica de la forma adecuada dos bits del registro NVOPT (bits 0 y 1, SEC00 y SEC01) y este estado se reflejar en el registro FOPT tras el arranque de la aplicacin.

Adicionalmente, el chip provee de la posibilidad de desactivar la seguridad del chip temporalmente (hasta el prximo reseteo del dispositivo) si se activa de fbrica el sptimo bit (KEYEN) del registro NVOPT y el quinto bit (KEYACC) del registro FCNFG. En este caso, la aplicacin deber escribir sobre los registros NVBACKKEY (de la seccin registros no voltiles) una clave de 8 bytes que, si coincide con la almacenada, provocar la dessecurizacin de la memoria hasta el prximo reseteo.

El mecanismo de seguridad del ND07 permanecer desactivado en la mayor parte de las aplicaciones por no ser realmente necesario y requerir de un estricto control de las claves almacenadas en cada aplicacin. No obstante, puesto que el bootloader se ejecutar desde recursos considerados seguros como son la memoria Flash y RAM del dispositivo, su funcionamiento e implementacin ser independiente y no se ver alterado por la decisin del desarrollador de aplicaciones acerca de la securizacin (o no) del equipo.

[Link].5.

El Componente NVM (Non-Volatile Memory)

Adicionalmente, la pila ZigBee de Freescale provee de un API de uso opcional para el manejo de su componente NVM (Non-Volatile Memory). Este interfaz permite el empleo de dos o ms pginas de memoria Flash para el almacenamiento de datos (RAM) cuyo valor debe de mantenerse entre reseteos del dispositivo (contexto del equipo ZigBee en la red). Para lograr este objetivo sin agotar rpidamente el nmero mximo de grabaciones que permite la memoria Flash del MC13213, la API utiliza unos algoritmos especiales de ubicacin de los datos, impide actualizaciones que no aporten cambios en las variables y limita la frecuencia de refresco de dichas variables (Freescale recomienda que las aplicaciones desarrolladas no actualicen las variables de la NVM con una frecuencia superior a una vez cada 1,8 horas para asegurar una vida del dispositivo cercana a los veinte aos).

Debido a las especificaciones de la memoria Flash del MC13213, un byte de una pgina no puede ser sobrescrito sin antes borrar toda la pgina. Es por ello que para poder disponer de dos pginas destinadas al almacenamiento de datos no voltiles (configuracin por defecto), ser necesario reservar tres. Siempre deber haber disponible una pgina extra para copiar

129

sobre ella la ltima pgina cuyos datos se han modificado (quedando la pgina que almacenaba esos datos como la nueva pgina libre).

Las variables de contexto almacenadas en la memoria NVM se pueden separar en los siguientes grupos (comunes para todos los dispositivos ZigBee salvo el ltimo punto, que es particular de cada aplicacin):

Parmetros de la red a la que el dispositivo est asociado: canal, direccin del padre lgico, PanId, Nmero de hijos asociados (routers y dispositivos finales), etc. Tablas de dispositivos vecinos y tablas de encaminamiento de paquetes (para los dispositivos routers) Parmetros de seguridad y capacidades del dispositivo que se reportarn bajo peticin. Tablas de direcciones, tablas de bindings, tablas de grupos y tablas de claves Alarmas y escenas de la ZigBee Cluster Library Datos de contexto especficos de la aplicacin ZigBee particular del dispositivo (estado de salidas, de LEDs, de batera, etc.)

La ubicacin del componente NVM en memoria (si la aplicacin del firmware en uso decide utilizarlo) es relativamente configurable pero suele ocupar por defecto las pginas 13, 14 y 15 de la Flash del dispositivo (aunque se pueden configurar ms pginas de memoria con este comportamiento, no suele ser necesario).

Toda aplicacin que desee ser conforme con la especificacin ZigBee (cualquiera de las versiones), ha de almacenar dichos parmetros de contexto entre reseteos del dispositivo. As pues, lo ms habitual es que todos los dispositivos que carezcan de otra memoria auxiliar para almacenar dichos datos (como es el caso del dispositivo ND07, que dispone de una memoria auxiliar pero que se emplea para el almacenamiento de imgenes) hagan uso del componente NVM.

No obstante, haga uso la aplicacin del componente NVM o no, las pginas empleadas para el almacenamiento de datos no voltiles son, a fin de cuentas, memoria Flash normal del MC13213 y como tal, el procedimiento a emplear por el bootloader para su borrado y sobrescritura sera idntico al del resto de memoria ROM y no planteara ningn problema tcnico adicional. Sin embargo, la funcin principal de la NVM es la de mantener el contexto del dispositivo entre reseteos de ste y, como es lgico, tambin entre actualizaciones de firmware.

Es muy poco probable que el bootloader se emplee para sustituir el firmware de un dispositivo por otro cuya funcionalidad sea muy distinta (por ejemplo reemplazar el firmware de un sensor de temperatura por el de un detector de presencia) ya que el hardware del dispositivo no suele

130

modificarse. Lo habitual ser actualizar el firmware slo para aadir funcionalidades o corregir bugs.

En el hipottico caso de que la funcionalidad del dispositivo cambiase radicalmente en la nueva imagen, bastara con tenerlo en cuenta a la hora de programar la nueva versin de firmware para que sea compatible con los parmetros de contexto almacenados en la NVM (y respetase las pginas ocupadas por sta no ocupndolas con el nuevo firmware) o se encargue de reemplazar los que considere oportunos en su primera ejecucin.

A efectos del bootloader slo existen pues dos posibilidades: incluir la NVM o ignorarla. En el primer caso el bootloader protegera las pginas asociadas a la NVM y no las borrara ni sobrescribira para que el dispositivo, una vez reseteado, recuperase su contexto tal como estaba antes de la actualizacin. En el segundo caso, el bootloader funcionara como si la NVM no existiese borrando sus pginas asociadas (siempre) y sobrescribindolas slo si el nuevo firmware aloja datos o cdigo en ellas.

La nica pregunta que el programador tendr que hacerse ser si incluir el mdulo NVM dentro de una aplicacin ZigBee determinada (y sus futuras revisiones) o no hacerlo en absoluto. Pero una vez tomada una decisin, sta habr de mantenerse en todas las actualizaciones de firmware del dispositivo a lo largo de su vida til.

As pues, los pros y contras de incluir el mdulo de NVM en una aplicacin ZigBee se pueden resumir en los siguientes puntos:

La NVM es un interfaz sencillo para almacenamiento del contexto de un dispositivo sin necesidad de memorias auxiliares adicionales ni de la programacin de nuevas APIs para ese fin. Adems esta API est perfectamente integrada con la librera de la capa de red ZigBee, facilitando mucho el trabajo al desarrollador.

Las imgenes almacenadas en la EEPROM sern ms pequeas, ya que las pginas correspondientes a la NVM se descartarn puesto que no se sustituirn en Flash. Menor espacio consumido en la EEPROM en concepto de imgenes, lo cual implica mayor velocidad del proceso de almacenamiento de firmwares y de actualizacin de la Flash (reduciendo las posibilidades de errores crticos).

Incluir el mdulo NVM en una aplicacin implica emplear para ese propsito unos 2 KB de cdigo en Flash y 150 bytes de RAM adicionales a las 3 pginas (en el mejor caso, 3x512 bytes) que habrn de reservarse para el almacenamiento de los datos no voltiles de contexto. Esto implica que como mnimo la aplicacin dispondr de casi 4KB menos de espacio en Flash para cdigo de aplicacin, y menos RAM, que son recursos muy escasos en aplicaciones complejas como routers y coordinadores. No

131

obstante, la inclusin de cualquier API que controle el almacenamiento de datos no voltiles en una memoria auxiliar implicar ocupar esta cantidad de memoria o ms.

Puesto que las aplicaciones desarrolladas sobre el dispositivo ND07 pretenden ceirse a la especificacin ZigBee lo mximo posible (para lo cual han de almacenar los datos de contexto de la aplicacin) y este dispositivo no dispone de ms memoria auxiliar que la EEPROM que ya se emplea para el almacenamiento de imgenes, el empleo del componente NVM es casi obligatorio.

Desarrollar un bootloader en ensamblador que permita elegir si se desea incluir el componente NVM o no (y de incluirlo, qu pginas ocuparn los datos no voltiles de contexto) es lo suficientemente complicado (aumentando considerablemente el tamao, lentitud y complejidad de integracin del bootloader con una aplicacin ZigBee) como para que no compense cubrir una situacin tan poco probable como es la de descartar el componente NVM.

De este modo, el bootloader desarrollado respetar tambin las pginas correspondientes a los datos de contexto de la NVM, no borrndolas ni sobrescribindolas nunca.

[Link].

Mdulo I2C del MC13213

El mdulo I2C incluido en la plataforma MC13213 proporciona las siguientes funcionalidades: Compatibilidad con el bus I2C Funcionamiento Multi-Maestro 64 diferentes frecuencias de reloj serie programables Bit ACK seleccionable por software Transferencia de datos mediante interrupciones byte a byte Interrupcin de prdida de arbitraje con cambio automtico de modo maestro a esclavo Deteccin y generacin de seales START y STOP Generacin de seal de START repetido Generacin y deteccin del bit de ACK Deteccin de bus ocupado

Estas funcionalidades se ilustran en el siguiente esquema:

132

Bloque Funcional I2C del MC13213 [33] El control de estas funcionalidades del mdulo I2C se realiza mediante la escritura y lectura de 5 registros de 8 bits: IICA, IICF, IICC, IICS y IICD. El registro IICA (I2C Address Register) almacena la direccin de 7 bits del mdulo I2C que lo identifica cuando funciona en modo esclavo. Esta situacin no se dar nunca en el ND07 ya que slo existen dos componentes conectados a su bus I2C, el MC13213 y la EEPROM, que siempre funcionarn como dispositivo maestro y esclavo respectivamente. El registro IICF (I2C Frequency Divider Register) permite configurar la velocidad del bus I2C y el tiempo que permanecen activos los bits en la lnea de datos (SDA) despus de que la lnea de reloj haya cambiado de nivel alto a nivel bajo. El registro IICC (I2C Control Register) otorga control sobre el funcionamiento del MC13213 en el bus. As pues permite: Activar o desactivar el mdulo I2C Alternar entre los roles de maestro y esclavo Alternar entre los modos de transmisin y recepcin Decidir si se responde a una recepcin mediante ACK o no se responde (NACK) Habilitar o deshabilitar las interrupciones I2C Forzar un START repetido

133

El registro IICS (I2C Status Register) permite a la aplicacin detectar el estado del bus o sucesos puntuales que han tenido lugar como pueden ser:

Final de una transferencia (tanto de recepcin como de transmisin) Un dispositivo ha iniciado una comunicacin como maestro dirigida al MC13213 como esclavo (esta situacin no se dar nunca en el ND07) Bus ocupado (si se ha escuchado un START en el canal y an no se ha recibido el STOP) Prdida de arbitraje Modo de funcionamiento (recepcin o transmisin) del MC13213 cuando est funcionando con el rol de esclavo (esto tampoco tiene nunca lugar en el ND07) Interrupciones I2C ante prdidas de arbitraje, transferencias finalizadas de un byte de datos, o coincidencia de direcciones de dispositivos durante el proceso de direccionamiento

Recepcin (o no) de bit de ACK tras el envo de un byte de datos

La lectura del registro IICD (I2C Data IO Register) permitir recuperar el ltimo byte recibido del bus I2C (en modo recepcin) y su escritura permitir el envo de datos. La lectura o escritura sobre este registro, con los dems registros convenientemente configurados, permitirn inicializar una comunicacin en modo recepcin o transmisin respectivamente. Adicionalmente, la interrupcin I2C permite a la aplicacin detectar y actuar en consecuencia ante situaciones de:

Prdida de arbitraje del bus. Finalizacin de transferencia de un byte. Recepcin de una trama que direcciona al MC13213 como esclavo de una transmisin (esto no suceder nunca en el ND07).

El empleo sabio de este interfaz formado por cinco registros y una interrupcin, junto los conocimientos adquiridos acerca del funcionamiento del protocolo I2C y su implementacin para la memoria AT24C512 (ver apartado 3.9) permitirn desarrollar un API para la lectura y escritura de la EEPROM externa que el bootloader emplear durante su ejecucin (ver bloque de lectura de registros S19 modificados del apartado [Link]).

134

[Link].

Vectores de Interrupcin

Los diferentes mdulos de la plataforma MC13213 (interfaces de comunicacin serie, conversor analgico-digital, mdulo SPI e I2C, temporizadores hardware, KBI, etc.), emplean habitualmente interrupciones para indicar diferentes estados de funcionamiento.

Como es habitual, a cada interrupcin le corresponde un vector de interrupcin que apunta a la seccin de cdigo en memoria Flash encargada de efectuar su rutina de atencin. En el caso del microcontrolador MC13213, todos los vectores de interrupcin se encuentran alojados por defecto en la ltima pgina de memoria Flash, aunque pueden redireccionarse a otras posiciones si se activa la proteccin de bloques de memoria (ver apartado [Link]).

El listado de las distintas interrupciones posibles y su emplazamiento por defecto en memoria Flash se describe en la siguiente figura:

Vectores de interrupcin y reset del MC13213 [33]

135

A efectos del bootloader, la nica interrupcin imprescindible que para su correcto funcionamiento ser aquella generada por el mdulo I2C (cuyo vector se encuentra en las posiciones de memoria 0xFFCE y 0xFFCF), fruto de la comunicacin del microcontrolador con la memoria E2PROM externa (que almacena la imagen del firmware que sustituir al actual).

En la plataforma MC13213, la mayora de las interrupciones se encuentran desactivadas por defecto y no tendrn lugar a menos que el cdigo de aplicacin, o alguna instruccin de la secuencia de arranque, las habilite especficamente. Es por esto que, para evitar al mximo los riesgos derivados de que cualquier interrupcin ajena al bootloader interrumpa su ejecucin repetidamente (o durante un tiempo demasiado prolongado), se recomienda ejecutar el bootloader lo ms prximo posible al principio de la secuencia de arranque. De este modo, poco despus del encendido del dispositivo se comprobar si existe una actualizacin programada en la EEPROM y, de existir, se proceder a sustituir el firmware mucho antes de dar paso al resto de mdulos del microcontrolador o a la aplicacin principal.

La localizacin de los vectores de interrupcin en la ltima pgina de la memoria Flash (pgina nmero 127), obligar a tratar este bloque de memoria de forma especial a la hora de actualizar el firmware de un dispositivo. El borrado accidental de este sector sin realizar una inmediata sobrescritura de los vectores de interrupcin puede provocar que una actualizacin se quede a medias dejando el dispositivo en un estado irrecuperable. Este punto se desarrollar con mayor profundidad en los prximos apartados.

[Link].

Watchdog

La plataforma MC13213 permite la activacin opcional de un temporizador hardware configurable llamado watchdog (o COP) cuya funcin consiste en forzar un reseteo del dispositivo cuando la aplicacin deja de funcionar como se espera de ella, quedndose colgada.

Para evitar este reseteo, la aplicacin ha de encargarse de reinicializar peridicamente el watchdog antes de que ste expire. Si por algn error de diseo o suceso inesperado el cdigo de la aplicacin falla y se pierde (memory leaks, punteros errneos, situaciones no contempladas, etc.), el watchdog no se reinicializar a tiempo y ste resetear el dispositivo para devolver al sistema a un punto inicial conocido. A da de hoy la mayor parte de las aplicaciones de dispositivos que pretendan permanecer funcionando periodos prolongados de tiempo, activan el temporizador watchdog en su cdigo

136

para protegerse ante situaciones no contempladas (difcilmente detectables a corto plazo mientras el programador desarrolla el cdigo).

Una aplicacin bien diseada incluir pues la activacin del watchdog y el cdigo necesario para reiniciarlo peridicamente slo si la ejecucin se est efectuando de acuerdo a lo esperado. De este modo un dispositivo instalado en un emplazamiento de difcil acceso no requerir de la asistencia de un instalador para reinicializar el dispositivo si este se cuelga.

Como ya se ha mencionado en el captulo tres, la tecnologa ZigBee est pensada especficamente para cubrir sistemas compuestos por dispositivos que permanecen encendidos periodos de hasta aos y que en muchas ocasiones se instalan en localizaciones de difcil acceso. Es por ello que cualquier desarrollador de aplicaciones ZigBee inteligente incluir, sin duda alguna, la funcionalidad del watchdog en todos los cdigos que programe.

Al ser este el caso del ND07, el diseo del bootloader se realizar siempre contando con que el watchdog est activado en todas las aplicaciones ZigBee. Puesto que habitualmente toda actualizacin del firmware llevar ms tiempo que el temporizador watchdog en expirar, ser necesario que el bootloader lo reinicialice peridicamente a lo largo de su ejecucin y no arriesgarse as a un reseteo inesperado del dispositivo en medio de algn proceso crtico.

En el caso de la plataforma MC13213, el watchdog puede ser configurado para que expire (si no se reinicializa antes) transcurridos periodos de 218 o 213 ciclos del bus (periodo que puede resultar muy cortos en el tiempo dependiendo de la frecuencia de reloj empleada por el chip, que ser distinta dependiendo de la fase de arranque del dispositivo).

Puesto que el bootloader incluye procesos crticos cuya duracin puede llegar a ser bastante prolongada, su inclusin impondr al desarrollador el requisito de configurar siempre el watchdog con la temporizacin ms larga posible (218 ciclos de bus). El manejo y configuracin del watchdog de la plataforma MC13213 es muy sencillo y se realiza ntegramente mediante el registro SOPT (System Options Register) y el registro SRS (System Reset Status Register).

De este modo, el temporizador watchdog se activar escribiendo un bit a 1 (el bit COPE, COP Enable) del registro SOPT y se configurar su periodo a 218 ciclos de bus escribiendo a 1 otro bit del mismo registro (el bit COPT, COP Timeout).

La reinicializacin del temporizador watchdog se realizar escribiendo cualquier valor sobre el registro de slo lectura SRS (no afectando pues, al valor en l almacenado) en cualquier momento. Obviamente se recomienda que este reseteo del temporizador no se realice nunca

137

dentro cdigos de atencin de interrupciones ya que stas podran seguir ejecutndose peridicamente incluso cuando el programa principal falle.

El nico requisito que impone este temporizador es que el registro SOPT ha de configurarse siempre, incluso si se desea deshabilitar el watchdog, al principio del arranque del dispositivo y que este proceso slo puede realizarse una vez por cada reseteo del dispositivo (ver pasos del cargador de arranque del apartado 4.1.2).

Como resumen se concluye pues que el bootloader desarrollado en este proyecto contar con que el watchdog estar activado siempre (y configurado con su periodo ms largo), y lo reiniciar peridicamente a lo largo de su ejecucin para evitar cualquier reseteo accidental del dispositivo.

138

4.1.3. Formatos de Firmware: Registros S19 y S19 Modificados

En este apartado se desarrollar el estudio realizado acerca del formato que sigue la imagen de una aplicacin ZigBee compilada para el chip MC13213 de Freescale y acerca del formato ptimo que se emplear para su almacenamiento en la memoria auxiliar EEPROM optimizando el espacio libre y eliminando datos redundantes o innecesarios.

[Link].

Fichero Motorola S19

S19 es la extensin utilizada por Motorola para los ficheros que almacenan las imgenes binarias de sus aplicaciones
[43]

y se basa en el formato de fichero HEX

[44]

de Intel.

Los ficheros Motorola S19 (S-Record) encapsulan la imagen a grabar como una lista de registros (lneas) donde los datos se encuentran codificados de forma que el valor de cada byte en hexadecimal se representa mediante dos caracteres ASCII (de este modo todos los datos son caracteres imprimibles). Eso quiere decir que cada lnea del fichero tiene el siguiente formato: Stnnaaaadddddddddddddddddddddddddddddddd cc En donde: = S indica que es un S-Record (registro) de Motorola = Tipo de registro, 0=Cabecera, 1=datos, 9=Fin de fichero. = Nmero de bytes del registro (lnea) contando los datos, la direccin destino y el checksum (cada byte son dos letras en ASCII). As pues ser el nmero de bytes de datos ms tres. Aaaa = Direccin de memoria destino de una lnea de datos (nmero hexadecimal en ASCII). Dd = Datos del registro (nmeros hexadecimales en ASCII). Cc = Checksum del numero de bytes, direccin y de los datos (nmero hexadecimal en ASCII). Para ello se suman todos los bytes en ASCII, se realiza una operacin AND con 0x00FF (truncamos a ocho bits) y se realiza el complemento a uno (operacin NOT). S t Nn El campo t puede tomar otros valores que corresponderan a memorias con un espacio de direcciones ms grande e implicaran un mayor nmero de bytes para direccionar los datos que contienen. El CodeWarrior compila imgenes de aplicaciones para el chip MC13213 en las que emplea nicamente 16 bits para las direcciones, pudiendo as direccionar hasta un mximo de 64KB de memoria.

Los ficheros .S19 generados mediante el IDE del CodeWarrior suelen contener nicamente registros de tipo S0 (cabecera), S1 (datos) o S9 (fin de fichero). Los registros S0 slo almacenan comentarios como podran ser el nombre de la aplicacin contenida o su versin, pero no contendrn datos del mapa de bytes de la imagen. As pues, estos registros pueden ser empleados por la aplicacin que comunique la imagen al dispositivo a actualizar para indicarle qu firmware es el que se trata de transmitir. Sin embargo, estos registros no se almacenarn en ningn caso en la memoria auxiliar para ahorrar todo el espacio que sea posible.

139

Los registros S9 indican el fin de fichero de la imagen y no aportan informacin ni datos adicionales, de modo que se pueden descartar incluso antes de ser transmitidos a la aplicacin que enviar la imagen al receptor.

As pues, a efectos de la imagen a ubicar en la memoria auxiliar externa EEPROM, slo interesar la informacin contenida en los registros S1.

CodeWarrior genera por defecto imgenes de aplicaciones en formato S19 cuyos registros de datos (S1) no tienen nunca una longitud superior a 32 bytes. Si a esto le sumamos el hecho de que el compilador trata de agrupar el cdigo generado de forma que la memoria se vaya rellenando de forma secuencial sin dejar posiciones libres (siempre en la medida de lo posible y si no se le fuerza un comportamiento distinto mediante directivas especiales u opciones de compilacin), nos encontramos con que el S19 es un formato considerablemente optimizado y verstil para transmitir imgenes por trozos.

No obstante, puesto que los datos estn codificados en hexadecimal y ASCII, el fichero S19 ocupar como mnimo ms del doble del tamao real de la imagen de la aplicacin en memoria Flash, de modo que ser imprescindible elegir otro formato para su almacenamiento en la EEPROM (que se evaluar en el siguiente apartado).

[Link].

Formato de Almacenamiento de Imgenes en EEPROM

Puesto que la imagen de una aplicacin ZigBee generada para el chip MC13213 por el CodeWarrior for Microcontrollers v5.1 seguir el formato de ficheros .S19 (explicado en el apartado anterior), lo ms lgico ser pensar que el formato de almacenamiento de la imagen en la EEPROM ser similar a ste.

As pues, aplicar una codificacin parecida a la empleada en los ficheros S19 para el almacenamiento de imgenes en la EEPROM revertira en una considerable reduccin de las necesidades de capacidad de procesamiento por parte de la aplicacin ZigBee, lo cual simplificara el cdigo final reduciendo su tamao (ambas caractersticas muy deseables).

Un fichero S19, al estar compuesto por nmeros hexadecimales en ASCII (por ejemplo el byte 0xAA figurara como dos caracteres: AA) aparte de las cabeceras (Sx) y los Checksum (en ASCII tambin) se puede descomponer completamente en caracteres imprimibles. Esa propiedad facilita enormemente su tratamiento a la hora de encapsular registros S19 para su transmisin y procesamiento.

Es por ello muy sencillo implementar un protocolo serie (RS232) que enve como tramas registros S19 aadindoles una cabecera y fin de trama no imprimibles que garantice la

140

integridad de los datos con muy poco procesamiento adicional. Adicionalmente, el hecho de tener la imagen separada en bloques de datos cada uno de un tamao mximo de 32 bytes (ocupando 64 bytes) facilita su envo de forma inalmbrica ya que requiere de muy poco procesamiento por parte de la aplicacin. Hay que tener en cuenta que la longitud mxima del campo de datos de un paquete ZigBee, incluso incluyendo una configuracin de alta seguridad, es superior a 64 bytes.

No obstante, esta misma propiedad provoca que el tamao de los ficheros S19 sea ms del doble del tamao real que ocupa la imagen en la Flash de un dispositivo ZigBee. Puesto que muchas aplicaciones ocupan casi toda la memoria Flash disponible de un dispositivo ZigBee, el empleo del formato S19 para almacenamiento de imgenes en la EEPROM auxiliar es inviable ya que stas habitualmente no cabran.

Otra posible opcin podra ser almacenar la imagen en la EEPROM con el formato exacto que ocupar luego en la Flash, byte a byte. Puesto que la EEPROM AT24C512 dispone de 64KB de memoria no existiran problemas de espacio. Desafortunadamente este modelo implica una serie de inconvenientes graves:

Siempre se ocuparan 60KB de EEPROM (el tamao mximo de puede ocupar una imagen en Flash), por muy pequea que sea realmente la imagen del firmware almacenado. Esto obligara a sobrescribir siempre casi todas las pginas de la EEPROM acortando su vida til y ralentizando el procedimiento de actualizacin al mximo.

Al tener que sobrescribirse siempre como mnimo 60KB de EEPROM, se maximizar el riesgo de errores de lectura o escritura sobre la memoria auxiliar. Al tener que almacenar la imagen tal como se copiar en Flash, incluyendo los bytes que no contienen informacin de la aplicacin, la aplicacin encargada de recibir el firmware y almacenarlo habr de cumplir uno de los dos siguientes requisitos: a) Es capaz de recibir un gran volumen de datos en muchos paquetes grandes (en el caso de envos de trozos de la imagen de 60KB por el canal) con el riesgo de prdida, corrupcin y reintento de paquetes que implica (y saturacin de canal) b) Es capaz de recibir los datos en trozos que slo contienen secciones tiles de la imagen y luego reensamblar la imagen final rellenando con bytes 0xFF los huecos no utilizados. Esto implica una menor ocupacin del canal pero mucha ms inteligencia en la aplicacin de recepcin, lo que se traduce en una sub-aplicacin dedicada a recibir la imagen que ocupar ms memoria Flash, reduciendo el tamao mximo posible de la aplicacin ZigBee principal (la parte que trabaja de forma transparente al bootloader y al cdigo de adquisicin de la nueva imagen).

141

As pues de entre los dos extremos, almacenar la imagen en EEPROM tal y como se copiar a la Flash o guardarla como registros S19, se ha optado por implementar una solucin intermedia. sta consistir en archivar en la EEPROM los registros S19 de la nueva imagen alterando previamente su formato para reducir la cantidad de memoria que requieren.

El formato de estos nuevos registros S19, que de ahora en adelante se denominarn registros S19 modificados, ser el siguiente:

2 bytes Direccin Flash Destino

1 byte Longitud

Variable (1 32 bytes) Datos

Formato de un registro S19 modificado El campo Direccin Flash Destino ser un nmero entre 0 y 65535 que apuntar a la posicin de memoria Flash del MC13213 sobre la que se escribirn los datos del ltimo campo del registro. En el registro S19 original, al estar este campo como nmero hexadecimal en ASCII, ocupaba el doble de bytes.

El campo Longitud ser un nmero entero de un byte cuyo valor oscilar entre 1 y 32, dependiendo de la longitud del campo de datos del registro S19 modificado.

El campo de Datos incluir todos los datos del registro S19 original pero sin formato alguno (se abandona la codificacin como nmeros hexadecimales en ASCII). Esto quiere decir que el campo de datos del registro modificado S19 tendr la mitad de la longitud que tena el mismo campo en el registro S19 original.

El campo de Checksum no se hereda en el registro S19 modificado porque se presupone que todos los registros S19 originales (o una versin modificada de stos pero que incluye CRC) superan exitosamente la comprobacin de CRC antes de modificarse y almacenarse en la EEPROM, de forma que la inclusin de este campo en cada nuevo registro sera redundante.

No obstante, s que existen dos bytes de CRC de la imagen completa sitos en la cabecera de la EEPROM que permitirn comprobar la integridad del firmware en un momento dado (por ejemplo si se desea reenviar una imagen almacenada en EEPROM a otro u otros dispositivos para provocar una actualizacin masiva de equipos).

De este modo, para tener un mayor control de las imgenes almacenadas en la EEPROM y su integridad, se ha diseado una cabecera de 14 bytes sita en las posiciones ms bajas de memoria que contiene informacin adicional asociada a stas. El formato es el siguiente:

142

0x0000 0x0001
(2 bytes)

0x0002 0x0009
(8 bytes)

0x000A 0x000B
(2 bytes)

0x000C 0x000D
(2 bytes)

Flag de Regrabacin

Versin Firmware

Tamao Imagen

CheckSum

Formato y direccionamiento de la cabecera de la EEPROM El Flag de Regrabacin es un campo del que ya se ha hablado profusamente en apartados anteriores. Su funcin ser la de indicar al bootloader, durante el proceso de arranque del dispositivo, que se encuentra almacenada en la EEPROM una nueva imagen de firmware lista para sustituir a la aplicacin en ejecucin. Cuando este campo almacene el valor 0xAABB significar que el flag est activo y que la Flash se regrabar en el prximo reseteo. Cuando almacene cualquier otro valor, el flag se considerar inactivo.

La Versin del Firmware es un campo formado por 8 bytes que pretenden identificar unvocamente la imagen concreta que se encuentra almacenada en la EEPROM. De este modo, una aplicacin distribuidora de imgenes podra consultar a otros dispositivos receptores acerca de qu versin de firmware tienen instalada y sugerirles (si procede) la conveniencia de iniciar el proceso de transmisin de una nueva imagen para sustituir a la antigua. Los dispositivos que reciban una imagen podran a su vez convertirse en los transmisores de sta hacia otros dispositivos ms alejados logrando as una actualizacin masiva y eficiente de los equipos de una red. Obviamente la aplicacin puede optar por no rellenar este campo y almacenar esta informacin en RAM, pero un reseteo del dispositivo (por falta de alimentacin o cualquier otro motivo) la eliminara de la memoria.

La especificacin del formato de la versin del firmware y el modo en que ste se adjunta a cada imagen para su transmisin (ya sea dentro de registros modificados o mediante comandos especiales) es competencia de la aplicacin encargada de difundir imgenes y queda fuera del alcance de este proyecto. A efectos del bootloader este campo es completamente transparente ya que slo actualizar la memoria si el flag de regrabacin est activo, independientemente de la versin del firmware en EEPROM.

El Tamao de la Imagen indica el nmero total de bytes que ocupa la imagen almacenada en la EEPROM en concepto de registros S19 modificados (sin contar pues los 14 bytes de la cabecera). De este modo, este nmero incluye todos los bytes de los registros almacenados repartidos entre campos de datos, direcciones y longitudes.

Este campo permitir a la aplicacin que almacene el firmware en la EEPROM tener otro mecanismo de validacin de la integridad (en este caso a travs del nmero exacto de bytes) de la imagen guardada. Adicionalmente en el caso de que el dispositivo pretenda redistribuir la imagen de la EEPROM, este campo le permitir calcular con antelacin el nmero de paquetes ZigBee que habr de enviar as como le indicar hasta qu posicin de memoria puede leer

143

(hay que tener en cuenta que la EEPROM puede almacenar en el espacio no ocupado por la imagen bytes aleatorios o trozos de anteriores firmwares que deben ignorarse).

El Checksum permite realizar un control adicional de la integridad del firmware almacenado en la EEPROM. La aplicacin inalmbrica que desee distribuir la imagen a otros dispositivos o quiera verificar que el almacenamiento de sta en su EEPROM se ha realizado de forma exitosa deber calcular el checksum de la imagen y compararla con el valor de este campo. La decisin acerca de cul ser el algoritmo empleado para codificar y comprobar el checksum la habr de tomar el programador de la aplicacin ZigBee principal. En todo caso, se recomienda el empleo de un algoritmo sencillo para minimizar as los requerimientos de memoria RAM y ROM para su implementacin. Unas propuestas interesantes podran ser la suma del valor de todos los bytes de la imagen o la aplicacin de la operacin matemtica O exclusivo (XOR) a todos ellos.

Como puede deducirse fcilmente de la explicacin de la cabecera de la EEPROM, todos los campos estn reservados para comprobaciones que la aplicacin ZigBee principal puede implementar (o no) sobre las imgenes almacenadas a excepcin del flag de regrabacin. Slo este ltimo afectar al bootloader que funcionar de forma transparente al valor del resto de campos. Esto se debe principalmente a las siguientes razones:

1. El bootloader, al ser el componente comn de mltiples procedimientos posibles de actualizacin de dispositivos, ha de permanecer lo ms sencillo posible. De este modo ocupar poca memoria (pudiendo incluirse dentro de aplicaciones complejas que ocupen mucho), y ser ms rpido y robusto (cuanto menor sea el nmero de lecturas y escrituras en Flash y EEPROM, menor ser la probabilidad de que suceda un fallo crtico). 2. Dejar la mayor parte de las comprobaciones a la aplicacin principal de carga remota permite una mayor flexibilidad en el diseo de la aplicacin de actualizacin, permitindole elegir el formato del crc y el control de versiones ms adecuado para el entorno con que se trabaje. 3. El bootloader parte de la premisa de que la aplicacin de carga remota ha depositado una imagen cuya integridad ha sido convenientemente comprobada antes de activar el flag de regrabacin. Esto se debe a que el bootloader no tiene control sobre el modo en que se adquiere la imagen (orden de paquetes, checksums, longitudes de tramas, etc.) y las comprobaciones que puede hacer sern siempre mucho menos exhaustivas (y muy probablemente redundantes) en comparacin con las que la aplicacin principal puede realizar.

Una vez se ha elegido el formado de almacenamiento de los datos del firmware en la EEPROM (mediante registros S19 modificados) y se ha descrito la cabecera que se incluir al principio de

144

sta, se puede esquematizar el mapa de memoria resultante de la EEPROM AT24C512 mediante la siguiente figura:

Mapa de memoria de la EEPROM Llegados a este punto, es necesario realizar una serie de comprobaciones acerca del tamao estimado de las imgenes de aplicaciones almacenadas en la EEPROM en forma de registros S19 modificados para evaluar si el formato elegido es suficientemente ptimo o si es necesario modificarlo o introducir alguna limitacin adicional al tamao de la imagen.

Si se examina el modelo de memoria Flash del microcontrolador incluido en la plataforma MC13213 (ver apartado [Link]), se deduce fcilmente que una aplicacin ZigBee puede llegar a ocupar un mximo de 60KB de memoria (61440 bytes). No obstante, por lo menos tres pginas de ella estarn ocupadas por el bootloader (3x512 bytes) y no se almacenarn en la EEPROM ya que no se sustituirn en Flash. Segn esto, el tamao mximo (en bytes) que la imagen de una aplicacin ZigBee puede llegar a ocupar en la memoria Flash del MC13213 (excluyendo el tamao asociado al bootloader, 3 pginas, que slo se grabarn en el dispositivo una vez justo al final del proceso de produccin) ser:

145

Imagen _ App _ ZigBee _ en _ Flash MAX = Flash TOTAL Tamao BOOTLOADER Imagen _ App _ ZigBee _ en _ Flash MAX = 61440 3 512 Imagen _ App _ ZigBee _ en _ Flash MAX = 59904 (bytes )

N registros _ S19 aprox =

Imagen _ App _ ZigBee _ en _ FlashMAX

Cabecera S19 _ mod ificado = Campo Direccin

= 1872 (registros S19 ) bytes 32 registro S 19 + Campolongitud _ S 19 = 2 + 1 = 3 (bytes)

(bytes )

Incremento _ Imagen _ en _ EEPROM = N registros _ S19 aprox Cabecera S 19 _ mod ificado = 1824 3 = 5616 (bytes) Imagen _ App _ en _ EEPROM Aprox = Imagen _ App _ ZigBee _ en _ FlashMAX + Incremento _ Imagen _ en _ EEPROM Imagen _ App _ en _ EEPROM Aprox = 65520 (bytes)
Este resultado ilustra el tamao que ocupara almacenada en EEPROM (con el formato elegido) una imagen de firmware que ocupase la totalidad de la memoria Flash disponible en un dispositivo. A este resultado habra que sumarle los 14 bytes de la cabecera EEPROM y se tendra un total de 65534 bytes, justo dos bytes menos que la capacidad total de la EEPROM, de modo que se dispondra de espacio suficiente para su almacenamiento.

No obstante, existen algunos casos ms desafortunados que ste (aquellas imgenes con menos datos pero con muchos huecos de menos de tres caracteres entre ellos), en los cuales la imagen podra no caber en la EEPROM por muy pocos bytes. Estos casos son muy poco probables ya que el compilador optimiza la colocacin de los datos en la memoria minimizando los huecos vacos entre ellos a menos que sean muy grandes.

Sin embargo, como se explic en el captulo [Link], se espera que toda aplicacin ZigBee desarrollada para el dispositivo ND07 emplee parte de su memoria Flash para el almacenamiento de variables de contexto. Eso quiere decir que:

Tres pginas se reservarn para el almacenamiento dinmico de datos de contexto no voltiles (lo cual implica que el S19 generado por el CodeWarrior no tendr registros asociados a esas posiciones de memoria ya que se rellenarn de forma dinmica durante el tiempo de ejecucin de la aplicacin del dispositivo).

Adicionalmente, por lo menos 2KB de Flash y 150 bytes de RAM del dispositivo se reservarn para el cdigo de control del componente NVM (hay que tener en cuenta que cualquier API desarrollado para el almacenamiento de datos no voltiles ocupar esta cantidad de memoria o ms). El cdigo asociado a este API s que estar incluido en el firmware distribuido mediante registros S19.

As pues, ser necesario modificar las ecuaciones anteriores:

146

Imagen _ App _ ZigBee _ en _ FlashMAX = FlashTOTAL TamaoBOOTLOADER Datos _ de _ ContextoNVM Imagen _ App _ ZigBee _ en _ FlashMAX = 61440 3 512 3 512 Imagen _ App _ ZigBee _ en _ FlashMAX = 58368 (bytes)

El tamao mximo de la imagen en memoria Flash se ha reducido lo suficiente como para que al realizar la aproximacin de repartirlo en registros modificados de tamao mximo (32 bytes de datos y 3 de cabecera) siga quedando espacio libre como para que aumente considerablemente el nmero de registros ocupados (debido a la no homogeneidad de la distribucin de datos dentro del firmware) y siga cabiendo holgadamente.

N registros _ S19 aprox =

Imagen _ App _ ZigBee _ en _ FlashMAX bytes 32 registro S 19

(bytes )

= 1824 (registros S19 )

Cabecera S19 _ mod ificado = Campo Direccin + Campolongitud _ S19 = 2 + 1 = 3 (bytes) Incremento _ Imagen _ en _ EEPROM = N registros _ S19 aprox Cabecera S19 _ mod ificado = 1824 3 = 5472 (bytes) Imagen _ App _ en _ EEPROM Aprox = Imagen _ App _ ZigBee _ en _ FlashMAX + Incremento _ Imagen _ en _ EEPROM Imagen _ App _ en _ EEPROM Aprox = 63840 (bytes) Espacio _ Ocupado _ en _ EEPROM Aprox = Imagen _ App _ en _ EEPROM Aprox + Cabecera EEPROM = 63840 + 14 Espacio _ Ocupado _ en _ EEPROM Aprox = 63854 (bytes)
As pues, se pueden concluir las siguientes afirmaciones:

El formato elegido para almacenar la imagen en EEPROM, mediante registros S19 modificados, permite almacenar casi todas las imgenes posibles para este chip. Las posibles excepciones implicaran que el programador forzase explcitamente al compilador a distribuir los datos de la imagen en Flash de forma subptima.

Por otro lado, para la mayora de imgenes posibles de aplicaciones ZigBee, este formato optimiza el espacio empleado para su almacenamiento en EEPROM, acelerando el procedimiento de actualizacin del dispositivo y minimizando las probabilidades de que tengan lugar fallos crticos.

Para protegerse ante todas las posibles situaciones (por improbables que sean), la aplicacin encargada de almacenar en EEPROM la imagen recibida deber comprobar que sta, distribuida en registros S19 modificados, ocupa menos de 63840 bytes en total. De lo contrario no activar el flag de regrabacin puesto que no se podr almacenar en su totalidad (ni se distribuir a otros dispositivos).

147

4.1.4. Desarrollo del Bootloader [Link]. Estructura de la Aplicacin

Como ya se ha comentado anteriormente, el bootloader desarrollado consiste principalmente en la modificacin del cargador de arranque incluido en el firmware del dispositivo de forma que incluya una nueva etapa.

La nueva etapa programada ser capaz de sustituir el firmware residente en la memoria no voltil (Flash) del dispositivo por una nueva imagen previamente almacenada en la EEPROM auxiliar. Este reemplazo no afectar a las pginas de memoria en las que resida esta nueva etapa del cargador de arranque aunque s puede afectar a las dems.

El funcionamiento de este nuevo cargador de arranque se ilustra en la siguiente figura:

148

Cargador de Arranque Primeras fases del proceso de arranque Inicializacin de los registros I 2C del microprocesador y de la API simplificada para la 2 comunicacin I C con la memoria auxiliar

Flag de sustitucin de firmware en EEPROM activo?

NO Reintento

SI

Sustitucin del firmware del dispositivo con imagen almacenada en EEPROM

NO

Sustitucin realizada con xito?

SI

Nueva Etapa del Bootloader *

ltimas fases del proceso de arranque

Desactivacin de Flag de sustitucin de firmware y Reset

Reset!!

Ejecucin del Gestor de Tareas y de la Aplicacin ZigBee Principal

*: Esta nueva etapa , situada entre las

fases iniciales del arranque del dispositivo , ser el Bootloader desarrollado en este proyecto .

Diagrama de la estructura de la aplicacin de bootloader

Como puede observarse en el esquema anterior, la nueva etapa del bootloader no modificar sustancialmente el proceso de arranque del dispositivo en las situaciones en que no exista en la memoria auxiliar un firmware listo para sustituir al actual (hecho que se indicar con el flag en EEPROM cuando sea necesario).

As pues, en la mayora de los casos en que el dispositivo arranque, la nueva etapa del bootloader slo se encargar de inicializar los puertos imprescindibles para leer (va protocolo

149

I2C) el flag de regrabacin situado EEPROM y continuar despus la inicializacin de forma transparente al resto de modificaciones introducidas.

Una decisin de diseo importante a tomar en este punto fue la conveniencia de situar el flag de regrabacin en la memoria externa (EEPROM) accesible mediante el protocolo I2C en lugar de en la memoria interna del dispositivo (Flash). Esto se debi principalmente a los siguientes factores:

La grabacin de un byte en una posicin al azar de la memoria ROM interna implica el borrado previo de la pgina completa que la contiene (512 bytes). De modo que se desperdiciara demasiada memoria ROM para almacenar el flag de grabacin (uno o dos bytes).

La memoria ROM de Freescale dispone de 2 pginas por defecto utilizables para el almacenamiento de variables cuyo valor debe ser conservado entre los distintos reseteos del dispositivo (para disponer de 2 pginas con ese fin es necesario reservar 3). Estas pginas simulan el funcionamiento de una memoria RAM no voltil (aumentando el nmero mximo posible de regrabaciones mediante algoritmos especiales) sobre una memoria ROM (ver apartado [Link]). Desafortunadamente se han detectado y confirmado varios errores en las funciones asociadas a este componente NVM (Non-Volatile Memory) dentro de las libreras de Freescale que provocaban un funcionamiento irregular. As pues, se ha descartado el empleo de la NVM (y de la API asociada que Freescale suministra para su manejo) para el almacenamiento del flag de regrabacin.

La elaboracin de la nueva etapa del bootloader ha requerido del desarrollo de una API simplificada para la comunicacin I2C con la EEPROM externa. De este modo la programacin de la comprobacin del flag de regrabacin en EEPROM es casi inmediata.

El inconveniente claro de esta eleccin es la necesidad de inicializar el mdulo I2C del chip y realizar una lectura de la EEPROM externa en una de las primeras fases del arranque, con el consecuente incremento del tiempo total de arranque del dispositivo. No obstante, dada la relativamente alta velocidad de la comunicacin I2C que se ha empleado, este tiempo adicional es pequeo (varios milisegundos).

Otra decisin de diseo realizada ha sido que para que la aplicacin indicase al bootloader que exista un firmware en la EEPROM preparado para sustituir al actual, el flag de regrabacin deba de almacenar el valor 0xAABB (valor poco probable aleatoriamente con muchos unos y ceros en binario). As pues se emplearon 2 bytes en lugar de uno para minimizar al mximo la probabilidad de la aparicin de un falso positivo.

150

Una vez la aplicacin principal ha decidido actualizar su firmware y ha almacenado la imagen de la nueva aplicacin en la memoria auxiliar EEPROM (respetando el formado especificado en el apartado 4.1.3), proceder a verificar su integridad. Si esta operacin se finaliza exitosamente, la aplicacin activar el flag de actualizacin del firmware y resetear el dispositivo para que comience a actualizarse (de este modo la aplicacin y el bootloader pueden funcionar de forma casi completamente independiente).

El proceso de actualizacin del firmware de un dispositivo ZigBee es la parte ms importante y crtica del proyecto que, a pesar de todas las restricciones que deben respetarse para su correcto funcionamiento, puede esquematizarse de forma simplificada mediante la siguiente figura:

151

Inicio Actualizacin (Flag Regrabacin Activo) Lectura de un registro modificado S19 almacenado en la EEPROM (obtenido mediante la comunicacin I2C): Ledo el n de datos del registro (N) Leda la posicin de Flash donde se almacenarn (puntero_flash) Ledos los datos (se almacenan en RAM) Borrado Especial de la pgina 127: Se almacena la direccin del ltimo registro S19 ledo de EEPROM (puntero_lectura_aux) Lectura del valor anterior en Flash de las posiciones asociadas al vector de interrupcin I2C. Borrado Completo de pgina nmero 127 Rescritura del valor del vector de interrupcin I2C en su posicin (0xFFCE-0xFFCF) con el valor ledo de Flash. Re-lectura del registro S19 apuntado por puntero_lectura_aux y continuacin del proceso de actualizacin.

Existen datos en el registro ledo destinados a la pgina 127 y no se ha borrado todava?

SI

NO

puntero_flash apunta a una posicin no sobrescribible?[I]

NO

SI

Se apunta la siguiente posicin en flash (puntero_flash++) y se descarta dato (N--) [IV]

puntero_flash apunta a una pgina que an no se ha borrado? [II]

NO

SI

Borrar pgina flash que contiene la direccin apuntada por puntero_flash. [III]

Escritura de 1 byte en la posicin de memoria Flash apuntada por puntero_flash. (N--) y (puntero_flash++) Quedan datos por escribir? (puntero_flash!=0x0000?)
NO SI

Datos del registro procesados? (N==0?)

NO

SI

Bucle de grabacin de un registro S19 en memoria Flash

Fin de la Actualizacin: Comprobaciones varias de xito de regrabacin Puesta a cero de flag de regrabacin Reset del dispositivo

Algoritmo de actualizacin del firmware del ND07

152

[I]

: Las posiciones de memoria ocupadas por el bootloader, la NVM y el vector de

interrupcin de I2C no se sobrescriben en el bucle principal. Esto se debe a que las pginas ocupadas por el bootloader y la NVM nunca se actualizarn y el vector de interrupcin slo se sobrescribir en la fase final (proceso etiquetado como Borrado Especial de la pgina 127 en el esquema anterior) cuando se lea un registro modificado S19 con datos para la ltima pgina de la memoria Flash.
[II]

: Para poder escribir un dato en una posicin de memoria Flash es imprescindible borrar

previamente la pgina completa que la contiene. Puesto que un registro modificado S19 puede incluir datos pertenecientes a pginas distintas, es necesario realizar esta comprobacin con cada byte a escribir para evitar fallos de actualizacin de la memoria. Adicionalmente, se podran borrar todas las pginas vacas (aquellas para las que no existan registros con datos en la EEPROM) para limpiar la memoria lo mximo posible. Sin embargo, este procedimiento adicional no se realizar ya que reduce innecesariamente la vida til de la memoria Flash (que est limitada en cuanto al nmero mximo de ciclos de escritura que se pueden efectuar sobre ella) y aumenta el tiempo total necesario para finalizar el proceso de actualizacin.
[III]

: Este apartado ha de incluir la comprobacin de si la pgina a borrar es la nmero 8 o la

nmero 12, ya que stas requieren de un direccionamiento especial para su reinicializacin (esto se debe a que no son pginas Flash completas de 512 bytes).
[IV]

: En el hipottico caso en el que la aplicacin encargada de recibir y almacenar el

firmware no haya descartado las pginas relativas al bootloader (que obviamente no se sobrescribir) los datos relativos a stas se ignorarn.

Segn la figura anterior podemos distinguir los siguientes bloques fundamentales:

Bucle principal, encargado de leer registros S19 desde la EEPROM Bucle secundario, encargado de borrar cada pgina de memoria Flash y sobrescribirla byte a byte con los datos ledos de cada registro modificado S19

Bloque de tratamiento especial de la pgina especial 127 Bloque de comprobaciones finales y Reset

A continuacin se procede a describir estos bloques con un poco ms de profundidad.

[Link].1.

Bucle de Lectura de Registros S19 Modificados

Este bloque funcional del Bootloader es el encargado de la recuperacin del firmware almacenado en la memoria auxiliar EEPROM con el formato S19 modificado que se describe en el apartado 4.1.3. Este bucle de lectura de la EEPROM se repetir al menos tantas veces como registros modificados S19 almacene la memoria auxiliar y cada iteracin implicar, en la mayora de los

153

casos, una llamada al bucle secundario para la grabacin de los datos ledos sobre una posicin concreta de la memoria Flash integrada en el chip. En este proceso, al igual que en el resto de los bloques que componen el bootloader, se realizan una serie de suposiciones que han de cumplirse para que la lectura concluya de forma exitosa (estos supuestos no se comprobarn en el bootloader para reducir al mximo el tamao de la memoria ocupada por ste). As pues lo prerrequisitos sern los siguientes:

Los registros modificados S19 han de almacenar datos para direcciones de memoria Flash ordenados secuencialmente de forma creciente, de manera que el registro con datos correspondientes a la direccin de ndice inferior (como mnimo 0x1080) ser el primero de la EEPROM y el registro que contenga el vector de interrupcin de Reset (correspondiente a las posiciones 0xFFFE-0xFFFF de la Flash) ser el ltimo.

La aplicacin encargada de almacenar el nuevo firmware en la EEPROM (fuera del mbito de este proyecto) debe asegurar la integridad de los registros de datos (mediante mecanismos de checksum, por ejemplo), la optimizacin de su almacenamiento (eliminando registros asociados a pginas que no se sobrescribirn como las del bootloader) y la completitud de la imagen (que no falte ningn registro necesario).

La imagen almacenada debe ocupar como mnimo dos registros S19 (cosa ms que probable puesto que con 64 bytes es prcticamente imposible disear una aplicacin ZigBee).

Cada registro modificado S19 no debe almacenar ms de 32 bytes de datos (y ha de contener al menos un byte de datos) y su campo de longitud debe almacenar el tamao exacto del nmero de bytes de ese registro.

Todos estos requisitos son muy fcilmente alcanzables ya que la configuracin por defecto del IDE CodeWarrior for MicroControllers v5.1, que es la herramienta suministrada por Freescale para compilar cdigos ZigBee para este chip, genera los registros en el formato especificado (en cuanto a tamao y nmero de registros, orden de stos segn la direccin apuntada, etctera) de modo que no deberan plantear ningn problema. Por otro lado, los requisitos de integridad exigidos a la aplicacin que almacenar el nuevo firmware en la EEPROM son los mnimos que un proceso tan crtico como es la sustitucin del programa en ejecucin de un dispositivo requerir siempre.

Como ya se ha mencionado con anterioridad, la comunicacin con la EEPROM auxiliar integrada en la placa del ND07 (modelo AT24C512) ha requerido de la programacin de una versin simplificada del protocolo I2C para poder realizar lectura y escrituras sobre ella. Puesto que el ND07 slo dispone de dos dispositivos conectados al bus I2C, el chip MC13213 funcionando siempre como maestro y la EEPROM funcionando siempre como equipo esclavo, situaciones como la prdida de arbitraje no se darn nunca, ya que en ningn caso varios dispositivos en modo maestro competirn por el bus. De este modo, no sera necesario

154

implementar el protocolo completo para lograr una perfecta comunicacin entre los dos integrados. No obstante, se desarroll un API simplificado que cubre el protocolo completo I2C puesto que el mdulo del MC13213 estaba especficamente preparado para ello y no requera de un esfuerzo significativo adicional ni incrementaba el tamao del cdigo resultante de forma apreciable. Para ello ha sido necesario apoyarse en el interfaz que otorga el mdulo I2C de la plataforma MC13213 mediante los registros descritos en el apartado [Link] y sus interrupciones asociadas.

Previamente fue necesario desarrollar dos funciones auxiliares: La funcin de atencin a la interrupcin I2C: configurada para activarse ante cualquiera de los siguientes sucesos en el bus: 1. Deteccin de prdida de arbitraje 2. Finalizacin de transferencia de un byte (mediante la recepcin de ACK o NACK por parte del dispositivo esclavo) 3. Recepcin de una trama que direcciona al MC13213 como esclavo de una transmisin (esto no suceder nunca en el ND07 ya que el microprocesador funcionar siempre en modo maestro y la EEPROM en modo esclavo) De este modo cada vez que se active la interrupcin se borrarn los flags de alarma y se actualizar una variable global (llamada Estado en los diagramas consiguientes) con el resultado de la ltima operacin realizada. La funcin de espera activa: encargada de evaluar el resultado de la ltima operacin efectuada sobre el bus I2C (lectura o escritura) mediante polling (proceso de consulta reiterada) de la variable global de estado (que se actualiza mediante la rutina de atencin de la interrupcin I2C) indicando despus al exterior el xito o fracaso de sta. Simultneamente activa un temporizador que si vence (llega a cero) sin recibir respuesta alguna del bus (mediante la llegada de interrupciones I2C o cambios en el registro IICS), da la comunicacin por fallida notificando el estado de error en el canal.

A continuacin se presenta un diagrama simplificado de las dos funciones programadas para facilitar su comprensin:

155

Espera Activa de Resultado de Operacin (Contador=100)

Interrupcin I2C

SI

IICS = Prdida de Arbitraje?

NO

Estado sin cambios y Contador>0?

SI

Contador -Estado = Prdida de Arbitraje

NO

Estado = Obtenida Respuesta del AT24C512

Estado = Prdida de Arbitraje o Contador=0?

NO

SI

Salida=Error Comunicacin I2C

Limpieza de Flags IICS

RTI
SI

IICS==NACK?
NO

Salida=NACK del AT24C512

Salida=ACK del AT24C512

Espera activa de un ACK del bus y su relacin con la interrupcin I2C del MC13213 A continuacin, basndose en las funciones de espera activa y de atencin de interrupcin I2C recin descritas, se desarrollaron las funciones principales de lectura y escritura I2C. Ambas sern despus necesarias para realizar operaciones de lectura sobre la EEPROM auxiliar. El algoritmo de lectura I2C programado inicializar el estado de los registros y los configurar para poner al MC13213 en modo recepcin (dentro del rol de maestro) y para responder con un bit de ACK los bytes ledos del bus I2C. A continuacin, se proceder a realizar una lectura del registro IICD que forzar el inicio de la operacin de lectura sobre el bus. Finalmente, se espera (mediante las funciones de espera activa y de atencin de interrupcin I2C) a que el dispositivo esclavo termine de transmitir y se deposite exitosamente un nuevo dato para leer en el registro ICCD. El algoritmo de escritura I2C programado inicializar el estado de los registros y los configurar para poner al MC13213 en modo transmisin (dentro del rol de maestro). A continuacin, se realizar el envo de cada byte escribiendo el dato deseado en el registro IICD. Finalmente, se espera a recibir un asentimiento (ACK o NACK) o cdigo de error del esclavo mediante la rutina de espera activa y de atencin de interrupcin ya explicadas.

156

A continuacin se presenta un diagrama de las dos funciones descritas, que sern la base principal para las operaciones de lectura y escritura sobre la memoria auxiliar AT24C512 mediante el bus I2C:
Escritura I2C Lectura I2C

Estado = Prdida de Arbitraje?

NO

SI

Estado = Prdida de Arbitraje? Salida=Error Comunicacin I2C

NO

SI

Estado = Reposo

Activar bit ACK (o NACK) en el registro IICC para leer (o no) varios bytes seguidos *

Salida=Error Comunicacin I2C

Activar Modo de Transmisin (activando bit 4 de IICC) Activar Modo de Recepcin (desactivando bit 4 de IICC) Iniciar Transmisin (escribiendo dato a enviar en IICD) Estado = Reposo Iniciar Lectura (leyendo registro IICD) Espera Activa de Resultado de Operacin

Espera Activa de Resultado de Operacin

Salida=Error Comunicacin I2C

NO

Recepcin de un byte completo?

SI

Activar Modo de Transmisin (para que la prxima lectura de IICD no lance otra iteracin de lectura I2C)

Lectura de byte de IICD y Salida exitosa

Proceso de lectura y escritura en el bus I2C desde el MC13213 *: El API I2C diseado soporta la lectura continua de bytes consecutivos del bus dentro de la misma comunicacin (es decir, sin seales STOP intermedias). Para lograrlo bastar con activar la opcin de ACK (en lugar de NACK) en el registro IICC para que una vez recibido cada byte del canal el MC13213 asienta la operacin y contine leyendo ms bytes (mediante lecturas del registro IICD) repitiendo la secuencia para cada dato.

157

Llegados a este punto, se ha desarrollado un conjunto de funciones que permiten la comunicacin entre la plataforma MC131213 y la memoria auxiliar AT24C512 a travs de un protocolo conforme con el bus I2C. No obstante, todava es necesario emplear dichas funciones para la creacin de un API de lectura (y posteriormente escritura) sobre la EEPROM que permita al usuario trabajar de forma transparente a dicho bus. As pues, basndose en las funciones I2C recin desarrolladas y explicadas, a continuacin se implementaron principalmente dos funciones de lectura y escritura sobre la EEPROM siguiendo los pasos descritos para ello en el apartado 3.9 acerca del bus I2C y su aplicacin para el componente AT24C512 (junto con su semntica especfica para apuntar posiciones de memoria).

La funcin de lectura de la EEPROM comprende las siguientes actividades: Control de bus ocupado (mediante lectura de un bit concreto del registro IICS) y configuracin de la comunicacin (borrado de los flags del IICS, reinicializacin de las variables de estado y seleccin del rol de maestro en el registro IICC) Envo de bit START Escritura I2C de la direccin de la EEPROM y del bit R/W a 0 (escritura) Escritura I2C de la posicin de memoria a leer (2 bytes) Envo de bit de START repetido (mediante el registro IICC) para cambiar el modo de transmisin Escritura I2C de la direccin de la EEPROM de nuevo pero ahora con el bit R/W a 1 (cambio a modo lectura) Lectura I2C de uno o varios bytes de datos Finalizacin de la operacin de lectura, limpiado de registros de estado y comprobacin de errores.

La funcin de escritura de la EEPROM es ms sencilla y comprende las siguientes actividades: Control de bus ocupado (mediante lectura de un bit concreto del registro IICS) y configuracin de la comunicacin (borrado de los flags del IICS, reinicializacin de las variables de estado y seleccin del rol de maestro en el registro IICC) Envo de bit START Escritura I2C de la direccin de la EEPROM y del bit R/W a 0 (escritura) Escritura I2C de la posicin de memoria sobre la que se va a empezar a escribir (2 bytes) Escritura I2C de uno o varios bytes de datos Finalizacin de la operacin de escritura, limpiado de registros de estado y comprobacin de errores Espera activa de diez milisegundos (tiempo mnimo recomendado por el fabricante del dispositivo AT24C512 entre dos escrituras sobre la memoria)

158

Una vez se ha programado un API completo para la lectura y escritura de posiciones de memoria de la EEPROM externa, el bucle que recupera los registros modificados S19 almacenados en la memoria AT24C512 es conceptualmente muy sencillo de disear.

Como ya se ha mencionado en el apartado 4.1.3, en el mapa de memoria de la EEPROM se podrn separar los siguientes dos bloques:

Cabecera (14 bytes) Registros modificados S19, cada uno con un campo de direccin destino (2 bytes), un campo de longitud de registro (1 byte) y de uno a 32 bytes de datos (en ese orden).

De este modo, el proceso de lectura de registros modificados S19 se iniciar a partir de la posicin 0x000E de la memoria EEPROM (justo despus de la cabecera) y cada iteracin seguir el esquema expuesto a continuacin:

Lectura EEPROM de la direccin destino de los datos del registro modificado S19 (2 bytes)

Lectura EEPROM de la longitud de datos (N) almacenados en el registro (1 byte)

Lectura EEPROM y almacenamiento en RAM de N bytes de datos del registro

Algoritmo recursivo de lectura de registros S19 modificados Una vez se dispone en RAM de los datos del registro S19 modificado, se llamar al bucle de sobrescritura de memoria Flash (descrito en el prximo sub apartado) que decidir si esos datos se copian inmediatamente a la Flash, si es necesario previamente borrar una nueva pgina (si los datos van destinados a alguna pgina que todava no haba sido formateada por el bootloader), o si se descartan (si los datos pertenecen a regiones protegidas como el bootloader, la NVM o la ltima pgina).

Existe una excepcin que se dar cuando alguno de los datos del registro ledo est destinado a actualizar una posicin de memoria contenida en la ltima pgina de la Flash. En este caso el control del proceso de actualizacin pasar al bloque funcional encargado de borrar la pgina Flash nmero 127 (bloque explicado despus del bucle de sobreescritura Flash) el cual, cuando concluya su cometido, llamar de nuevo al bloque de lectura de EEPROM para que termine de leer firmware. todos los registros S19 modificados que quedan almacenados del nuevo

159

[Link].2.

Bucle de Sobrescritura de la Memoria Flash

Este bloque funcional del Bootloader ser el encargado de procesar los datos de los registros modificados S19 segn se vayan recuperando stos de la EEPROM mediante el bucle principal de lectura a travs del bus I2C. Las llamadas a este bloque se realizarn cada vez que el bloque de lectura de EEPROM (explicado en el apartado anterior) deposite en memoria voltil (RAM) datos destinados a reescribir posiciones concretas de la memoria Flash del dispositivo.

As pues las funciones principales de este bloque, segn se presentan esquematizadamente en subapartados anteriores, pueden resumirse en los siguientes puntos:

Comprobar que los datos del registro (cada uno de ellos) no van destinados a posiciones reservadas de memoria Flash (pginas de la NVM o del propio bootloader), y descartarlos en caso afirmativo. En principio un diseo inteligente del sistema de envo y almacenamiento de imgenes no dara nunca lugar a esta situacin ya que para optimizar recursos no se enviaran ni almacenaran nunca los registros S19 relativos a posiciones de memoria que no se actualizarn.

Comprobar si alguno de los datos de cada registro ledo va destinado a una pgina de memoria que no se ha borrado previamente. En caso afirmativo el algoritmo ir realizando llamadas peridicas a las funciones de borrado de pginas Flash reinicindolas segn sea necesario. No obstante, las pginas de memoria que no vayan a ser actualizadas por no existir datos almacenados destinados a ellas, no se borrarn para maximizar la vida til de la Flash y la velocidad de la actualizacin.

En el caso de disponer por primera vez de datos destinados a la ltima pgina de Flash, se encargar su borrado previo a un bloque funcional especfico (descrito ms adelante) que adicionalmente reescribir el vector de interrupcin I2C y permitir a este bloque seguir despus con su funcionamiento habitual.

Si las anteriores comprobaciones son superadas exitosamente, el algoritmo proceder a regrabar cada byte de datos del registro modificado S19 almacenado temporalmente en memoria RAM mediante llamadas al API de grabacin Flash previamente programado.

As pues este bloque funcional, aparte de realizar una serie de comprobaciones sobre los datos depositados en RAM por el bloque de lectura de EEPROM, se encargar de la operacin ms delicada del proceso de actualizacin: el borrado y regrabado de la memoria Flash del dispositivo.

160

Para ello, la parte del cdigo del bootloader encargada del borrado y regrabado de la memoria Flash se apoyar en el interfaz que suministra la plataforma MC13213 para el manejo de sta y cuyo funcionamiento se ha explicado previamente en el apartado [Link].

De este modo cuando se necesite realizar una operacin de borrado o reescritura de la memoria Flash el bootloader seguir, basndose en los registros FCDIV, FSTAT y FCMD, el siguiente algoritmo:

Reiniciar los registros implicados (principalmente el registro FCDIV, que slo se configurar una vez al principio del bootloader) y limpiar toda notificacin de errores pasados.

Escribir un byte de datos en una direccin de la memoria Flash (esta operacin realmente no se ejecutar todava, pero el acto de solicitarla provoca que el controlador Flash encole la peticin). En el caso de que la operacin que se vaya a solicitar a continuacin no sea una escritura, el byte de datos escrito en la Flash ser irrelevante, ya que slo se emplear para indicar al interfaz el deseo de ejecutar un comando sobre una pgina determinada de la memoria no voltil (aquella que incluya la posicin sobre la que se ha solicitado grabar el byte de datos).

Escribir el comando deseado en el registro FCMD para encolar la peticin en el buffer del controlador Flash. De los cinco comandos posibles, el bootloader solo emplear el de grabacin estndar (0x20) o el de borrado de pgina (0x40) dependiendo de cada fase del proceso de actualizacin de la memoria (ver apartado [Link] para una explicacin detallada de las razones de este hecho).

Escribir un 1 en el bit FCBEF del registro FSTAT para limpiar el flag y lanzar el procesado del comando solicitado. Comprobar el bit FCCF del registro FSTAT hasta que se active (a 1) indicando que la operacin solicitada ha finalizado. A continuacin se comprobar si ha tenido lugar algn error y se limpiarn los registros de estado para prepararlos para cualquier operacin posterior.

Todos estos pasos pueden observarse de forma esquemtica en el siguiente esquema aplicable tanto para las operaciones de regrabado como para las de borrado de pgina, cambiando slo el valor del comando enviado al interfaz Flash en cada caso:

161

Algoritmo de escritura y borrado de la memoria flash [33] Como ya se ha explicado en apartados anteriores, uno de los inconvenientes que plantea la memoria Flash de la plataforma MC13213 es que recomienda que no se contine leyendo de la memoria ROM mientras se est procesando o solicitando un comando de borrado o reprogramacin de la Flash. No acatar esta recomendacin puede provocar errores de lectura que den lugar a problemas graves en el flujo natural del programa.

Este grave inconveniente se ha resuelto programando todo el algoritmo del esquema anterior directamente en ensamblador, de forma que cuando es necesario ejecutarlo el bootloader realiza una copia de ste a una posicin de la memoria RAM junto con los datos a grabar (en el caso de ejecutarse una escritura en Flash). A continuacin se apunta el contador de programa a dicha posicin, de forma que el algoritmo contina ejecutndose desde memoria voltil mientras dura el proceso de actualizacin de la Flash. Una vez termina el procesado del comando solicitado, el contador de programa vuelve a apuntar a la posicin de memoria Flash original del bootloader.

Como puede apreciarse, el algoritmo ms crtico del bootloader es considerablemente sencillo de implementar y el cdigo resultante ocupar poca memoria (de lo contrario sera imposible depositarlo en RAM mientras se procesa cada comando sobre la memoria Flash).

No obstante, la problemtica principal de este bloque reside en que se ejecutar muchas veces a lo largo de una actualizacin de firmware y que los errores que puedan darse durante este proceso tienen difcil o nula solucin (la mayor parte de ellos derivados de una posible prdida

162

de alimentacin durante el proceso de borrado y regrabado). Es por ello que este bloque se ha programado optimizando su velocidad de procesado y reduciendo al mximo el tamao del cdigo final generado.

Una vez este bloque funcional ha terminado de procesar todos los datos que el bloque de lectura de la EEPROM haba depositado para l en RAM (proceso que puede comprender descartar bytes, borrar pginas y/o regrabar posiciones de Flash), se devolver el control al segundo para que contine leyendo de la EEPROM datos destinados a la actualizacin de pginas de la memoria Flash (que seguramente volvern a resultar en nuevas llamadas a este bloque).

Cuando este bloque termine de reescribir las ltimas posiciones de memoria Flash (0xFFFE y 0xFFFF) correspondientes al vector de interrupcin de reset, significar que el proceso de borrado y regrabado de la memoria Flash est a punto de concluir y se ceder el control al bloque final de la actualizacin del firmware (explicado ms adelante).

[Link].3.

Bloque de Sobrescritura de la Pgina Flash 127

Como ya se ha mencionado, aunque casi la totalidad del proceso de actualizacin del firmware tendr lugar en los dos bloques funcionales que se acaban de describir, el borrado de la ltima pgina de la Flash (la nmero 127) requerir de un tratamiento especial que se desarrollar en este bloque funcional.

Esto se debe a que dicha pgina contiene los registros no voltiles, el puntero de inicio de programa y los vectores de interrupcin, entre los cuales se encuentra el responsable de la comunicacin I2C, imprescindible para realizar lecturas sobre la memoria auxiliar EEPROM externa (ver apartado [Link]). De este modo, de realizarse un borrado de la ltima pgina y no sobrescribirse inmediatamente el valor del vector de interrupcin I2C, ya no podran leerse nuevos registros S19 de la EEPROM ni terminar pues el proceso de actualizacin de la Flash.

Puesto que el valor almacenado en dicho vector de interrupcin (concretamente en las posiciones 0xFFCE y 0xFFCF) no debera de cambiar nunca para no alterar el funcionamiento del bootloader, no ser necesario recorrer los registros S19 en busca de dicho valor. Bastar con leer el valor antiguo almacenado en el vector de interrupcin, borrar la pgina y reescribir dicha posicin con el mismo valor.

La plataforma MC13213 recomienda no reescribir ms de una vez una posicin de memoria Flash despus del borrado completo de la pgina que la contiene pero no impone ninguna restriccin acerca del orden en que se han de reescribir las posiciones de cada pgina. As

163

pues, el bootloader actualizar todas las pginas de la Flash para las que tiene datos almacenados reescribiendo sus bytes secuencialmente en orden creciente de direccin a excepcin de la ltima pgina, que borrar completamente, reescribir el vector de interrupcin I2C y finalmente el resto de datos (de nuevo secuencialmente en orden creciente e ignorando el valor repetido del vector I2C).

Para realizar las operaciones de borrado de la pgina 127 y la sobreescritura del vector de interrupcin I2C por su mismo valor, este bloque funcional har uso de las mismas funciones empleadas en el bloque funcional de sobreescritura de la Flash (explicadas justo en el subapartado anterior).

Una vez finalizado pues el cometido de este bloque, se devolver el control al bucle de sobreescritura Flash para que termine de reescribir el resto de posiciones de memoria Flash de la pgina 127. Dicho bloque ignorar las posiciones de memoria asociadas al vector de interrupcin I2C para no incurrir en el error de volver a reescribirlas sin haber vuelto a borrar la pgina entera.

Cuando el bucle de sobreescritura reescriba las ultimas posiciones de memoria Flash, asociadas al vector de reset (0xFFFE y 0xFFFF), dar por terminado su trabajo y transferir el control al bloque de comprobaciones finales y reset, que se describe a continuacin.

[Link].4.

Comprobaciones Finales y Reset (Fin de la Actualizacin)

En el momento en que el resto de bloques funcionales desarrollados en los subapartados anteriores han terminado su trabajo, se llama a este bloque final para concluir con el proceso de actualizacin del firmware del ND07.

Llegados a este punto, todos los errores que puedan haber tenido lugar a lo largo del proceso de actualizacin han debido de ser convenientemente solucionados mediante las tcnicas que se describen en el apartado siguiente [Link].

Si el proceso de actualizacin ha considerado conveniente otorgar el control a este ltimo bloque funcional del bootloader significa que da la sustitucin del firmware por finalizada satisfactoriamente.

No obstante, una vez alcanzado el bloque de comprobaciones finales, an resta modificar el flag de regrabacin de la EEPROM para indicar que la actualizacin ha finalizado y que la prxima reinicializacin del dispositivo ha de arrancar el nuevo firmware ignorando la imagen almacenada en la memoria externa.

164

La actualizacin del valor del flag de regrabacin se realizar empleando el API desarrollado para la lectura y escritura de la EEPROM explicado en la seccin Bucle de Lectura de Registros Modificados S19 de este mismo subapartado.

As pues, este bloque se encargar de reescribir el flag de regrabacin de la EEPROM (posiciones de memoria 0x0000 y 0x0001, ver apartado 4.1.3) a un valor 0xCCCC. Obviamente esta grabacin tambin podra dar errores y es competencia del algoritmo reintentarla hasta tener xito. En caso de superar los 255 reintentos se dejara de reintentar y se confiara que el prximo rearranque del dispositivo (que obviamente proceder, al seguir el flag de regrabacin activo, a volver a actualizar la memoria Flash) arreglar el problema.

Lo ms habitual ser que de fbrica el valor de las posiciones de memoria de la EEPROM sean todo bytes a 0x00 o 0xFF. Es por ello que no resulta conveniente emplear el valor 0x0000 para indicar que la imagen almacenada ha sido empleada exitosamente para actualizar el dispositivo (pero que no se desea realizar de nuevo de momento) y se emplea en su lugar 0xCCCC.

La aplicacin encargada de almacenar firmwares en la EEPROM podr emplear el flag de regrabacin para indicar en cualquier momento el estado de una imagen en la memoria externa, como por ejemplo: en proceso de recepcin, lista para ser redistribuida, lista para actualizar el dispositivo anfitrin (con el valor 0xAABB como ya se ha comentado), obsoleta, con errores, etc. La decisin acerca del significado de cada valor (a excepcin de los valores reservados 0xAABB, 0xCCCC, 0xFFFF y 0x0000) queda en manos del futuro desarrollador de la aplicacin encargada de almacenar las imgenes en EEPROM.

Una vez el flag de regrabacin se ha desactivado exitosamente para no volver a activar el bootloader en el prximo arranque del dispositivo, se proceder a resetear el ND07 para que comience a ejecutar el nuevo firmware.

Para lograrlo, se ejecutar una instruccin fuera del rango permitido del MC13213, que provocar la interrupcin inmediata del flujo del programa y reiniciar el dispositivo de igual forma que si hubiese perdido la alimentacin. A continuacin, se ejecutar el nuevo cargador de arranque que pasar por el bootloader para comprobar que no existe otra imagen disponible en EEPROM para actualizar el firmware. Despus se otorgar el control al resto de la aplicacin actualizada.

Llegados a este punto se considera finalizada la descripcin modular del funcionamiento del bootloader desarrollado, objetivo final de este proyecto.

165

[Link].

Validacin de la Actualizacin del Firmware

La mayor parte de las incidencias que se pueden dar durante la ejecucin del algoritmo de actualizacin se pueden separar fcilmente en errores de grabacin/borrado de posiciones de memoria Flash o en errores de lectura/escritura de la EEPROM a travs de la comunicacin I2C.

Desafortunadamente, en ambos casos la estrategia empleada para solucionar el error se basa en el reintento de la operacin hasta que funcione o se descarte (tras reintentar un mximo de 255 veces) dando por hecho que la propia notificacin de error no es fiable. Esto es as porque, como ya se explic en el apartado 4.1.1, el objetivo de este proyecto es nicamente el desarrollo del bootloader encargado de la actualizacin del firmware, de modo que ste no puede contar con la disponibilidad de un cargador de arranque completo protegido que permanezca inmutable y que permita descartar la actualizacin en caso de darse un problema irrecuperable a mitad del proceso.

Es necesario recordar que existe un lmite mximo en el nmero de ciclos de escritura sobre la memoria Flash y sobre la EEPROM, de modo que reintentar una operacin demasiadas veces daara el dispositivo permanentemente.

La notificacin hacia el exterior de la aparicin de un error en el proceso de actualizacin es de poca o nula utilidad ya que si el ste se deja a medias para tratar de informar al usuario, probablemente el dispositivo no vuelva a funcionar correctamente nunca ms. Es por ello que la poltica de actualizacin empleada para dispositivos de poca memoria y capacidad de procesamiento como el ND07 consiste bsicamente en reintentar las operaciones que dan errores y no notificar nada al exterior. Adems, en caso de la aparicin de un error de grabacin (irrecuperable) el usuario poco podra hacer para arreglarlo ms all de sustituir el dispositivo por otro.

As pues, el cdigo del bootloader comprueba el resultado de la mayor parte de operaciones que va realizando (en ocasiones, para simplificar el cdigo, se realizan comprobaciones de algoritmos completos) y cuando stas no finalizan exitosamente se reintentan tras reinicializar el estado de los registros de estado.

El caso ms desafortunado es un fallo en la escritura de una posicin de memoria Flash. Cuando esto sucede es imprescindible volver a borrar la pgina y repetir la actualizacin de esta de cero, lo cual implica volver a leer registros S19 modificados ya procesados, con el coste computacional que supone. Una vez ms, cada pgina se reintenta un mximo de 255 veces, tras lo cual se pasa a la siguiente confiando en el xito de la operacin.

166

La aparicin constante de errores de grabacin de posiciones Flash indicar claramente un defecto en la memoria de la plataforma MC13213 o un problema en la alimentacin del dispositivo (el ND07 no dispone de batera de backup). Situaciones ambas de difcil solucin: sustituir el ND07 o el adaptador de corriente por otro nuevo, respectivamente.

Adicionalmente, fluctuaciones de la tensin de alimentacin pueden causar tambin errores en el proceso de grabacin que sean indetectables por el controlador Flash, de forma que el bootloader podra llegar a dar por buena una actualizacin no exitosa. Sin embargo, la solucin de contingencia para este problema pasa por comparar byte a byte la memoria Flash con la imagen almacenada en EEPROM o implementar algn tipo de checksum global.

Desafortunadamente ambos procesos pueden acarrear nuevos errores y complicaran demasiado el cdigo sin tener a cambio la garanta de corregir el error (pudiendo intercambiarlo por otro). Es necesario elegir un punto de equilibrio entre complejidad (mayor lentitud) y seguridad del bootloader, y es por ello que estas soluciones de contingencia no se han implementado.

Para finalizar, ya se ha comentado que la validacin de la actualizacin de firmware se realizar a lo largo de la ejecucin del bootloader en cada operacin que se realice, de forma que el algoritmo es bastante seguro. No obstante, una prctica recomendable para reducir al mximo las posibilidades de aparicin de errores ser exigir a la aplicacin que ejecuta el bootloader que realice todas las comprobaciones de integridad posibles a la imagen depositada en EEPROM y que no permita el inicio de actualizaciones si se detectan fluctuaciones en la alimentacin.

Todas estas recomendaciones se recogen en el apartado de requisitos para la aplicacin del apndice A.2.

[Link].

Opciones del Compilador y del Enlazador (Linker).

El IDE CodeWarrior for MicroControllers v5.1 incluye en su paquete un compilador, un ensamblador y un enlazador (Linker) capaces de generar cdigo mquina para chips como el MC13123. Adicionalmente provee de un depurador que permiti en su momento limpiar el cdigo programado, detectar errores y validar su correcto funcionamiento.

Tanto el compilador como el enlazador son configurables mediante parmetros de entrada, lo cual les convierte en herramientas muy flexibles y potentes a la hora de controlar el modo en que se generar el cdigo desarrollado y se dispondr en las memorias RAM y Flash del chip.

167

Independientemente de las optimizaciones de compilacin seleccionadas, el compilador tratar siempre de optimizar la velocidad y tamao del cdigo generado, creando dependencias entre las funciones programadas y otras partes del cdigo o sus propias libreras internas para as tratar de eliminar las redundancias encontradas al mximo.

Desafortunadamente, esta potencia de optimizacin del cdigo por parte del compilador puede llegar a ser un problema para el desarrollo de una aplicacin como el bootloader, cuyo requisito principal es que resida en una seccin concreta de la memoria (tanto Flash como RAM) y no dependa en ningn momento de cdigo o memoria alojada fuera de su propio mbito. Esto se debe a que el proceso de actualizacin reescribir toda la memoria del chip a excepcin de aquella ocupada por el bootloader y, si ste dependiese de funciones alojadas fuera de su mbito, dejara de funcionar a mitad del proceso dejando al dispositivo en un estado irrecuperable.

Como ya se explicar ms adelante, no existe opcin seleccionable de compilacin que fuerce al compilador a no optimizar una seccin del cdigo (como sera el caso del bootloader) de forma que siempre sea independiente del resto de la aplicacin. Habitualmente sucede que a una aplicacin cuyo bootloader es independiente del resto del cdigo se le modifica alguna rutina de la comunicacin ZigBee y el nuevo cdigo generado convierte al bootloader en dependiente de la aplicacin principal.

Sin embargo, la eleccin de una serie de optimizaciones del compilador frente a otras s que puede provocar que en la mayora de las aplicaciones compiladas el bootloader permanezca independiente al resto del cdigo e inalterado, aunque sin garantizar nunca el 100% de los casos (dato que confirm ms tarde el servicio tcnico de Freescale, ver apartado 4.1.5).

Es por todo esto que el estudio de las opciones del compilador y del enlazador ha sido fundamental para alcanzar el objetivo final de este proyecto (la obtencin de un bootloader independiente del resto de cdigo de aplicacin) y se describen resumidamente a continuacin.

[Link].1.

Opciones del Compilador

Las opciones del compilador suministrado por Freescale dentro del IDE CodeWarrior for Microcontrollers V5.1 se encuentran accesibles para su configuracin siguiendo la ruta: Edit -> Application Settings->Compiler for HC08 y pulsando el botn etiquetado como Options.

Tras pulsar dicho botn (aunque las opciones pueden configurarse a mano en la entrada de texto etiquetada como Command Line Options de la pantalla que lo contiene), aparece el siguiente men compuesto de pestaas y checkboxes:

168

Captura de pantalla del men de opciones del compilador

Como puede apreciarse en la imagen anterior, las diversas optimizaciones aplicables por el compilador son accesibles de forma muy intuitiva y documentada (aunque sus efectos son en ocasiones ms difciles de apreciar) y las ms importantes pueden resumirse en el siguiente listado junto con una breve descripcin de su funcionamiento en ingls:

Listado de opciones de compilacin disponibles [45]

169

Dependiendo del cdigo fuente a compilar, cada optimizacin del compilador presenta una serie de ventajas y de desventajas. A pesar de ello, Freescale recomienda emplear siempre las siguientes opciones [45]: Alojar objetos constantes en ROM (opcin Cc) especificando su localizacin mediante la seccin ROM_VAR en el fichero de parmetros del enlazador (linker). Notificar error cuando se encuentren declaraciones de parmetros implcitos (opcin -Wpd), ayudando a detectar fallos de programacin. Realizar optimizacin de registros (opcin Or) siempre que sea posible. Compilar las funciones de cada mdulo con las opciones ms adecuadas para l. Para ello se definirn dinmicamente mediante la opcin OdocF (Dynamic Option Configuration for Functions).

Las opciones por defecto del CodeWarrior activan la mayor parte de las optimizaciones del compilador. Esto puede provocar que, en ocasiones, el cdigo resultante sea difcil de depurar, ocupe ms de lo debido (cuando el objetivo a optimizar no sea el tamao del cdigo pero s la velocidad) o incluso no funcione bien. Ser funcin del programador estudiar pues cuales son las optimizaciones ms adecuadas para la aplicacin que desarrolla.

As pues, a lo largo del desarrollo del bootloader se ha comprobado imprescindible omitir la opcin Os (es decir, forzar la optimizacin del tamao del cdigo frente a la velocidad), de lo contrario el cdigo resultante siempre era dependiente de la aplicacin principal. Por otro lado, el empleo de la opcin Ot (opcin opuesta, en la que el compilador optimiza la velocidad del cdigo) no genera dependencias del bootloader a priori pero aumenta considerablemente el tamao del cdigo resultante (factor que tampoco interesa). De forma que se descartaron ambas.

Las opciones de compilacin finalmente empleadas para el Cargador RS232 con bootloader que no generaban dependencias fueron las siguientes: -Cc Cni Cq Cs08 CswMaxLF0 CswMinLF0 CswMinSLB9999 DgBeeStackIncluded_d=1 -DINCLUDE_802_15_4 DgCoordinatorCapability_d=1 Dtype_FFDPZSNBNVNS -DgTargetMC13213ND07_d=1 DgMeshNetworkingCapability_d=1 DgZtcIncluded_d=0 -Lasm=%[Link] Lasmc=h Ms Ou Obfv OdocF=-Onca|-One|-Or|-Ont OnB TE1uE -WmsgNu=acdet Wpd

[Link].2.

Pragmas

Un pragma es una directiva del compilador que define cmo se pasar la informacin desde el interfaz del programador hacia la parte encargada de procesar el cdigo, sin afectar al analizador sintctico (parser).

170

Los pragmas aceptados por el compilador suministrado por Freescale para la plataforma MC13213 se enumeran a continuacin:

Listado de PRAGMAS del compilador [45] A efectos del desarrollo del bootloader, los pragmas CODE_SEG, CONST_SEG, DATA_SEG, han sido fundamentales para tener control preciso sobre las secciones concretas de memoria (tanto ROM como RAM) que requerir la aplicacin para su correcto funcionamiento.

Adicionalmente se ha empleado profusamente el pragma MESSAGE (para controlar las alarmas generadas en tiempo de compilacin) y puntualmente el pragma OPTION (para especificar un tratamiento especial de una seccin concreta del cdigo por parte del compilador).

[Link].3.

Opciones del Enlazador y Fichero de Parmetros(PRM)

Un enlazador (linker) es un programa que toma los ficheros de cdigo objeto generados en los primeros pasos del proceso de compilacin, la informacin de todos los recursos necesarios (libreras), quita aquellos recursos que no necesita, y enlaza el cdigo objeto con su(s) librera(s) con lo que finalmente produce un fichero ejecutable o una librera.

Aunque el enlazador permite configurar distintas opciones (desde lnea de comandos) de enlazado de los ficheros objeto generados en la compilacin, se suele optar por aquellas que Freescale suministra por defecto para proyectos diseados para la plataforma MC13213. Estas opciones sern las siguientes:

-B M WmsgSd1100 WmsgSd1912 EnvSRECORD=s19 WstdoutOn

171

Se ha comprobado que la eleccin de las opciones de enlazado por defecto dan lugar a compilaciones de aplicaciones independientes del bootloader siempre y cuando se hayan elegido correctamente las optimizaciones de compilacin.

No obstante, debido a su importancia en el desarrollo exitoso de este proyecto, cabe destacar las siguientes opciones de enlazado: -B: opcin que activa la generacin de un fichero .S19 junto con el cdigo compilado (no slo cdigo mquina). Esto permitir a las aplicaciones enviar imgenes de firmware con un formato cmodo a travs del puerto serie o de forma inalmbrica. -M: opcin que permite generar mapas de memoria del cdigo compilado, enlazado y ensamblado. Gracias a estos mapas se ha podido evaluar cuando una compilacin concreta generaba dependencias entre la aplicacin principal y el bootloader y detectar en qu partes concretas del cdigo suceda.

Sin embargo, la parte ms importante del enlazador a efectos del bootloader es su fichero de parmetros.

El fichero de parmetros, de extensin .prm y sito en la carpeta homnima de cada proyecto del CodeWarrior for MicroControllers v5.1, permite al desarrollador etiquetar secciones distintas de la memoria Flash y RAM para luego emplazar cada bloque del cdigo de aplicacin (y lo ms importante, del bootloader) en la seccin que se desee.

El formato del fichero de parmetros .prm es un fichero de texto en el que se distinguen principalmente los siguientes bloques: [46] bloque SECTIONS: en el que se separa la memoria en varias secciones, especificando el tipo de datos que van a alojar (de slo lectura, lectura y escritura, etc.) y otorgndoles una etiqueta. bloque PLACEMENT: en el que se asigna a cada segmento de la memoria (definidos a lo largo del cdigo mediante los pragmas CODE_SEG, CONST_SEG o DATA_SEG y un identificador especfico) a una seccin de la memoria de las anteriormente definidas. Bloque VECTOR 0: vector que apunta a la primera funcin que se ejecutar al resetear el dispositivo.

Aunque se podran mencionar ms tipos de bloques y explicar extensamente las secciones de memoria predefinidas existentes, no son directamente relevantes en cuanto al bootloader se refiere. No obstante, un desarrollador de una aplicacin ZigBee estndar s que deber estudiar este fichero con detenimiento para asegurarse de que todo su cdigo se emplaza donde tiene planeado.

172

El bootloader, como se explicar mas adelante, deber reservar una seccin de memoria Flash y RAM para su uso particular que no podr ser empleada para ninguna otra aplicacin, o de lo contrario no se podr asegurar su correcto funcionamiento el 100% de las veces.

Para ello ser necesario pues incluir en el fichero de parmetros del enlazador, en todas las aplicaciones que incluyan el bootloader desarrollado en este proyecto, las siguientes secciones (dentro del bloque SECTIONS):
//RAM voltil reservada por el Bootloader BOOTLOADER_RAM_SECTION = READ_WRITE 0x0260 TO 0x02A4;

//Vector de interrupcin I2C para aplicacin (siempre justo antes del bootloader) I2C_VECTOR_SECTION = READ_ONLY 0xF7FE TO 0xF7FF;

//Secciones BOOTLOADER NLAZA_BOOT NLAZA_CODE = READ_ONLY 0xF800 TO 0xF85F; //0xFDFF; = READ_ONLY 0xF860 TO 0xFDFF; //0xFDFF;

Y las siguientes asignaciones de memoria (dentro del bloque PLACEMENT):

//BOOTLOADER NLAZA_BOOTLOADER NLAZA_BOOTCODE BOOTLOADER_RAM INTO NLAZA_BOOT; INTO NLAZA_CODE; INTO BOOTLOADER_RAM_SECTION;

//Cdigo Interrupcin I2C para aplicacin I2C_APP_VECTOR INTO I2C_VECTOR_SECTION;

De este modo, cuando un programador de dispositivos ZigBee ND07 necesite incluir el bootloader en su cdigo, deber incluir estas lneas adicionales en el fichero de parmetros (y modificar el resto en consecuencia para no solapar secciones) a la vez que incluye los ficheros del bootloader en el proyecto de su aplicacin.

[Link].

Programar Cdigo en Ensamblador

Como se deduce de los apartados anteriores, el principal problema que plante el bootloader, una vez diseado y programado, fue que dependiendo de las opciones de compilacin elegidas (y en ocasiones sin importar que optimizaciones se aplicasen) el cdigo de ste se haca dependiente de otras secciones de la memoria, externas a su rango asignado.

Seleccionar unas opciones de compilacin frente a otras eliminaba en ocasiones las dependencias generadas pero obviamente alteraba el modo en que se ensamblaba el bootloader, modificando el tamao del cdigo resultante.

173

Puesto que el bootloader reserva 3 pginas de memoria para almacenar su cdigo de aplicacin y habitualmente (en la mayora de las compilaciones) la ltima se queda casi vaca, ligeras modificaciones del tamao no tienen un efecto negativo significativo (siempre y cuando no se altere su funcionamiento).

No sucede as con las dependencias. En el momento que el bootloader se convierte en dependiente de otra seccin del cdigo ya no se puede asegurar su correcto funcionamiento. Afortunadamente el enlazador (linker) permite generar mapas de memoria del cdigo compilado (ver apartado anterior) de forma que se puede detectar rpidamente cualquier dependencia, as como evaluar el tamao del cdigo resultante y comprobar si se ha almacenado en la seccin que tiene asignada en el fichero de parmetros.

Aunque podra llegar a ser una restriccin asumible en un momento dado, en un principio los esfuerzos de desarrollo del bootloader han ido siempre encaminados a hacerlo funcional de forma independiente a las optimizaciones del compilador elegidas por el programador, para evitar restar flexibilidad al diseo del resto de aplicaciones.

Finalmente, se lleg a la conclusin de que el nico mtodo que garantiza que el bootloader se compilar de forma independiente al resto de la aplicacin principal entre las sucesivas versiones de sta, consiste en desarrollarlo ntegramente en ensamblador y luego grabarlo en la posicin deseada de memoria Flash (cuando se programe el ND07 por primera vez para sacarlo al mercado). Adicionalmente este mtodo asegurara un tamao y posicin en memoria del bootloader fijas sea cual sea la aplicacin principal que lo contenga.

Esta conclusin fue confirmada tiempo ms tarde por el servicio tcnico de Freescale (ver apartado 4.1.5) tras realizar muchas consultas.

Desafortunadamente,

programar

el

bootloader

ntegramente

en

ensamblador

es

extremadamente costoso a efectos de tiempo y trabajo, de forma que la primera aproximacin fue la de traducir a ensamblador slo aquellas funciones del bootloader ms propensas a ser optimizadas por el compilador generando dependencias con cdigo externo al bootloader.

Una vez ms, esta solucin no resolva el problema en la totalidad de las situaciones (por no hablar del hecho de que en muchos casos el compilador no trataba correctamente funciones con muchos parmetros de entrada cuando estaban ntegramente escritas en ensamblador) de forma que no qued ms remedio que traducir toda la aplicacin a ensamblador y cdigo mquina.

Para facilitar el trabajo en la medida de lo posible y minimizar el tiempo de desarrollo, el proceso de traduccin se realiz en las siguientes fases:

174

Fase I: Finalizacin del cdigo definitivo (en C con secciones puntuales en ensamblador). Finalizacin del cdigo definitivo del cargador RS232. Depuracin de cdigos hasta obtener la versin definitiva y comprobacin de su funcionamiento.

Fase II: Evaluacin de las opciones de compilacin hasta obtener una combinacin que no generaba dependencias entre el cdigo del bootloader y el de la aplicacin principal (en este caso el cargador RS232). Reserva de secciones de memoria RAM y Flash para el bootloader mediante el fichero de parmetros del enlazador y el empleo de pragmas (ver apartado [Link]). Comprobacin de correcto funcionamiento.

Fase III: Apoyndose en los ficheros de listado generados en la compilacin (mediante determinadas opciones del compilador) y en el depurador del CodeWarrior, se pudo recuperar una versin en ensamblador ms o menos precisa de la ltima versin sin dependencias del bootloader sin necesidad de programarla de cero. A partir de esta primera versin en ensamblador se desarroll la versin final con una pequea seccin en cdigo C (encargada de asegurarse de que el CodeWarrior reservara siempre la memoria necesaria en RAM y ROM para el bootloader), una pequea seccin en ensamblador (encargada de inicializar el mdulo I2C) y el resto de la aplicacin en cdigo mquina (que resultar inalterable sea cual sea la optimizacin del compilador elegida).

De este modo, al apoyarse en los ficheros de listados en ensamblador generados por el compilador, el proceso de migracin del cdigo en lenguaje C a cdigo mquina y ensamblador se realiz de forma ptima y controlada, empleando una cantidad de tiempo mucho menor de lo que habra implicado programarlo de cero y obteniendo un resultado mucho ms robusto.

A partir de este punto, todas las aplicaciones que incluyan el bootloader obtenido (traducido a cdigo mquina a partir de una compilacin en la que no se haban generado dependencias con la aplicacin principal), podrn ser compiladas con cualquier conjunto de optimizaciones sin que se generen dependencias entre ambos puesto que ste ya se presenta compilado en cdigo mquina y ensamblador como una ristra de bytes (no optimizable en modo alguno).

[Link].

Localizacin Inteligente del Bootloader

Debido al hecho de que la versin definitiva del bootloader desarrollado a lo largo de este proyecto ha de suministrarse en ensamblador y cdigo mquina (para evitar dependencias con el resto del cdigo, como ya se ha comentado con anterioridad), la mayor parte de los parmetros que rigen su funcionamiento han de ser fijados con anterioridad a dicha traduccin.

175

A continuacin se desarrollan pues las decisiones de diseo tomadas referentes a la reserva de memoria y emplazamiento dentro de la secuencia de arranque del dispositivo. stas se convertirn en parte de los requisitos de instalacin del bootloader dentro de una aplicacin ZigBee.

[Link].1.

Emplazamiento en la Memoria (RAM y Flash)

La eleccin y reserva de las posiciones de memoria Flash del MC13213 que ocuparn las tres pginas del bootloader es fundamental para el ptimo aprovechamiento de sta y para evitar posibles problemas derivados de su solapamiento con secciones del cdigo de la aplicacin principal. Puesto que el cdigo relativo al bootloader no se sobrescribir nunca, ocupar un nmero entero de pginas Flash que jams debern contener nada del resto de cdigo de aplicacin ni del espacio reservado para registros no voltiles o para vectores de interrupcin del MC13213. De lo contrario, estos mdulos (o secciones de cdigo) no se sobrescribiran entre actualizaciones pudiendo corromper la aplicacin final.

Si se analiza el modelo de memoria del MC13213 (ver apartado [Link]), se deduce que las tres pginas del bootloader (1535 bytes) podran emplazarse o en el bloque de direcciones [0x1080 0x1800] o en el bloque [0x192C 0xFDFF]. La ltima pgina, cuyo rango de

direcciones es [0xFE00

0xFFFF], no puede emplearse para este fin ya que contiene los

vectores de interrupcin, de reset y los registros no voltiles del MC13213.

Sin embargo, puesto que por defecto el puntero de inicio de programa apunta siempre a la primera posicin de Flash (0x1080) como emplazamiento del cdigo de inicio del dispositivo (de tamao no despreciable), las pginas asociadas al bloque de direcciones

[0x1080 0x1800] no parecen ser las ms adecuadas para la instalacin del bootloader.

Adicionalmente, el mdulo NVM suele reservar 3 pginas de memoria Flash para el almacenamiento de variables no voltiles que por defecto cubren el rango de direcciones [0x1A00 0x1FFF]. Puesto que el nmero de pginas empleadas por el mdulo NVM puede ser mayor que 3 (aunque en esas situaciones, de suceder una actualizacin se sobrescribira el valor de stas), no resulta conveniente emplazar el bootloader inmediatamente despus de las pginas reservadas para la NVM.

De este modo, se ha decidido emplazar el cdigo del bootloader en las pginas 124, 125 y 126 (rango de direcciones [0xF800 0xFDFF]) al final de la memoria Flash del dispositivo (evitando la ltima pgina, para que cualquier actualizacin de firmware pueda modificar el valor de un registro no voltil o de un vector de interrupcin). Esta decisin de diseo deja al compilador,

176

ensamblador y enlazador (linker) con la mayor cantidad de memoria Flash libre contigua dentro del bloque [0x192C 0xFFFF] posible y se protege ante las configuraciones atpicas que un

desarrollador de aplicaciones podra decidir programar en una aplicacin concreta.

En cuanto a consumo de RAM se refiere, el bootloader desarrollado necesita reservar una serie de variables y cdigo de aplicacin en memoria voltil que ocuparn 69 bytes de RAM de forma permanente.

Una vez ms, se decide reservar la seccin de memoria RAM con menor riesgo de colisin con otros mdulos del microcontrolador. Con este fin, el bootloader reservar los primeros 69 bytes de la memoria RAM designada como libre despus del stack. As pues, cuando se desee instalar el bootloader, ser necesario reservar el rango de direcciones [0x0260 su uso exclusivo. 0x02A4] para

Como ya se ha explicado en el apartado [Link], el fichero de parmetros del enlazador (.prm) (presente en todo proyecto de CodeWarrior) permitir al programador de aplicaciones reservar los rangos de memoria RAM y Flash especificados anteriormente para la correcta instalacin del bootloader. Los pasos concretos a dar se enumerarn en el apndice de instrucciones de instalacin, en el apartado A.1.1.

[Link].2.

Emplazamiento en la Secuencia de Arranque

La eleccin del emplazamiento del bootloader dentro de la secuencia de arranque del dispositivo es un proceso delicado ya que de l dependen muchos factores.

Principalmente cabe destacar los siguientes:

La posicin concreta del bootloader dentro de la secuencia de arranque determinar la frecuencia del reloj del bus interno que se emplear para la actualizacin del firmware (en el caso de requerirse una actualizacin), del que depende directamente el valor almacenado en el registro FCDIV para configurar correctamente la velocidad del reloj del mdulo Flash entre 150 y 200 KHz. Este registro slo puede escribirse en una ocasin por cada reseteo del dispositivo.

Cuanto ms prximo al inicio del proceso de arranque del dispositivo se posicione el bootloader, el reloj empleado ser de menor frecuencia y menor precisin (al utilizar una fuente interna del MC13213). Esto podra tener una repercusin negativa en los procedimientos de escritura de la Flash y la EEPROM.

177

Si se analizan los pasos de la secuencia de arranque de la figura del apartado 4.1.2, se comprueba que cualquier localizacin del bootloader dentro de sta podra ser vlido una vez efectuado el paso 5, momento en que ya se ha inicializado la memoria RAM y el reloj interno del microcontrolador.

Por otro lado, en el afn de hacer al bootloader lo ms independiente posible del cdigo de aplicacin (de forma que no sea nunca interrumpido por la aplicacin principal cuando se est ejecutando una actualizacin), tampoco conviene emplazarlo en una posicin de la secuencia de arranque posterior al paso 9 (inclusive). Esto se debe a que la inicializacin del gestor de tareas que tiene lugar en el paso 10 podra afectar a la continuidad de la ejecucin de una actualizacin o a que una tarea no se ejecute debidamente por inanicin (si el bootloader acapara los recursos demasiado tiempo).

As pues, el rango de pasos que comprende la secuencia de arranque del dispositivo que pueden ser aptos para el emplazamiento del bootloader se muestran en el siguiente diagrama:

Pasos de la secuencia de Arranque:

Inicializacin de la RAM: 1.- Poner a cero el espacio disponible. 2.- Inicializar variables locales. 3.- Copiar a RAM desde ROM el valor inicial de todas las variables globales. Inicializacin de la plataforma: Configuracin de puertos GPIO Inicializacin de la plataforma: 1.- Configuracin del interfaz SPI para comunicarse con el mdem. 2.- Inicializacin Transceptor Radio. Configuracin Reloj del Sistema: 1.- Configuracin reloj del mdem. 2.- Generacin de reloj de sistema a partir del reloj del mdem. Inicializacin de las capas fsica y MAC de la librera 802.15.4

9 10

Inicializacin gestor de Tareas

Localizaciones posibles del bootloader dentro de la secuencia de arranque

De este modo, a continuacin se analizarn los pros y contras de cada una de las 5 localizaciones posibles para el bootloader en la secuencia de arranque del dispositivo:

178

1. Despus del paso 5: tras la inicializacin de la memoria RAM empleado la fuente de reloj interna del microcontrolador como referencia. La principal ventaja de esta localizacin es que es la ms independiente del cdigo de la aplicacin final. El principal inconveniente es que el reloj empleado es ms lento e impreciso. 2. Despus del paso 6: tras la inicializacin de los puertos GPIO. Puesto que dichos puertos no afectan al bootloader (a menos que sean inconvenientemente configurados y se activen interrupciones indebidas), esta localizacin no presenta ninguna ventaja a la anterior (y podra plantear nuevos inconvenientes). 3. Despus del paso 7: Tras la configuracin del interfaz SPI y la inicializacin del transceptor radio. Este paso activar la comunicacin del microcontrolador con el mdem que permitir realizar emisiones y recepciones radio y emplear adicionalmente su seal de salida como nueva referencia de reloj (ms rpida y estable). Sin embargo, justo despus de este paso an no se ha configurado el nuevo reloj del bus mientras que las interrupciones SPI ya podran afectar al funcionamiento del bootloader. De nuevo esta localizacin no plantea ninguna ventaja nueva (y s posibles inconvenientes) a la primera localizacin planteada. 4. Despus del paso 8: tras la configuracin de un nuevo reloj de bus a partir de la seal de referencia del modem radio (ms rpida y estable). Las ventajas de esta localizacin son claras: mayor velocidad del bootloader y mayor precisin. Los inconvenientes: dependencia del bootloader de la frecuencia de bus elegida por el programador de la aplicacin principal (una vez programado el bootloader sta ya nunca podra modificarse) y la coexistencia con un mayor nmero de interrupciones y mdulos activos que podran alterar su correcto funcionamiento. 5. Despus del paso 9: tras la inicializacin de las capas fsica (PHY) y de acceso al medio (MAC) de la librera 802.15.4 suministrada. Puesto que el bootloader es independiente de ellas, su inicializacin no plantea ninguna ventaja respecto a la localizacin anterior mientras que podra plantear algn inconveniente no considerado.

As pues, de todos los posibles emplazamientos del bootloader dentro de la secuencia de arranque slo dos parecen adecuados:

1. Justo despus de la inicializacin de la RAM (tras el paso 5 de la secuencia de arranque). Presenta la mayor independencia posible del bootloader con la aplicacin final y las mnimas interferencias posibles de otros mdulos del microcontrolador. 2. Justo despus de la sincronizacin del microcontrolador con el mdem radio y el establecimiento de la seal de reloj a partir de ste. Esta localizacin presenta la mayor velocidad de bus y el reloj ms preciso que se emplearn en el microcontrolador.

179

Aunque ambas posibilidades son correctas, se ha decidido finalmente emplazar el bootloader dentro de la secuencia de arranque justo despus de la inicializacin de la memoria RAM (opcin 1) por las siguientes razones:

1. El reloj interno empleado por defecto, a una frecuencia de 8 MHz de bus, es slo la mitad de la que habitualmente se genera luego a partir de la seal de sincronizacin del mdem radio (16 MHz). 2. Dicha diferencia de velocidades no afecta a la velocidad de borrado y grabacin de memoria Flash que nunca ser ms rpida que 200 KHz. Esto es especialmente significativo puesto que el proceso de sobrescritura Flash es con diferencia el procedimiento ms lento del bootloader. De esta forma, la velocidad del bus a efectos del bootloader slo se apreciar a la hora de realizar lecturas y/o escrituras I2C sobre la memoria auxiliar externa, la EEPROM, y no ser significativa. 3. El empleo de una seal de reloj poco precisa no debera perturbar significativamente un protocolo de comunicaciones robusto como es el I2C, diseado para soportar caractersticas como el estrechamiento de reloj. Simultneamente, puesto que la seal de reloj del mdulo Flash generada a partir del reloj de bus tiene una frecuencia 40 veces menor (200KHz mximo), la falta de precisin debera reducirse significativamente, dejando de ser un problema en la mayora de los casos. 4. El bootloader ha sido programado para reintentar muchas veces cada operacin que no se ejecute correctamente, de forma que est preparado para afrontar cualquier problema derivado de la falta de precisin. 5. Se ha comprobado el ptimo funcionamiento del bootloader en este emplazamiento y la sencillez de realizar dicha instalacin dentro de la secuencia de arranque (pasos enumerados ms adelante dentro de las especificaciones del bootloader, apndice A.1.1). 6. El posicionamiento del bootloader cuanto ms prximo al principio de la secuencia de arranque del dispositivo facilita su funcionamiento independiente con respecto a la aplicacin principal, sus mdulos en memoria y sus interrupciones asociadas. De este modo, cualquier programador podr desarrollar fcilmente aplicaciones complejas ZigBee de forma transparente al bootloader.

Por todo esto se concluye como opcin idnea el emplazamiento del bootloader dentro de la secuencia de arranque del ND07 justo despus de la inicializacin de la memoria RAM, como se muestra en el siguiente diagrama:

180

Pasos de la secuencia de Arranque:

Inicializacin de la RAM: 1.- Poner a cero el espacio disponible. 2.- Inicializar variables locales. 3.- Copiar a RAM desde ROM el valor inicial de todas las variables globales. BOOTLOADER

6 7

Inicializacin de la plataforma: Configuracin de puertos GPIO

Etc.
Emplazamiento definitivo del bootloader en la secuencia de arranque Los pasos necesarios a dar por el desarrollador de aplicaciones ZigBee para emplazar el bootloader en la localizacin elegida dentro de la secuencia de arranque del ND07 son muy sencillos, y se enumeran en el apndice A.1.1 de esta memoria.

4.1.5. Servicio Tcnico de Freescale

El servicio tcnico de Freescale consiste bsicamente en un portal que mantiene un foro de dudas y un sistema de formularios donde los desarrolladores plantean incidencias directamente a la compaa.

Aunque a lo largo de los aos este servicio ha mejorado bastante, durante el periodo de desarrollo de este proyecto su funcionamiento ha sido extremadamente desastroso.

Una consulta a Freescale tardaba de media dos semanas en ser atendida y cuando esto por fin suceda por lo general la respuesta era de una simpleza elemental (bsicamente una redireccin a los manuales ms bsicos), dando clara muestra de no haber entendido la pregunta o estar muy lejos de saber la respuesta. Era necesario repetir la pregunta (dos semanas cada vez) hasta que la incidencia se escalaba por fin a un tcnico especializado capaz de responder a la consulta con informacin de alguna utilidad.

De este modo, la mayora de las consultas han llevado ms de dos meses para obtener una respuesta ms o menos orientada al tema de la pregunta y, desafortunadamente, muy a menudo ha sido para recibir la confirmacin de un error de la librera ZigBee que Freescale prometa anotar para solventar en la prxima versin de sta. Sin embargo, errores detectados como el mencionado sobre la NVM (ver apartado 3.8.3) nunca se solventaron en la pila ZigBee

181

2006 de Freescale (aunque lleg a reconocer este error al final en varias de las consultas que se le efectuaron).

Aunque

la

documentacin

que

suministra

Freescale

para

el

chip

MC13213

es

considerablemente extensa, detalles concretos del funcionamiento del cargador de arranque, la memoria, las opciones de configuracin del compilador, linkador y ensamblador del CodeWarrior son difciles o imposibles de encontrar e interpretar salvo mediante consultas en los foros (si hay mucha suerte) o mediante el servicio tcnico (extremadamente lento y en ocasiones intil).

Cuando al principio del proyecto se programaron las primeras versiones funcionales del bootloader, todo apuntaba a que se lograra emplazar siempre todo su cdigo en las pginas de memoria deseadas por el desarrollador software mediante directivas del ensamblador y opciones especiales del compilador.

Fue a lo largo del proceso de pruebas que se detect que el cdigo del bootloader slo se consegua independizar del resto de la aplicacin en determinadas ocasiones (aleatorias). Al principio se perdi mucho tiempo creyendo que se estaban empleando mal las herramientas que ofrece Freescale para el desarrollo, compilacin, linkado y ensamblado de programas.

No obstante, despus de muchos intentos de obtener informacin al respecto, el servicio tcnico confirm que no se poda garantizar mediante opciones ni directivas del compilador que el cdigo del bootloader se alojase en una seccin concreta de la memoria Flash sin ninguna dependencia de otros sectores. Esto suceda habitualmente porque estos sectores alojaban a su vez funciones de optimizacin de las operaciones realizadas en el proceso de actualizacin de firmware que el compilador asociaba al bootloader para reducir su tamao y aumentar su velocidad.

Adicionalmente el servicio tcnico confirm que para lograr el objetivo buscado de independencia de cdigo era absolutamente necesario implementar todo el bootloader directamente en ensamblador.

De este modo se puede concluir que el servicio tcnico de Freescale, si bien ha servido para tomar decisiones de diseo fundamentales para el correcto funcionamiento del bootloader, ha requerido de la inversin de mucho esfuerzo y tiempo para logar este objetivo. Todos los problemas encontrados a lo largo del desarrollo podran haber sido solventados o sorteados con un considerable menor coste en tiempo si el servicio tcnico hubiese funcionado mejor y hubiese sido menos reticente a la hora de reconocer errores de sus libreras y de su documentacin.

182

4.1.6. Actualizaciones de Libreras: Consecuencias y Estado Actual

Como consecuencia de los errores de la pila ZigBee 2006 reportados a Freescale a travs de su sistema de incidencias y de las sucesivas mejoras que se han ido aplicando a la librera, la compaa ha publicado hasta cinco versiones de su BeeStack en menos de dos aos.

Cada actualizacin ha implicado cambios tanto a las libreras 802.15.4 y ZigBee (cuyo cdigo se presenta ya compilado en su mayor parte) como a las aplicaciones de ejemplo (que han de emplear diferentes interfaces, estructuras de datos y funciones para alcanzar los mismos objetivos).

As pues, desde la primera versin de la pila ZigBee de Freescale para el MC13213, denominada BeeStack 1.0.0, hasta la ltima que se suministr a principios del 2008 (cuando Freescale dej de dar soporte ZigBee 2006 para este chip), la versin 1.0.5, se han sucedido muchos cambios en el funcionamiento del API suministrado.

Muy a nuestro pesar, el empleo habitual del servicio de incidencias de Freescale nos ha permitido informar y corroborar un nmero considerable de errores (algunos muy crticos) en las libreras suministradas. De este modo, muchas veces ha sido necesario esperar a la publicacin de una actualizacin de dichas libreras para tener un funcionamiento adecuado del sistema (con la consecuente prdida de tiempo).

No obstante, cada publicacin de una actualizacin de las libreras ha implicado un considerable trabajo adicional para comprobar que todas las funciones, estructuras y variables empleadas tanto por el bootloader como por las aplicaciones ZigBee seguan siendo compatibles. Por otro lado, no actualizar el proyecto nunca hubiese sido una opcin, ya que cada versin de las libreras poda proveer de parches a fallos que todava no haban sido detectados.

Es por ello que cada versin de las libreras 802.15.4 o ZigBee ha tenido que ser comprobada y el cdigo de la aplicacin ajustado para asegurar el funcionamiento de sta idntico (o mejor) al que ya se tena. No bastaba con sobrescribir las libreras, el interfaz suministrado para ellas era habitualmente modificado por Freescale y no se documentaba adecuadamente.

Obviamente, cada publicacin de nuevas libreras implicaba a su vez la descarga de una nueva versin de la herramienta BeeKit, capaz de generar aplicaciones ZigBee de ejemplo con las nuevas pilas.

El procedimiento ms seguro para actualizar correctamente las libreras ha consistido siempre en generar una nueva aplicacin ZigBee de ejemplo con el BeeKit (con las nuevas libreras)

183

con los mismos parmetros originales que emple la primera versin del bootloader y compararlo con el proyecto del bootloader en desarrollo.

Puesto que la aplicacin ZigBee en proceso de desarrollo con el bootloader instalado siempre haba sido modificada sustancialmente con respecto a la aplicacin de ejemplo de la que parta (en parte debido a los numerosos fallos encontrados en los cdigos y en las libreras), realizar dicha comparacin a mano era considerablemente laborioso.

As pues, ha sido necesario hacer uso de una herramienta que permitiese comparar ficheros organizados en rboles de directorios similares, resaltando las diferencias y facilitando su actualizacin. Para ello se ha empleado la aplicacin libre WinMerge.

Captura de pantalla de la herramienta WinMerge [20] Incluso mediante el empleo de la herramienta WinMerge, cada actualizacin de las libreras de un proyecto ha sido siempre un procedimiento delicado que ha requerido de la inversin de una considerable cantidad de tiempo y esfuerzo.

De este modo, a lo largo de la elaboracin de este proyecto, ha sido necesario destinar varios das de trabajo a la actualizacin de las libreras y APIs cada vez que se reciba una publicacin peridica.

A pesar de ello, Freescale nos ha anunciado su decisin de dejar de dar soporte a la librera ZigBee 2006 para esta plataforma y, desafortunadamente, la ltima versin publicada an presenta fallos graves en el funcionamiento del protocolo ZigBee (que hemos detectado y la compaa ha reconocido).

184

4.2.

Aplicacin Auxiliar: Cargador RS232

4.2.1. Introduccin y Objetivos

Como ya se ha mencionado anteriormente, el bootloader desarrollado en este proyecto se ha diseado de forma que pueda funcionar de forma independiente al modo en que la aplicacin principal (probablemente un sensor ZigBee) obtenga la imagen del nuevo firmware. Esto ser verdad siempre y cuando dicha aplicacin almacene la imagen en la EEPROM con el formato estipulado y cumpla todos los prerrequisitos especificados en este documento (ver apartado A.1.2).

As pues, a la hora de implementar una aplicacin capaz de recibir y almacenar imgenes, de las mltiples posibles, se opt por aquella que facilitase al mximo la depuracin del bootloader (durante su fase de desarrollo) y que adems requiriese de un esfuerzo moderado (ya que su fin principal sera la evaluacin del proyecto).

De este modo, se decidi desarrollar una aplicacin (de ahora en adelante la denominaremos Cargador RS232) capaz de recibir y almacenar una imagen transmitida a travs del puerto serie de un ordenador mediante el protocolo RS232 (ver apartado 3.10).

Esta eleccin se debi principalmente a las siguientes razones:

El dispositivo de NLaza Soluciones ND07 permite una comunicacin bidireccional completa conforme al protocolo RS232 de forma sencilla a travs de su conector DE-9. Freescale suministra aplicaciones ZigBee de ejemplo con soporte de comunicaciones serie para el chip MC13213 integrado en el ND07. De este modo desarrollar una aplicacin que acte de pasarela ZigBee-RS232 es relativamente sencillo.

Para que un dispositivo ZigBee reciba inalmbricamente una imagen de firmware tiene que existir previamente un dispositivo distribuidor de imgenes que las obtenga de forma cableada (mediante una comunicacin serie, Ethernet, etc.). As que el desarrollo de esta aplicacin es imprescindible para toda demostracin del bootloader.

Todo el cdigo de la aplicacin sera reaprovechable en las ocasiones en que el dispositivo distribuidor de imgenes fuese un ND07 (en caso de querer desarrollar una aplicacin comercial ms robusta capaz de hacer transparente al usuario toda la comunicacin).

Dada la sencillez de la solucin se podra depurar eficazmente el bootloader (objetivo ltimo de este proyecto) con una considerable seguridad de que cualquier irregularidad encontrada durante el proceso vendra por parte del cdigo del bootloader, maximizando la velocidad a la hora de encontrar y eliminar errores.

185

Una vez finalizada la depuracin del bootloader, esta sencilla aplicacin servir a la vez como demostracin de su correcto funcionamiento.

Por tanto, el objetivo perseguido fue disear un cargador serie sencillo, intuitivo y de cdigo reutilizable (aplicacin escalable), que permita depurar el bootloader y finalmente demostrar su correcto funcionamiento.

4.2.2. Descripcin de la Aplicacin y Esquema de Funcionamiento

El cargador de imgenes RS232 es una aplicacin ZigBee 2006 genrica de interfaz combinado (tipo de dispositivo Combined Interface (Id. 0x0007) segn el perfil de automatizacin del hogar, Home Automation Profile) que dispone adicionalmente de la capacidad de recibir y almacenar imgenes de firmware transmitidas desde el puerto serie de un ordenador.

Adems, el cargador de imgenes RS232 se ha programado como coordinador de red ZigBee (aunque esta caracterstica podra modificarse en el futuro de forma muy sencilla) capaz pues de crear y gestionar una red mallada ZigBee. Esto se ha diseado as para hacer al dispositivo independiente de otros dispositivos ZigBee (a excepcin de otros coordinadores en el mismo canal) a la hora de crear una red y de enviar tramas broadcast sobre sta (propiedad de la que se har uso para validar el funcionamiento del bootloader)

De este modo, la aplicacin desarrollada ser capaz de: Arrancar y ejecutar (slo ante un flag de regrabacin activo) el bootloader. Crear una red ZigBee, aceptar solicitudes de asociacin y proceder a enviar tramas broadcast sobre ella peridicamente. Enviar peridicamente tramas de informacin (o texto genrico) por el puerto serie para indicar el progreso de carga de una imagen (cuando proceda). Recibir una imagen de firmware transmitida a travs de una conexin serie RS232. Procesar los registros S19 de la imagen, comprobar su integridad, traducirlos a registros S19 modificados y almacenarlos en la EEPROM auxiliar. Descartar los registros referidos a secciones de memoria no reescribibles (como son las pginas de la NVM o del propio bootloader) para evitar la necesidad de procesar previamente las imgenes antes de enviarlas. Indicar al exterior la existencia de una imagen vlida en EEPROM que no ha sido empleada para actualizar el dispositivo mediante el encendido de un LED rojo. Permitir al usuario iniciar manualmente el proceso de actualizacin (si est el LED rojo encendido) mediante la pulsacin de un interruptor (switch) del ND07. Esto provocar

186

la activacin del flag de regrabacin del dispositivo y posterior reseteo para que el bootloader realice la actualizacin del firmware.

As pues, la mquina de estados del cargador RS232 podr esquematizarse, para facilitar la comprensin de su funcionamiento, mediante la siguiente figura:

Fase Inicial del Arranque BOOTLOADER: Actualizacin del SI firmware en Flash Desactivacin del flag de regrabado Reset

Nuevo Firmwar e Listo?

NO

Fase Final del Arranque Aplicacin ZigBee principal: Envo peridico de tramas de texto broadcast Envo peridico de tramas de texto serie Aceptacin de imgenes de firmware por el puerto serie (RS232)

NO

Recepcin de datos va RS232?

SI

Pulsacin del switch?

SI

NO

Proceso de recepcin, procesado y almacenamiento (en EEPROM) de la nueva imagen de firmware

LED encendido?
SI

NO

NO

Recepcin OK?
SI

Activacin Flag de regrabado.

Firmware Listo

Encendido del LED luminoso (se mantiene entre reseteos del ND07)
Mquina de estados del Cargador RS232

187

De este modo, se podra concluir que la aplicacin de Cargador RS232 se comportar como un coordinador de red ZigBee genrico (capaz de aceptar asociaciones de dispositivos a la red, enrutar paquetes, etctera), con la peculiaridad de que emitir peridicamente tramas de texto propietarias al canal inalmbrico (y al interfaz serie) y ser capaz de recibir, procesar y almacenar una imagen de firmware para actualizar el dispositivo bajo demanda del usuario.

Esta aplicacin, conceptualmente sencilla, nos permitir demostrar el correcto funcionamiento del bootloader cuando se transmita una nueva versin del cdigo a travs de la comunicacin RS232 y se solicite la actualizacin del firmware va pulsacin del interruptor del ND07.

Para simplificar el desarrollo de la aplicacin de demostracin, el cargador RS232, se ha diseado de tal forma que se limita a recibir imgenes completas a travs de la comunicacin serie (sin tramas de negociacin previas) y slo da por bueno el nuevo firmware cuando ha recibido todos sus registros de forma ntegra (para ello comprueba el cdigo de checksum de cada registro S19).

Para hacer lo ms intuitiva posible la demostracin, se transmitir la imagen de una aplicacin idntica a la que tan solo se le haya modificado el texto de las tramas que enva a travs del aire y de la comunicacin serie. De este modo, la simulacin ser muy similar a una situacin real en la que un programador decidiese actualizar la aplicacin tras haberle realizado alguna pequea mejora. Por otro lado, esta actualizacin podr as comprobarse de forma inalmbrica mediante un Sniffer capturando tramas del canal elegido o de forma cableada mediante un terminal que permita la lectura y transmisin de tramas de texto va RS232. El API de comunicaciones I2C con la EEPROM auxiliar programado durante el desarrollo del bootloader se reutiliz (en una versin ligeramente modificada y sin traduccin a ensamblador ni cdigo mquina) para lograr el almacenaje de las imgenes de firmware recibidas por el puerto serie del ND07.

La parte relativa a la comunicacin RS232 de la aplicacin se ha desarrollado basndose en el API de la UART que incluyen las aplicaciones ZigBee de ejemplo suministradas por Freescale. Puesto que el cargador RS232 se ha desarrollado a partir de un cdigo de ejemplo de un interfaz combinado de automatizacin del hogar (HA Combined Interface), dicho mdulo estaba incluido y slo ha sido necesario aprender a utilizarlo.

Adicionalmente, ha sido necesario realizar todo el estudio previo sobre la tecnologa ZigBee y la librera de Freescale descritos en los captulos 2 y 3 para que, junto con la experiencia adquirida acerca del funcionamiento de sus aplicaciones de ejemplo, tener finalmente control sobre los distintos mdulos que integra el cargador RS232:

188

Control hardware del LED luminoso y puertos de entrada/salida en general (adecuacin al caso del ND07). Puesta en marcha de una red ZigBee y el envo inalmbrico de tramas sobre ella. Temporizadores Software y Hardware (para el watchdog y el reset) Interrupciones de KBI (pulsadores) y rutinas de atencin

Con todo esto, el cargador RS232 desarrollado permitir simular una situacin real de comportamiento de un coordinador ZigBee y validar as el funcionamiento del bootloader en un escenario de actualizacin de firmware a travs de una comunicacin serie RS232.

Adicionalmente, todo el cdigo desarrollado podra ser reutilizado para desarrollar una aplicacin distribuidora de actualizaciones de firmware a travs de una red ZigBee.

189

Captulo 5 Validacin del Sistema

190

5.1.

Introduccin

El bootloader desarrollado en este proyecto ha requerido, como toda aplicacin crtica que se programe, de un concienzudo proceso de depuracin del cdigo y ajuste de sus parmetros.

Aunque una de las propiedades ms interesantes de la aplicacin de bootloader es su independencia con respecto a la aplicacin encargada de realizar la adquisicin y almacenamiento de imgenes de firmware, es imprescindible programar ambas en el ND07 para poder depurar completamente su funcionamiento. De este modo, la depuracin del bootloader se realiz siempre de forma conjunta con la depuracin del cargador RS232.

De este modo, el proceso de depuracin y validacin del cargador RS232 con el bootloader instalado se realiz principalmente mediante 3 estrategias distintas (cada una de ellas especialmente adecuada para depurar un aspecto especfico de la aplicacin):

Validacin mediante el depurador del CodeWarrior Validacin mediante trazas serie Validacin mediante trazas radio ZigBee

A continuacin se describir cada uno de dichos procedimientos y finalmente se ilustrar el escenario de validacin del sistema completo (demostracin del proceso de actualizacin del cargador RS232 mediante el bootloader).

5.2.

Validacin Mediante el Depurador

El entorno de desarrollo del CodeWarrior incluye un depurador (debugger) bastante potente, sin embargo su empleo para la bsqueda y deteccin de errores del bootloader plantea los siguientes inconvenientes:

Puesto que el depurador emplea su propio reloj de referencia para ejecutar el firmware del dispositivo y adems permite realizar paradas (breakpoints) en la secuencia de ejecucin, puede suceder que las temporizaciones requeridas para el borrado y regrabado de pginas de memoria Flash no se respeten adecuadamente y los datos se corrompan. De este modo, la depuracin puede llegar a arrojar ms confusin que pistas acerca de los errores del cdigo (ya que introduce nuevos bugs).

Lo mismo suceder con la depuracin de algoritmos de comunicaciones con perifricos que requieran de temporizaciones especficas (o timeouts). La interrupcin (aunque sea momentnea) de la comunicacin del MC13213 con otro integrado (mediante I2C, RS232, etc.) puede provocar que el perifrico descarte tramas, cierre comunicaciones

191

o simplemente se pierdan datos. Una vez ms, la propia depuracin puede llegar a introducir ms incertidumbre que indicios acerca de los errores del cdigo. El depurador funciona bajo la hiptesis de que el firmware del dispositivo es constante, de modo que emplearlo para validar una sustitucin del firmware por parte del bootloader slo puede realizarse de forma aproximada.

A pesar de todas estas limitaciones, el depurador del CodeWarrior s que se ha empleado para depurar el funcionamiento del bootloader de forma global. Es decir, ha permitido comprobar que diversas secciones del cdigo lograban sus objetivos parciales en determinados instantes concretos (por ejemplo el borrado completo de una pgina de la memoria, una vez ste ha finalizado) pero no ha facilitado la investigacin profunda de todos los algoritmos involucrados por separado.

Sin embargo el depurador s que ha permitido la depuracin meticulosa de la aplicacin principal ZigBee y de su algoritmo de recepcin de imgenes (cargador RS232).

El proceso de validacin mediante el depurador del CodeWarrior requiere de los siguientes elementos software y hardware:

Ordenador (porttil o sobremesa) con el IDE CodeWarrior for Microcontrollers v5.1 instalado y una licencia actualizada Dispositivo USB MultiLink de Freescale y sus drivers instalados en el PC. Dispositivo adaptador de NLaza Soluciones que permita emplear el USB MultiLink para programar el ND07 (adaptador NLaza/Freescale) Fuente de alimentacin regulable capaz de suministrar 2,5 voltios de corriente continua

Aunque en situaciones de funcionamiento normal, para alimentar el dispositivo ND07 slo se requiere de un adaptador de corriente a 4,5 voltios, mientras duren situaciones de programacin del firmware y depuracin de ste la alimentacin ha de realizarse mediante una fuente de alimentacin (regulada a 2,5 voltios) acoplada al adaptador NLaza/Freescale.

Aunque el apartado 3.5.3 ilustra profundamente dicho escenario de aplicacin, ste puede esquematizarse mediante la siguiente figura:

192

Escenario de depuracin del firmware del ND07 Una vez preparado este entorno de trabajo, el desarrollador compilar cada cdigo a evaluar, lo programar en el ND07 e inicializar el depurador (debugger) incluido en el CodeWarrior for Microcontrollers v5.1, pudiendo visualizar as el siguiente conjunto de herramientas:

Captura de pantalla del funcionamiento del depurador incluido en el CodeWarrior [47] Como puede apreciarse en la captura de pantalla, el depurador permite evaluar en un instante concreto de la ejecucin de la aplicacin (breakpoint) todas las variables de contexto relacionadas: mapa de memoria, registros del microcontrolador, valores de variables globales y locales, fuentes del cdigo sin ensamblar y firmware ensamblado.

193

No obstante, como ya se ha mencionado, la interrupcin de la ejecucin secuencial del bootloader durante la actualizacin de un firmware habitualmente provoca que se corrompa el proceso (aunque arroje informacin puntual acerca del funcionamiento de una seccin de cdigo) y sea necesario despus regrabar el dispositivo para seguir depurando.

Adicionalmente, el borrado y regrabacin del firmware en tiempo de ejecucin provocaba en muchas ocasiones que el depurador se bloquease (si se solicitaban breakpoints en determinados puntos del cdigo) y era necesario reiniciar todo el proceso.

Este proceso de depuracin ha sido pues un procedimiento muy lento y trabajoso que ha requerido en muchas ocasiones de la regrabacin del ND07 y de la reinicializacin del depurador decenas de veces para tratar de evaluar el funcionamiento de una seccin concreta del cdigo.

De este modo, la validacin del bootloader (y del cargador RS2323) mediante el depurador se puede sintetizar como un lento procedimiento basado en modificaciones del cdigo, evaluacin de contextos de memoria y un gran nmero de regrabaciones del firmware y reinicializaciones de la aplicacin del depurador.

5.3.

Validacin Mediante Trazas Serie RS232

El desarrollo simultneo del bootloader en conjunto con la aplicacin del cargador serie RS232 ha permitido, en un momento dado, depurar el funcionamiento de diversos mdulos mediante la emisin de trazas a travs de la comunicacin RS232.

No obstante, la funcin ms importante a desempear por la comunicacin serie generada por el cargador RS232 ha sido la de recibir y almacenar imgenes de firmware en la memoria auxiliar. Gracias a esto, se ha podido depurar la seccin del cdigo del bootloader relativa a la lectura de registros modificados S19 desde la EEPROM para su posterior escritura sobre la memoria flash.

El escenario de validacin mediante trazas RS232 ha requerido de un cable serie conectado desde la salida del ND07 hasta el puerto serie de un PC que se encontraba ejecutando una aplicacin de terminal (RealTerm, HyperTerminal, etc.). El esquema se presenta en la figura siguiente:

194

Validacin y depuracin mediante trazas serie As pues, el proceso de validacin mediante trazas serie simplemente ha consistido en la programacin de la aplicacin de forma que transmitiese el estado de determinadas variables de contexto (transmisin peridica o puntual) y se informase acerca del resultado de la ejecucin de secciones concretas del cdigo. De este modo, era posible estimar el correcto o incorrecto funcionamiento del bootloader y del cargador RS232 sin forzar una parada en su secuencia de ejecucin (algo inevitable mediante el depurador) y obtener pistas acerca de los posibles errores.

Obviamente, una vez validado el correcto funcionamiento del bootloader y del cargador RS232 mediante las trazas serie, se han suprimido dichas trazas para la versin definitiva del cdigo ya que, para el usuario final, no arrojarn informacin relevante (adems se transmitirse sta en un formato muy tcnico y poco amigable).

Adicionalmente, el cargador serie RS232 se ha diseado se forma que emitir trazas serie especiales a lo largo de todo el proceso de recepcin de una imagen por el puerto serie, de forma que un usuario pueda saber en tiempo real el progreso del proceso y su estado. Estas trazas en cambio no se eliminarn ya que mejoran la experiencia del usuario del cargador RS232.

5.4.

Validacin Mediante Trazas Radio (ZigBee)

De forma adicional a los dos mecanismos de validacin detallados en los subapartados anteriores, se ha validado el funcionamiento del cdigo desarrollado (en este caso slo del cargador RS232 ya que la radio no se inicializa hasta que el bootloader ha terminado de ejecutarse) mediante la emisin peridica (o eventual) de trazas radio broadcast con datos acerca del contexto de la aplicacin. Una vez ms, estos datos recibidos han mejorado la capacidad del desarrollador de detectar y corregir errores de la aplicacin.

Este escenario de validacin ha requerido de un ordenador (el mismo que realiza las trazas

195

serie u otro adicional) con la aplicacin de captura de tramas SNA (Daintree Sensor Network Analyzer) ejecutndose y el sniffer (Sensor Network Adapter) correctamente acoplado e instalado. El escenario puede apreciarse pues en la figura siguiente:

ZigBee 2006
ND07
Tramas Broadcast Trazas Radio

Cargador RS232 + Bootloader

Sniffer (Sensor Network Adapter)

PC capturando tramas (Sensor Network Analyzer)

Validacin mediante captura de tramas radio El software suministrado por Daintree Networks para la captura de tramas presenta un entorno de trabajo como el de la imagen siguiente:

Captura de pantalla del Daintree Sensor Network Analyzer (SNA)

196

De este modo, el proceso de validacin ha consistido en el estudio de las tramas recibidas a travs del sniffer radio, las cuales incluan informacin acerca de las variables de contexto de la aplicacin bajo anlisis.

De la misma forma que sucedi con las trazas serie, la trazas radio fueron suprimidas en la versin definitiva de la aplicacin del cargador RS232, ya que su funcin haba concluido satisfactoriamente.

Adicionalmente, el cargador serie RS232 se ha diseado se forma que, mientras no se encuentre en proceso de actualizacin mediante el bootloader, emitir tramas radio broadcast (no trazas) para indicar que ha formado una red de la que es coordinador ZigBee.

Estas tramas ZigBee incluirn un campo de texto legible mediante la aplicacin de captura de paquetes (SNA) de modo que, si una actualizacin modificase su contenido (uno de los objetivos de la demostracin del sistema global), este cambio podra apreciarse perfectamente.

5.5.

Validacin del Sistema Completo (Demo Cargador Serie RS232 + Bootloader)

Una vez se ha depurado y validado el adecuado comportamiento de los distintos bloques que conforman la aplicacin del bootloader, es el momento de validar y demostrar su funcionamiento en conjunto con la aplicacin encargada de recibir y almacenar actualizaciones de firmware, el cargador RS232.

El objetivo ms ambicioso que se perseguir en esta demostracin ser el de validar la actualizacin de una aplicacin radio (empleando ZigBee 2006) realizada mediante el bootloader. La aplicacin ZigBee 2006 a actualizar ser, evidentemente, el propio cargador RS232.

Un objetivo secundario de esta demostracin ser el de validar la actualizacin de una aplicacin serie, que tambin ser el cargador RS232.

Obviamente, aunque ambos objetivos se alcanzarn mediante el mismo procedimiento, la validacin/demostracin de su correcto funcionamiento slo ser posible si se disponen de los medios materiales necesarios en el momento de la demostracin.

De este modo, realizar la demostracin de la actualizacin de una aplicacin serie RS232, requerir de los siguientes elementos hardware y software:

197

PC con aplicacin de terminal (RealTerm) para la transmisin de imgenes de firmware ND07 con el cargador RS232 y el bootloader instalados Cable serie conectado entre el ND07 y el puerto serie del PC

Por otro lado, realizar la demostracin de la actualizacin de una aplicacin radio ZigBee 2006, requerir (adems de todos los requerimientos anteriores) de los siguientes elementos hardware y software:

PC con la aplicacin de captura de tramas SNA (Daintree Sensor Network Analyzer) instalada y con licencia Sniffer (Sensor Network Adapter) correctamente acoplado e instalado

Puesto que el procedimiento de actualizacin del cargador RS232 es nico, la demostracin/validacin slo variar en complejidad y objetivos segn el material disponible en el momento de la demostracin.

Para que validacin del sistema global sea realmente una demostracin del funcionamiento del bootloader, se ha decidido que el nuevo firmware que sustituir al original grabado en el ND07 slo implementar modificaciones sobre los campos de texto emitidos peridicamente va radio (ZigBee 2006) y va comunicacin serie (RS232). De este modo, al finalizar la actualizacin, un usuario podr comprobar que el funcionamiento de la aplicacin es idntico salvo por la informacin contenida en dichos campos.

Este escenario ser muy similar al de un sistema real, en el que las actualizaciones no suelen modificar significativamente el funcionamiento de la aplicacin, sino slo corregir errores e incluir ligeras mejoras, a veces inapreciables por el usuario.

De este modo, el escenario de la demostracin/validacin del cargador RS232 con el bootloader instalado puede esquematizarse mediante la siguiente figura:

Escenario de la demostracin

198

Una demostracin completa de todo el procedimiento de actualizacin requerira de los siguientes pasos:

Compilacin y grabacin del cargador RS232 (junto con el bootloader) sobre un dispositivo ND07 a travs de las herramientas de grabacin suministradas por Freescale (cable MultiLink).

Demostracin del funcionamiento de la aplicacin programada (comunicaciones radio y por puerto serie). Realizar una modificacin del cdigo de la aplicacin empleando el CodeWarrior que implique cambios apreciables desde el exterior por los usuarios. Recompilacin y generacin de una nueva imagen de firmware (compuesta por registros S19). Transmisin de dicha imagen a travs del puerto serie del PC al cargador RS232 programado en el ND07. Comprobacin del correcto funcionamiento de todo el proceso. Una vez finalizada exitosamente la transmisin serie, el cargador RS232 proceder a comprobar la integridad de la imagen recibida y que ha almacenado en la memoria auxiliar. En el caso de que este proceso se haya completado satisfactoriamente, el cargador encender un LED para indicar que est listo para actualizarse cuando el usuario as lo requiera.

A continuacin se pulsar el switch del dispositivo para solicitar la actualizacin del dispositivo. Esta pulsacin forzar el apagado del LED. Se realizar despus una espera activa hasta la finalizacin del proceso de actualizacin y el reseteo automtico del dispositivo. Finalmente se comprobar de que la actualizacin se ha efectuado correctamente al aplicarse con xito las modificaciones programadas (reflejadas en las comunicaciones radio y por puerto serie).

Desafortunadamente, seguir secuencialmente todos estos pasos suele requerir de una media de entre 6 a 7 minutos, y de la disponibilidad de varias aplicaciones y perifricos que no puede asegurarse.

Esto se debe a que tanto el CodeWarrior (empleado para la edicin, compilacin y grabacin del cdigo de ND07), como el software del Sniffer (para evaluar el funcionamiento de la comunicacin ZigBee) requieren de licencias y perifricos especficos que podran no estar disponibles en el momento de la demostracin.

De darse esta situacin, la demostracin se podra simplificar hacindola ms sencilla y ms corta en el tiempo. Para ello los nuevos pasos a dar seran los siguientes:

199

Demostracin del funcionamiento de la aplicacin programada (slo por puerto serie si no se dispone de sniffer). Esta aplicacin (cargador RS232) se habra programado previamente en el ND07 en un laboratorio provisto de los medios necesarios.

Transmisin de una nueva imagen de firmware a travs del puerto serie del PC al cargador RS232 programado en el ND07. Este nuevo firmware sera una ligera variacin del anterior y se presentara compilado con antelacin en un laboratorio.

Comprobacin del correcto funcionamiento de todo el proceso de transmisin de la nueva imagen va RS232. En el caso de que este proceso se haya completado satisfactoriamente, el cargador encender un LED indicando que est listo para actualizarse cuando el usuario as lo requiera.

A continuacin se pulsar el switch del dispositivo para solicitar la actualizacin del dispositivo. Esta pulsacin forzar el apagado del LED. Espera activa hasta la finalizacin del proceso de actualizacin que culminar con el reseteo automtico del dispositivo. Comprobacin de que la actualizacin se ha efectuado correctamente al aplicarse con xito las modificaciones programadas (reflejadas en las trazas emitidas desde el cargador RS232 por el puerto serie y en las tramas ZigBee, en el caso de disponer de sniffer).

Esta modalidad de demostracin, siendo considerablemente ms terica y menos visual, se completara en un mximo de cuatro minutos teniendo en cuenta tan solo las temporizaciones de los procesos involucrados.

Una vez ms, es necesario mencionar que la demostracin del funcionamiento del bootloader estar supeditada a los medios materiales y a la cantidad de tiempo disponibles en el momento de su ejecucin.

200

Captulo 6 Conclusiones y Trabajos Futuros

201

6.1.

Visin Global del Proyecto. Conclusiones

Como se introduca al principio de esta memoria, el objetivo principal de este proyecto ha sido el desarrollo de una aplicacin de bootloader capaz de actualizar el firmware de dispositivos pertenecientes a una red de sensores 802.15.4 o ZigBee.

Este objetivo responda a la clara necesidad de proveer de un mecanismo de actualizacin del firmware de los dispositivos ZigBee de la empresa NLaza Soluciones, que permitiese el empleo de cualquier protocolo de carga remota para hacer llegar las nuevas imgenes de firmware a los equipos.

Para alcanzar este objetivo, ha sido imprescindible realizar un profundo estudio previo de las tecnologas relacionadas, los entornos de desarrollo disponibles, las libreras suministradas, y las herramientas que proporcionan (para la reprogramacin de la memoria) el dispositivo y el microcontrolador elegidos.

De este modo, el bootloader se ha programado en diversas fases (primero en C y luego se ha portado a ensamblador y cdigo mquina) alcanzando todos los requerimientos impuestos por el dispositivo, las libreras y la tecnologa: funcionamiento transparente con respecto a la aplicacin principal del dispositivo, robustez, independencia del protocolo de telecarga, facilidad de instalacin y bajos requisitos de memoria, de espacio disponible y de capacidad de proceso.

El correcto desarrollo del bootloader se ha logrado mediante la programacin de una aplicacin auxiliar, un cargador RS232 ZigBee, que ha permitido reproducir (por cable) el funcionamiento real de un protocolo de telecarga y as poder depurar y validar el proceso de actualizacin de firmware.

As pues, fruto de este desarrollo se ha obtenido, adems de las aplicaciones del bootloader y del cargador RS232, un manual para su instalacin en dispositivos NLaza Soluciones funcionando con 802.15.4 o ZigBee 2006, y una serie especificaciones para el correcto almacenamiento de imgenes de firmware en la memoria EEPROM, que los diversos protocolos de telecarga programables debern respetar para garantizar su compatibilidad.

A lo largo de todo el proceso de desarrollo se ha comprobado que las libreras 802.15.4 y ZigBee 2006 suministradas por Freescale para el microcontrolador MC13213, integrado en el dispositivo NLaza ND07, eran tal vez demasiado inmaduras.

As pues, el proceso de desarrollo se ha visto ralentizado e interrumpido en innumerables ocasiones debido a la aparicin de errores crticos en las libreras suministradas. El servicio tcnico de Freescale, aunque ha ido mejorando con el paso de los aos, ha demostrado su

202

ineficiencia y lentitud en la mayora de los casos (el tiempo medio de respuesta a una consulta o notificacin de error en la librera nunca fue inferior a una semana y, por lo general, requera de 4 o 5 respuestas por su parte para que Freescale reconociese una incidencia o plantease una solucin de contingencia).

La numerosa publicacin de revisiones y parches de la librera tambin ha sido un indicador de la inmadurez de la plataforma que, cuando surgi, se planteaba como la ms prometedora de las disponibles en el mercado.

La observacin de la evolucin de la tecnologa a lo largo de los aos tambin sugiere que es ahora, con bastantes aos de retraso, cuando por fin se empiezan a ver soluciones ZigBee disponibles para su adquisicin. Las prestaciones de ZigBee PRO ofrecen soluciones inteligentes para muchos de los puntos dbiles y limitaciones que planteaba ZigBee 2006, por lo que es de esperar que sea esta versin de la especificacin la que se imponga en el mercado.

De igual forma, queda patente que el chip MC13213 de Freescale se queda corto, en cuanto a prestaciones se refiere, para la implementacin adecuada del protocolo ZigBee PRO. Muestra de lo cual es el cese de soporte por parte de Freescale a las libreras ZigBee 2006 y la focalizacin de sus esfuerzos en las libreras PRO y en nuevas lneas de chips ms potentes.

No obstante, 802.15.4 y ZigBee 2006 permiten el despliegue de redes de sensores inalmbricos de bajo consumo completamente funcionales y, el bootloader desarrollado, permitir mejorar an ms sus prestaciones.

De este modo, el bootloader programado se ha empleado exitosamente como base para una aplicacin de carga remota en redes 802.15.4, enmarcada dentro del proyecto de investigacin LoRIS (localizacin en entornos socio-sanitarios) [48], financiado por el ministerio de Industria.

Adicionalmente, el bootloader se encuentra actualmente instalado en diversos modelos de dispositivos ZigBee de NLaza Soluciones, permitiendo la actualizacin de su firmware a travs de diversos protocolos propietarios de telecarga.

Por otro lado, la aplicacin del cargador serie RS232 ser una base idnea para el desarrollo de un coordinador ZigBee encargado de la actualizacin remota de dispositivos empleando para ello las imgenes de firmware que recibe a travs de la comunicacin serie.

Como conclusin se puede afirmar que el proyecto del bootloader ha alcanzado sus objetivos y que su correcto funcionamiento ha sido convenientemente validado en escenarios de aplicacin reales.

203

6.2.

Trabajos Futuros

El bootloader y el cargador RS232 desarrollados en este proyecto sugieren una serie de futuras lneas de trabajo que se enumerarn a continuacin.

1. Creacin de nuevos protocolos de carga remota para distintos escenarios de redes de sensores inalmbricos basados en el bootloader desarrollado. Los protocolos ms interesantes sern aquellos que se diseen de forma que sean compatibles con los comandos y formatos de trama especificados por los perfiles pblicos de aplicacin (Home Automation, Smart Energy, etc.). 2. Ampliacin de las funcionalidades y capacidades del cargador RS232 para que sea capaz de gestionar la red ZigBee 2006 y funcionar como repositorio de actualizaciones para los dispositivos que la conforman. 3. Desarrollo de nuevas aplicaciones ZigBee 2006 que reproduzcan el funcionamiento del cargador RS232 pero que permitan la adquisicin de nuevas imgenes a travs de otros interfaces como RS485, USB o Ethernet, por ejemplo. Las imgenes recibidas se emplearan luego para distribuir inalmbricamente las actualizaciones entre los dispositivos de la red. 4. Creacin de una aplicacin visual que permita la actualizacin remota de dispositivos ZigBee 2006 desde un centro de control como puede ser un PC o similar. Esto implicara el desarrollo de un protocolo de transmisin serie ms robusto con reenvo de tramas y descarte de redundancias. El proyecto de fin de carrera desarrollado por R. G. Carranza para la carga remota en redes 802.15.4 (basado en este bootloader) puede servir de referencia [48]. 5. Modificacin del componente NVM de las libreras ZigBee 2006 para que realice el almacenamiento de datos de contexto en el espacio sobrante de la EEPROM auxiliar (un poco menos de 4K) y as ofrecer una solucin de contingencia para los errores de las libreras para los que no se suministra parche. 6. Migracin del bootloader a las libreras de Freescale de ZigBee PRO. De este modo, al menos los dispositivos finales (que requieren menos memoria y la nueva librera debera caber) basados en chips MC13213 sern compatibles y podrn asociarse a una red ZigBee PRO y disponer de medios para su actualizacin remota.

204

Apndice A
Instrucciones y Recomendaciones de Instalacin

205

A.1. Instalacin del Bootloader

En este apndice se detallar el conjunto de instrucciones necesario para lograr la instalacin del bootloader dentro de una aplicacin ZigBee y los requisitos de diseo de sta ltima que han de cumplirse para garantizarla adecuada coexistencia entre ambos.

Aunque estas instrucciones y especificaciones han sido diseadas para instalar el bootloader dentro de una aplicacin ZigBee 2006 (empleando la pila BeeStack 1.0.5) programada sobre un dispositivo ND07, una leve modificacin de stas permitira realizar dicha instalacin sobre otros dispositivos y libreras a condicin de que empleasen el mismo microcontrolador (el MC13123 de Freescale).

De este modo, el bootloader se ha instalado con xito sobre otros equipos ZigBee de la lnea NDimension de NLaza Soluciones (el ND01, ND02, ND04 y un largo etctera) y sobre placas de desarrollo de Freescale.

Puesto que el bootloader es independiente del protocolo inalmbrico (o conducido) del que hace uso la aplicacin principal, tambin puede instalarse sobre aplicaciones 802.15.4 o Simple MAC empleando las libreras correspondientes que proporciona Freescale. Esto tambin se ha comprobado satisfactoriamente.

A.1.1.

Instrucciones de Instalacin

A continuacin se presentan las instrucciones a seguir para incluir exitosamente el bootloader dentro del proyecto de una aplicacin 802.15.4 o ZigBee desarrollada mediante el IDE CodeWarrior for Microcontrollers v5.1:

1. Dentro del CodeWarrior, crear una nueva carpeta (opcin Create Group) llamada bootloader dentro del proyecto (si es una aplicacin ZigBee 2006, moverla despus dentro del grupo BeeApps por coherencia). 2. Crear ese directorio fsico (dentro del directorio BeeApps) e incluir los ficheros: Bootloader.c Bootloader.h 3. Dentro del CodeWarrior, incluir dichos ficheros dentro de la carpeta bootloader y habilitar su compilacin para todos los targets del proyecto para los que se desee instalar el bootloader. Para ello pulsar sobre el botn del CodeWarrior asociado al fichero bootloader.c siguiente:

206

Captura de pantalla del CodeWarrior for Microcontrollers v5.1 4. Apuntar el vector de interrupcin I2C a su rutina de atencin dentro del bootloader. Para ello abrir el fichero isrvectors.c sito en el grupo: PLM/Source/Common/Sys (podra encontrarse en otro directorio en el caso de no ser un proyecto ZigBee 2006) y sustituir la lnea:
Default_Dummy_ISR, /* vector 24 IIC control */

por las lneas siguientes:

#if Bootloader_Included (void(*near)())0xF87D, /* vector 24 IIC control */ #else Default_Dummy_ISR, /* vector 24 IIC control */ #endif

5.

Incluir la llamada al bootloader dentro de la secuencia de arranque del dispositivo en la posicin concreta acordada en el apartado [Link].2. Para ello, abrir el fichero crt0.h sito en el grupo: PLM/Source/Common/Interface y sustituir las lneas:
#if (gBeeStackProject_c == 1) #define CALL_MAIN_INTERFACE Init();\ RST_GetResetStatus(); \ main(); /* Call user main function */ #else #define CALL_MAIN_INTERFACE Init();\ main(); /* Call user main function */ #endif /*gBeeStackProject_c*/

por las siguientes:

#if (gBeeStackProject_c == 1) && (Bootloader_Included == 1) #define CALL_MAIN_INTERFACE Init();\ RST_GetResetStatus(); \ Nlaza_Bootloader(); \ main(); /* Call user main function */ #elif (gBeeStackProject_c == 1) #define CALL_MAIN_INTERFACE Init();\ RST_GetResetStatus(); \ main(); /* Call user main function */ #elif (gBeeStackProject_c == 0) && (Bootloader_Included == 1) #define CALL_MAIN_INTERFACE Init();\ Nlaza_Bootloader(); \ main(); /* Call user main function */ #else #define CALL_MAIN_INTERFACE Init();\ main(); /* Call user main function */ #endif /*gBeeStackProject_c*/

207

6.

Incluir al principio de dicho fichero las lneas:

#if (Bootloader_Included==1) #include Bootloader.h #endif

7. Deshabilitar la proteccin y la securizacin de bloques para poder actualizar la memoria Flash. Para ello es necesario sustituir en el fichero NVFlash.h en el grupo PLM/Source/NVM las lneas:
#define NVFOPT_VALUE 0x02 #define NVFPROT_VALUE 0x98

Por las siguientes:

#define NVFOPT_VALUE 0x42

#define NVFPROT_VALUE 0xC0

8. Aadir para cada target del proyecto sobre el que se desee instalar el bootloader la siguiente opcin de compilacin (Men Edit-> Settings->Compiler for HC08):
-Dbootloader_Included=1

De este modo, aquellos targets del proyecto que no deseen incluir el bootloader incluirn dicha opcin de compilacin con valor cero o no la incluirn (en cuyo caso el CodeWarrior notificar un warning). 9. Configurar el fichero de parmetros del enlazador (linker) para que reserve para el bootloader las secciones de memoria RAM y Flash requeridas. Para ello es necesario modificar el fichero [Link] (o en el caso de no ser ZiBee 2006 el fichero de parmetros concreto que use el proyecto) sito en /PLM/PRM siguiendo los pasos enumerados a continuacin: a) Reservar una seccin (dentro de la etiqueta SECTIONS) de memoria RAM concreta (no compartida por otras aplicaciones) para el bootloader. Para ello es necesario incluir las siguientes lneas:
//RAM voltil reservada por el Bootloader BOOTLOADER_RAM_SECTION = READ_WRITE 0x0260 TO 0x02A4;

y modificar la seccin de RAM restante consecuentemente a travs de las lneas:

// All of RAM that isnt reserved for something else. APP_RAM = READ_WRITE 0x02A5 TO 0x1047; // RAM

b) Reservar una seccin de memoria Flash concreta (dentro de la etiqueta SECTIONS) para el bootloader. Para ello es necesario incluir las siguientes lneas:
//Vector de interrupcin I2C para aplicacin (siempre justo antes del bootloader) I2C_VECTOR_SECTION = READ_ONLY 0xF7FE TO 0xF7FF;

//Secciones BOOTLOADER (3 pginas) NLAZA_BOOT = READ_ONLY 0xF800 TO 0xF85F;

208

NLAZA_CODE

= READ_ONLY 0xF860 TO 0xFDFF;

y modificar la seccin de Flash restante consecuentemente a travs de las lneas:

// Use this version if there are 3 NV storage pages. APP_CODE_2 = READ_ONLY 0x2000 TO 0xF7FD; // Flash

//Post Bootloader... APP_CODE_3 = READ_ONLY 0xFE00 TO 0xFF4F; // Flash

c) Asignar el cdigo y las variables estticas del bootloader, a sus secciones correspondientes. Para ello es necesario incluir las siguientes lneas dentro de la etiqueta PLACEMENT:
//BOOTLOADER NLAZA_BOOTLOADER NLAZA_BOOTCODE BOOTLOADER_RAM INTO NLAZA_BOOT; INTO NLAZA_CODE; INTO BOOTLOADER_RAM_SECTION;

//Puntero a rutina atencin interrupcin I2C para la aplicacin ppal I2C_APP_VECTOR INTO I2C_VECTOR_SECTION;

y, finalmente, modificar el emplazamiento de cdigo genrico por defecto:

DEFAULT_ROM INTO APP_CODE_0, APP_CODE_1, APP_CODE_2,APP_CODE_3;

Una vez finalizados los nueve pasos enumerados, el bootloader se considerar instalado y se arrancar en cada reseteo del dispositivo.

A.1.2.

Requisitos de la aplicacin ZigBee principal

Para que un programador de aplicaciones 802.15.4 o ZigBee sobre el ND07 (o sobre cualquier dispositivo de la lnea NDimension de NLaza Soluciones) pueda instalar exitosamente el bootloader desarrollado a lo largo de este proyecto, su aplicacin deber cumplir una serie de requisitos de diseo previos.

Dichos requisitos, se enumerarn a continuacin:

1.- La aplicacin deber disponer de suficiente memoria RAM y Flash libre como para alojar convenientemente el bootloader. El bootloader precisa de, al menos: 69 bytes de memoria RAM, ubicados forzosamente en el rango de direcciones [0x0260 0x02A4]. 3 pginas de memoria Flash (1536 bytes) obligatoriamente emplazados en el rango de direcciones [0xF800 0xFDFF].

209

2.- La aplicacin que reciba y almacene las imgenes en la EEPROM deber comprobar que los registros S19 que las conforman apuntan a direcciones de memoria en orden creciente. sta es la opcin por defecto de un fichero de registros S19, pero podran llegar desordenados al dispositivo a actualizar y la actualizacin no se realizara correctamente.

3.- La aplicacin deber descartar los registros S19 de cabecera y fin (en el hipottico y poco prctico caso en que se hayan transmitido al dispositivo a actualizar). Slo habrn de almacenarse en la EEPROM los registros S19 de datos (y convenientemente traducidos al formato de registros S19 modificados).

4.- La aplicacin principal no deber permitir que se inicie el proceso de actualizacin en los casos en que el nivel de batera del dispositivo sea bajo, ya que la interrupcin de la alimentacin durante un proceso de sustitucin de firmware puede provocar que el equipo se dae de forma irrecuperable.

5.- Debido a las limitaciones de tamao de la memoria EEPROM discutidas en el apartado 4.1.3, la imagen de firmware no debe ocupar ms de 63840 bytes una vez almacenada en EEPROM mediante registros S19 modificados. As pues la aplicacin receptora del nuevo firmware deber comprobar este parmetro (si no lo comprueba previamente la aplicacin que distribuir dicha imagen y que tambin, presumiblemente, almacenar la imagen en EEPROM).

6.- Para garantizar una correcta comunicacin entre el bootloader y la aplicacin principal, la semntica de los valores almacenados en el flag de regrabacin del la EEPROM ha de ser la siguiente: Flag=0xAABB La EEPROM contiene una imagen ntegra (con CRC correcto) que

aun no ha sido volcada a Flash (pero que est programada para volcarse en el prximo reseteo del dispositivo). Flag=0xBBBB La EEPROM contiene una imagen corrupta. Flag=0xCCCC La EEPROM contiene una imagen ntegra que ya ha sido empleada para actualizar el dispositivo. Flag=0xDDDD La EEPROM contiene una imagen ntegra que puede emplearse (o no) para actualizar el dispositivo cuando se desee. Sin embargo todava no est programada para actualizar al dispositivo en el prximo reseteo. El resto de valores son ignorados por el bootloader pero pueden ser empleados por la aplicacin principal para indicar otros estados distintos de la imagen almacenada.

7.- La aplicacin programada no deber activar el mecanismo de bloqueo de memoria ni de redireccin de vectores o de lo contrario el bootloader dejar de funcionar correctamente. En cambio, la decisin tomada acerca de la securizacin (o no) de la memoria del dispositivo no afectar al funcionamiento de ste. Los pasos a dar para cumplir este requisito se detallan

210

en el punto 7 de las instrucciones de instalacin.

8.- El programador deber disear las aplicaciones destinadas a actualizar el firmware del ND07 de forma que el vector de interrupcin I2C apunte siempre a la misma posicin de memoria del bootloader. Para alcanzar este objetivo es imprescindible efectuar el paso 4 de las instrucciones de instalacin anteriores. Siempre que se est ejecutando la aplicacin principal (y no el bootloader), el vector de interrupcin I2C estar automticamente redireccionado a las posiciones de memoria [0xF7FE 0xF7FF] (slo por el hecho de instalar el bootloader).

9.- Para garantizar el correcto funcionamiento de la instalacin, la aplicacin deber activar el watchdog y configurarlo con la temporizacin ms larga posible, 218 ciclos de bus.

10.- En el caso de que la aplicacin emplee el mdulo NVM para almacenar variables no voltiles, stas debern ubicarse en las pginas 13, 14 y 15 de la memoria Flash. En el caso de necesitar pginas adicionales es necesario tener en cuenta que el bootloader podra borrarlas durante actualizaciones del firmware, de forma que los datos cuya conservacin sea crtica debern almacenarse nicamente en las pginas citadas.

Incluso en el caso de que la aplicacin 802.15.4 o ZigBee desarrollada cumpla todos estos prerrequisitos de diseo, el desarrollador deber seguir escrupulosamente todas las instrucciones de instalacin del bootloader detalladas en el subapartado A.1.1.1 o de lo contrario no se podr garantizar su correcto funcionamiento.

Como cabe esperar, la aplicacin desarrollada para depurar y validar el bootloader, el cargador serie RS232, cumple de forma estricta todos los prerrequisitos de diseo e instalacin enumerados en este apndice.

A.2. Recomendaciones de Instalacin

Una vez seguidas las instrucciones de instalacin del bootloader junto con las especificaciones de diseo de la aplicacin principal citadas anteriormente, se espera que el conjunto formado por el bootloader y la aplicacin funcione correctamente.

No obstante, existen una serie de recomendaciones de diseo de la aplicacin adicionales que, tomadas en consideracin, pueden optimizar el funcionamiento del dispositivo, protegerlo ante situaciones excepcionales y alargar su vida til.

De este modo, estas recomendaciones de diseo se enumerarn a continuacin:

211

1.- Existe un nmero mximo de borrados y regrabados de la memoria ROM del dispositivo, de modo que conviene actualizarlo slo cuando sea imprescindible (por no hablar de los riesgos que entraa toda actualizacin). Y lo mismo sucede con la EEPROM externa.

2.- Conviene que la aplicacin encargada de activar el bootloader para la actualizacin del firmware de un dispositivo se cerciore previamente del nivel de batera de que dispone y no permita la actualizacin hasta que se pueda garantizar alimentacin ininterrumpida durante todo el proceso. En el caso del ND07 esto no representar un problema significativo ya que est alimentado a la corriente alterna a travs de un transformador. No obstante conviene tenerlo en cuenta y no actualizar el ND07 en entornos de alimentacin fluctuante (como podran ser das tormentosos con riesgo de corte de suministro elctrico).

3.- No se recomienda activar la capacidad de dormir el procesador (propiedad ZigBee muy comn que permite ahorrar batera) hasta la finalizacin de la secuencia de arranque del dispositivo (y con ella una posible actualizacin del firmware por parte del bootloader) para evitar todo riesgo posible de perturbar las temporizaciones internas requeridas.

4.- Toda aplicacin desarrollada que lleve instalado el bootloader requerir de la programacin de un mecanismo capaz de alojar imgenes de firmware en la EEPROM auxiliar mediante el bus I2C. Para que dicho mecanismo funcione correctamente el desarrollador deber programar una rutina de atencin a interrupcin I2C y apuntarla desde el vector I2C redireccionado sito en las posiciones de memoria [0xF7FE 0xF7FF] (ver configuracin del fichero de parmetros .prm de este apndice). Dadas las instrucciones de instalacin del bootloader del anterior subapartado, la forma ms sencilla de lograr dicho objetivo ser mediante las siguientes lneas de cdigo:
typedef void(*ISR_funct_t)(void);

#pragma CONST_SEG I2C_APP_VECTOR const ISR_funct_t I2C_vector[]={ App_IIC_Interrupt }; #pragma CONST_SEG DEFAULT //Cambiar por el nombre concreto de la funcin programada

5.- El ND07, como la mayor parte de dispositivos ZigBee, dispone de recursos de memoria y capacidad de procesamiento reducidos. Es por esto que todo sistema inteligente de actualizacin de dispositivos en un red deber ser diseada de forma que el esfuerzo de procesamiento requerido por los dispositivos receptores de imgenes sea mnimo. La aplicacin encargada de transmitir imgenes de firmware debera evitar el envo de datos superfluos en la medida de lo posible y el formato elegido para la transmisin de imgenes no debera requerir de una transformacin muy compleja en recepcin para poder almacenarlas.

212

El seguimiento de estas recomendaciones, junto con los requisitos e instrucciones de instalacin de los subapartados anteriores, garantizar el desarrollo de un sistema de actualizacin de dispositivos eficiente, robusto y duradero.

213

Apndice B Presupuesto

214

B.1. Fases del Proyecto

Para poder evaluar el coste de personal invertido en la realizacin de este proyecto, es necesario separar en la medida de lo posible las distintas fases de ha comprendido, ofreciendo as una estimacin temporal al mismo.

Esta separacin ser meramente orientativa ya que, como en todo proyecto de ingeniera, ciertas tareas se han solapado y ha existido una constante realimentacin de las conclusiones de cada tarea para la redefinicin y optimizacin de diseos planteados en tareas previas.

De este modo, las tareas realizadas en este proyecto se pueden desglosar, cronolgicamente, de la siguiente forma:

1. Estudio del estado del arte de las tecnologas de redes de sensores de bajo consumo. Estudio en detalle del estndar IEEE 802.15.4 y la especificacin ZigBee. Investigacin acerca de las plataformas de desarrollo disponibles para 802.15.4 y ZigBee en el mercado (principales fabricantes). Seleccin del chip MC13213 de Freescale y del ND07 de NLaza Soluciones como plataformas de trabajo. 2. Familiarizacin con el entorno de desarrollo. Evaluacin del IDE de programacin (CodeWarrior) y de las libreras de 802.15.4 y ZigBee suministradas por Freescale para el chip MC13213. Generacin de aplicaciones de ejemplo (herramienta BeeKit) sobre el kit de desarrollo y entrenamiento para la programacin y depuracin de placas mediante los perifricos incluidos en el kit. Familiarizacin con el API de las diferentes capas y el sistema operativo, formado por el programador de tareas, el sistema de eventos y las interrupciones hardware. Evaluacin del funcionamiento del bajo consumo y de la secuencia de arranque de las aplicaciones. 3. Estudio del chip MC13213 de Freescale. Estudio de los diferentes mdulos y controladores que integra. Aprendizaje de su manejo y configuracin. Evaluacin de la relacin de cada uno de ellos con el bootloader y el RS232. Estudio concienzudo del funcionamiento de la memoria y de las herramientas disponibles para borrarla, regrabarla, protegerla o securizarla mediante el API incluido en las libreras 802.15.4 y ZigBee. 4. Estudio del coordinador ZigBee ND07 de NLaza. Estudio de los componentes que integra (entre los que se encuentra el propio chip MC13213, un chip RS232, una EEPROM auxiliar y varios perifricos como LEDs o pulsadores) y su funcionamiento. Evaluacin de las herramientas disponibles en las libreras para su control y gestin desde el microcontrolador (mdulos de comunicacin I2C y UART principalmente). Estudio de los protocolos serie RS232 e I2C para el manejo de la comunicacin serie y la EEPROM auxiliar respectivamente. Evaluacin y diseo del formato ptimo de almacenamiento de imgenes firmware en la EEPROM auxiliar.

215

5. Programacin del Bootloader en C. Diseo de los diferentes bloques que requiere, programacin de un API para las comunicaciones serie RS232 e I2C (para la memoria auxiliar externa al chip). Programacin en C de los bloques principales del bootloader, capaces de la lectura de firmware almacenado en la EEPROM y de la regrabacin de la memoria Flash en tiempo de ejecucin. Estudio del emplazamiento ptimo del bootloader dentro de la secuencia de arranque del dispositivo y la configuracin de sus parmetros necesaria asociada. 6. Localizacin, reproduccin y resolucin de errores de las libreras de Freescale. Mltiples conversaciones con el servicio tcnico de Freescale va correo electrnico durante meses para conseguir el reconocimiento de errores crticos de sus libreras y as obtener parches o soluciones de contingencia. Publicacin de actualizaciones peridicas de las libreras por parte de Freescale que requeran un considerable esfuerzo para el portado del proyecto bajo desarrollo. 7. Programacin del cargador RS232 (aplicacin auxiliar anfitriona del bootloader). Diseo y programacin de la aplicacin, basada principalmente en el bloque de comunicaciones ZigBee y en el mdulo de la UART para la comunicacin RS232. Instalacin del bootloader dentro de su secuencia de arranque. 8. Portado del Bootloader a ensamblador y cdigo mquina. nica solucin posible para asegurar el funcionamiento del bootloader de forma independiente a la aplicacin anfitriona sobre la que se instale. 9. Validacin y depuracin del cargador RS232 y el bootloader. Deteccin y correccin de errores mediante las herramientas suministradas por Freescale y mediante la emisin de trazas radio y serie. Distintos escenarios de pruebas. 10. Documentacin de proyecto. Generacin de la documentacin asociada al trabajo desarrollado. Generacin de un manual de instalacin (apndice A). Generacin de transparencias para la presentacin del proyecto.

Como puede observarse, aproximadamente la mitad de las tareas enumeradas tienen un considerable estudio terico asociado, lo cual se debe a que gran parte del esfuerzo realizado ha requerido de una profunda investigacin acerca del funcionamiento de las diferentes tecnologas y mdulos involucrados (segn se iba haciendo necesaria).

Todas las tareas enumeradas han sido desarrolladas extensamente en el presente documento, pero siguiendo una ordenacin ligeramente diferente que se describe en el captulo 1.3.

La planificacin de la ejecucin de las tareas de este proyecto (y el solapamiento temporal que tiene lugar entre algunas de ellas), se ilustra en el siguiente diagrama de Gantt:

216

Diagrama de Gantt: Planificacin del Proyecto

217

B.2. Costes de Recursos Humanos

Este apartado recoger los costes asociados al trabajo de las personas implicadas en el proyecto. Para este clculo, se considerar que todo el trabajo ha sido realizado por un ingeniero superior de telecomunicacin.

El salario por hora de un ingeniero superior de telecomunicacin estimado ser de 40 euros/hora, lo que incluir el sueldo que el ingeniero percibe, I.R.P.F, seguridad social y otros gastos de los que la empresa debe hacerse cargo. A continuacin la siguiente tabla presentar, basndose en la enumeracin de las fases del proyecto descritas en el apartado anterior, la estimacin del tiempo que ha requerido cada tarea y su coste asociado:

Tarea Estudio del estado del arte Familiarizacin con el entorno de desarrollo Estudio del chip MC13213 de Freescale Estudio del coordinador ZigBee ND07 Programacin del bootloader en C Localizacin, reproduccin y resolucin de bugs en las libreras de Freescale Programacin del cargador RS232 Portado del bootloader a ensamblador y cdigo mquina Validacin y depuracin Documentacin del proyecto

Horas 176 h 176 h 150 h 40 h 264 h 176 h 40 h 72 h 40 h 328 h

Coste/Hora 40 /h 40 /h 40 /h 40 /h 40 /h 40 /h

Coste Total 7040 7040 6000 1600 10560 7040 1600 2880 1600 13120

40 /h 40 /h

40 /h 40 /h

TOTAL

1462 h Costes de los recursos humanos

58480

Para que esta estimacin sea coherente con el diagrama de Gantt del apartado anterior, es importante sealar que la jornada de trabajo habitual ha sido de 4 horas los das laborables de la semana. Esto se debe a que el proyecto se ha realizado compaginndose con una jornada laboral completa en la compaa NLaza Soluciones.

218

B.3. Costes de Equipo Hardware

Basndose en el listado del captulo 1.4, que enumera los dispositivos y equipo hardware que han sido necesarios para el desarrollo de este proyecto, se puede estimar el coste asociado al material en la siguiente tabla:

Equipo Hardware Ordenador de sobremesa Kit de desarrollo MC1321x de Freescale NLaza NDimension ND07 Programador/Depurador NLaza-Freescale Sniffer Daintree Network Adapter Fuente de alimentacin regulable Cable de puerto serie

Unidades 1 1 1 1 1 1 1

Precio Unitario 479.00 * 1267.98 60.00 30.00 0.00 ** 125.00 2.50

Precio Total 479.00 1267.98 60.00 30.00 0.00 125.00 2.50

TOTAL (sin IVA) Base imponible (IVA 16%) TOTAL (con IVA) Costes del equipo hardware

1964.48 314.32 2278.80

*Coste actualizado a octubre 2009 para un PC de sobremesa Intel Pentium Dual Core E5300 (2.6GHz, 800Mhz, 2MB) de la marca Dell. **El coste del sniffer hardware se incluye dentro del kit de captura de tramas software ms adelante.

B.4. Costes de Equipo Software

Basndose en el listado del captulo 1.4, que enumera las aplicaciones software y las licencias que han sido necesarias para el desarrollo de este proyecto, se puede estimar el coste asociado al equipo software en la siguiente tabla:

Equipo Software Microsoft Windows XP Professional Ed.

Unidades 1

Precio Unitario 120.65

Precio Total 120.65

219

IDE CodeWarrior for Microcontrollers v5.1 con una licencia estndar Servidor de licencias flotantes FlexLm v8.4 Analizador de protocolos Daintree Sensor Network Analyzer (SNA) con una licencia estndar BeeKit Wireless Connectivity Toolkit con una licencia estndar Pila BeeStack 1.0.5. WinMerge 2.0.2 RealTerm [Link]

1 1

666.01 0.00 *

666.01 0.00

1335.36

1335.36

1 1 1 1

866.81 0.00 ** 0.00 0.00

866.81 0.00 * 0.00 0.00

TOTAL (sin IVA) Base Imponible (IVA 16%) TOTAL (con IVA) Costes del equipo software

2988.83 478.21 3467.04

* El coste del servidor de licencias se incluye dentro del coste del IDE CodeWarrior con una licencia flotante estndar. ** El coste de la pila ZigBee y 802.15.4 estn indirectamente incluidos en el coste de la licencia del BeeKit.

B.5. Costes Totales

Finalmente, basndose en los costes calculados de equipo (hardware y software) y de recursos humanos, se concluye el siguiente presupuesto del proyecto:

Concepto Recursos Humanos Equipo Hardware Equipo Software

Coste () 58480.00 1964.48 2988.83

TOTAL (sin IVA) Base imponible (IVA 16% del equipo) TOTAL (con IVA) Presupuesto del proyecto

63433.30 792.53

64225.80

220

Apndice C Glosario y Acrnimos

221

ACK Ad Hoc ADC AF

Asentimiento (Acknowledgement). Tipo de red de control descentralizado en la que cada dispositivo participa en el encaminamiento de paquetes de otros nodos. Conversor analgico-digital (Analog-to-Digital Converter). Plataforma de aplicacin. Nivel de la arquitectura ZigBee encargado de alojar los diferentes objetos de aplicacin y facilitarles diferentes interfaces (Application Framework). Base de datos de nivel de aplicacin (Application Information Base). Protocolo de comunicaciones de nivel 2 en el modelo OSI. Describe un mecanismo de acceso al medio basado en el envo inmediato de datos y luego una escucha del canal en busca de colisiones (en cuyo caso se reintentar ms tarde). Punto de acceso (Access Point). Unidad de datos del protocolo de aplicacin (Application Protocol Data Unit). Interfaz de programacin de aplicaciones (Application Programming Interface). Subnivel de soporte a la aplicacin (Application Support Sublayer). American Standard Code for Information Interchange. Tcnica de modulacin en la que se representan los datos como variaciones de la amplitud de una portadora (Amplitude-shift Keying). Trama baliza. Empleadas habitualmente para sincronizar dispositivos o para publicar las caractersticas de una PAN. Nombre que recibe la implementacin de la pila del protocolo ZigBee por parte de las libreras de Freescale. Ligaduras. Asociaciones lgicas establecidas entre dos endpoints de una red ZigBee. Especificacin industrial IEEE 802.15.1, que define un estndar global de comunicacin inalmbrica de voz y datos entre diferentes dispositivos. Punto de ruptura. Secciones del cdigo donde se interrumpir temporalmente la secuencia de ejecucin de instrucciones para depurar la aplicacin. Envo de informacin que ser recibida por todos los dispositivos de una red. Nmero de secuencia de baliza (Beacon Sequence Number). Error de una aplicacin o librera. Estimacin de canal libre (Clear Channel Assessment). Seales que disminuyen o aumentan de frecuencia con el tiempo. Se emplean habitualmente en tcnicas de espectro ensanchado CSS. Comprobacin de redundancia cclica (Cyclic Redundancy Check). Carrier Sense Multiple Access with Collision Avoidance. Tcnica de espectro ensanchado que emplea pulsos chirp para codificar la informacin (Chirp Spread Spectrum). Elemento de la interfaz grfica de usuario que permite hacer selecciones mltiples de un conjunto de opciones. Suma de verificacin. Es una forma de control de redundancia, una medida muy simple para proteger la integridad de datos.

AIB ALOHA

AP APDU API APS ASCII ASK Beacon BeeStack Binding Bluetooth Breakpoint Broadcast BSN Bug CCA Chirp CRC CSMA/CA CSS Checkbox Checksum

222

DCE

Equipo de Comunicacin de Datos (Data Circuit-terminating Equipment). Se considera DCE a todo dispositivo que participa en la comunicacin entre dos equipos pero que no es receptor final ni emisor original de los datos que forman parte de esa comunicacin. Depurador. Herramienta tpica de un entorno de desarrollo que permite depurar el funcionamiento de un firmware y localizar errores o situaciones no controladas de ste. Tcnica de espectro ensanchado por secuencia directa (Direct Sequence Spread Spectrum). Nmero de secuencia de trama de datos (Data Sequence Number). Equipo Terminal de Datos (Data Terminal Equipment). Es aquel componente del circuito de datos que hace de fuente o destino de la informacin. Cdigo estndar de 8 bits propiedad de IBM (Extended Binary Coded Decimal Interchange Code). Energy Detection. Electrically-Erasable Programmable Read-Only Memory. Punto final de la aplicacin. Por lo general representa uno de los posibles puntos de acceso a una aplicacin desde la subcapa de soporte de aplicacin. Secuencia de verificacin de trama incorrecta (Frame Check Sequence). Dispositivo de funcionalidad completa (Full-Function Device). Bloque de instrucciones de un programa, grabado en una memoria de tipo no voltil, que establece la lgica de ms bajo nivel que controla los circuitos electrnicos de un dispositivo. Uno o ms bits que se emplean para almacenar un valor binario o cdigo que tiene asignado un significado. Tipo de EEPROM que permite que mltiples posiciones de memoria sean escritas o borradas en una misma operacin. Puerto de entrada/salida de propsito general (General Purpose Input Output). Porciones temporales de una supertrama que se asignan a una determinada comunicacin entre dispositivos (Guaranteed Time Slot). Interfaz grfica de usuario (Graphical User Interface). Red de rea del Hogar (Home Area Network). Bus serie IIC (Inter-Integrated Circuit). Entorno de desarrollo integrado (Integrated Development Environment). En el contexto de este proyecto, se denominar imagen a una copia exacta (bit a bit) del firmware de un dispositivo, codificado en un formato concreto. Separacin temporal necesaria entre tramas para otorgar al receptor de tiempo suficiente para su proceso (InterFrame Spacing). Interrupciones similares a las generadas por teclados o pulsadores (Keyboard Interrupt). Esquema de un circuito integrado. Diodo emisor de luz (Light-Emitting Diode). Control de enlace lgico definido por el estndar IEEE 802.2 (Logical Link Control). Representa la parte superior del nivel de enlace del modelo OSI. Proyecto para la Localizacin en Redes Inalmbricas en aplicaciones Sociosanitarias.

Debugger

DSSS DSN DTE EBCDIC ED EEPROM Endpoint FCS FFD Firmware

Flag Flash GPIO GTS GUI HAN IC IDE Imagen IFS KBI Layout LED LLC LoRIS
2

223

LQI LR-WPAN LSB MAC MCU Mesh NIB NPDU MSB OEM OSI OTAP PAN PCB PDU PHY PIB Polling Profile

Indicador de la calidad del enlace (Link Quality Indicator). Red de rea personal inalmbrica de baja tasa de transmisin (Low Rate Wireless Personal Area Network). Bit menos significativo (Less Significant Bit). Capa de control de acceso al medio (Medium Access Control layer). Microcontroller Unit. Red mallada. Network Information Base. Unidad de datos del protocolo de red (Network Protocol Data Unit). Bit ms significativo (Most Significant Bit). Original Equipment Manufacturer. Open Systems Interconnection. On The Air Programming. Red de rea personal (Personal Area Network). Tarjeta de circuito impreso (Printed Circuit Board). Unidad de datos del protocolo (Protocol Data Unit). Capa fsica (Physical layer). PAN Information Base. Operacin de consulta constante. Perfil. Definicin de un conjunto de variables y comandos dentro de un campo de aplicacin determinado, que permitirn a diferentes vendedores crear productos ZigBee interoperables. Tcnica de espectro ensanchado por secuencia paralela (Parallel Sequence Spread Spectrum). Memoria de acceso aleatorio (Random Access Memory). Proceso de devolver a condiciones iniciales un sistema. Habitualmente este objetivo se alcanza apagando y volviendo a encender la alimentacin. Radio frecuencia (Radio Frequency). Protocolo inalmbrico desarrollado conjuntamente con la ZigBee Alliance diseado especialmente para aplicaciones sencillas dispositivo a dispositivo que no requieren de las funcionalidades completas que ofrecen las redes malladas ZigBee. Dispositivo de funcionalidad reducida (Reduced-Function Device). Memoria de slo lectura (Read Only Memory). Indicador de fuerza/potencia de seal recibida (Received Signal Strength Indicator). Punto de acceso a un servicio (Service Access Point). Solucin inalmbrica integrada en un nico chip. Habitualmente el mdem radio y el microcontrolador. Sumidero. Por lo general referido a un nodo de la red encargado de la recoleccin de medidas de otros dispositivos del sistema.

PSSS RAM Reset RF RF4CE

RFD ROM RSSI SAP Single Chip Sink

224

SiP SKKE SMAC

Conjunto de circuitos integrados suministrados todos juntos dentro del mismo mdulo o encapsulado (System in Package). Symmetric-key key establishment. Simple-MAC. Protocolo propietario de Freescale muy sencillo para la comunicacin entre dispositivos inalmbricos punto a punto o en redes en forma de estrella. Se basa en la capa fsica de 802.15.4 y ha sido diseado para dispositivos con muy poca memoria y capacidad de proceso. Dispositivo capaz de capturar las tramas emitidas en un canal compartido. Integracin de todos los componentes de un sistema electrnico dentro del mismo chip (System on Chip). Bus de interfaz de perifricos serie (Serial Peripheral Interface). Subcapa de convergencia entre el servicio de datos del nivel MAC de 802.15.4 (MCPS) y el control de enlace lgico (LLC) (Service-Specific Convergence Sublayer). Proveedor de servicios de seguridad (Security Service Provider). Pila. Se emplea con doble acepcin: como segmento de memoria que utiliza una estructura de datos tipo LIFO para almacenar informacin sobre las llamadas a subrutinas actualmente en ejecucin en un programa (pila de memoria) y como la estructura de capas que conforma la implementacin concreta de un protocolo inalmbrico segn el modelo OSI (pila ZigBee). Seal de inicio de una comunicacin. Seal de fin de una comunicacin. Conmutador o pulsador. Protocolo inalmbrico de Freescale basado en 802.15.4 pero que incluye una capa de red sencilla y propietaria. Conjunto concreto de opciones de compilacin y enlazado definido para un proyecto. Es habitual que un proyecto de CodeWarrior disponga de distintos targets cada uno configurado para distintos dispositivos o funciones. Tiempo de margen que se asigna a un suceso para completar su labor de forma exitosa. Transmisor-Receptor Asncrono Universal (Universal Asynchronous ReceiverTransmitter). Envo de informacin desde un nico emisor a un nico receptor. Ultra-wideband. Alarma del compilador del CodeWarrior para alertar al programador de un posible error en el cdigo generado. Protocolo para el envo inalmbrico de datos tambin conocido como estndar IEEE 802.11b. Red de rea personal inalmbrica (Wireless Personal Area Network). Redes Inalmbricas de Sensores (Wireless Sensor Networks). Coordinador ZigBee (ZigBee Coordinator). Objeto de dispositivo ZigBee (ZigBee Device Object). Perfil de dispositivo ZigBee (ZigBee Device Profile). Dispositivo final ZigBee (ZigBee End Device). Estndar especfico para redes de sensores inalmbricas de bajo consumo.

Sniffer SoC SPI SSCS

SSP Stack

START STOP Switch SynkroRF Target

Timeout UART Unicast UWB Warning Wifi WPAN WSN ZC ZDO ZDP ZED ZigBee

225

Apndice D Bibliografa y Referencias

226

[1] Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low Rate Wireless Personal Area Networks (LR-WPANs).IEEE Std 802.15.4-2003. [Link] (Octubre 2003)

[2] Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low Rate Wireless Personal Area Networks (LR-WPANs).IEEE Std 802.15.4-2006. [Link] (Septiembre 2006)

[3] Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low Rate Wireless Personal Area Networks (LR-WPANs).IEEE Std 802.15.4a-2007. [Link] (Agosto 2007)

[4] ZigBee Specification. Document 053474r06, Ver 1.0. Diciembre 2004. ZigBee Alliance.

[5] ZigBee Specification. Document 053474r13. Octubre 2006. ZigBee Alliance.

[6] ZigBee Specification. Document 053474r17. Octubre 2007. ZigBee Alliance.

[7] Sitio Web Oficial de la Z-Wave Alliance. [Link]

[8] Mike Foley,The New Wireless Frontier. Junio 2007. Bluetooth SIG.

[9] Sitio Web Oficial de la ZigBee Alliance. [Link]

[10] ZigBee Home Automation Public Application Profile (ZigBee Profile 0x0104). Ref. 053520r25. Octubre 2007. ZigBee Alliance.

[11] ZigBee Smart Energy Profile Specification (ZigBee Profile: 0x0109). Ref. 075356r14. Mayo 2008. ZigBee Alliance.

[12] Latest ZigBee Specification and Golden Units Now Available. (Nota de Prensa). Enero 2008. Zigbee Alliance. [Link]

[13] ZigBee Smart Energy: The Standard for Energy Efficiency Available Now. (Nota de Prensa). Junio 2008. ZigBee Alliance. [Link]

[14] Sitio Web de Freescale. Kits de Desarrollo ZigBee y 802.15.4 (chips 1321x). [Link] ?code=1321x_Dev_Kits

227

[15] Sitio Web Oficial de Ember. Kits de Desarrollo ZigBee Insight (EM250 & EM260 chips). [Link]

[16] Sitio Web Oficial de Texas Instruments (T.I.). Kits de Desarrollo ZigBee. [Link] ?familyId=367&genContentId=24196

[17] ZigBee Home Automation: The New Global Standard for Home Automation. (Nota de Prensa). Noviembre 2007. ZigBee Alliance. [Link] ?contentID=12128 [18] [Link] Ortiz, Introduction to OTA Application Provisioning. Noviembre 2002. [Link] [19] Sitio Web Oficial de NLaza Soluciones S.L. [Link]

[20] Sitio Web Oficial de WinMerge. [Link]

[21] Sitio Web Oficial de RealTerm. [Link]

[22] P. Baronti, P. Pillai, V. W. C. Chook, S. Chessa, A. Gotta, and Y. F. Hu, Wireless sensor networks: A survey on the state of the art and the 802.15.4 and Zigbee standards. Computer Communications, vol. 30, no. 7, pp. 16551695. 2007.

[23] Sweden boasts worlds first ZigBee city. (Nota de Prensa). Ref. 075304r00ZB_MWG. Octubre 2007. Ember.

[24] ZigBee Cluster Library Specification. Ref. 075123r02ZB. Mayo 2008. ZigBee Alliance.

[25] Sitio Web Oficial de Microchip. [Link]

[26] Sitio Web Oficial de Atmel. [Link]

[27] Sitio Web Oficial de Freescale Semiconductor. [Link] [28] Sitio Web Oficial de Jennic. [Link]

[29] Sitio Web Oficial de Motorola. [Link] [30] P. Lajsner. Developers Serial Bootloader for M68HC08 and HCS08 MCUs. Ref AN2295. Agosto 2006. Freescale.

228

[31] 802.15.4/ZigBee Embedded Bootloader, Rev 1.1. Ref. 802154EBRM. Febrero 2006. Freescale.

[32] Manual de Instalacin ND07. Ref. NLAZA-MAN-002_1.0. Abril 2009. NLaza Soluciones.

[33] MC13211/212/213/214 ZigBee- Compliant Platform 2.4 GHz Low Power Transceiver for the IEEE 802.15.4 Standard plus Microcontroller Reference Manual. Rev 1.4. Ref. MC1321xRM. Agosto 2009. Freescale.

[34] CodeWarrior Development Studio 8/16-Bit IDE Users Guide. Septiembre 2005. Freescale.

[35] Freescale BeeStack Application Development Guide. Ref. BSADG, rev 1.1. Enero 2008. Freescale.

[36] BeeKit Wireless Connectivity Toolkit Users Guide. Ref. BKWCTKUG, rev 1.9. Septiembre 2009. Freescale.

[37] Freescale BeeStack Software Reference Manual. [Link], rev 1.0. Marzo 2007. Freescale.

[38] Freescale Platform Reference Manual. Ref. FSPRM, rev. 1.0. Enero 2008. Freescale. [39] I2C-bus specification and user manual. Rev.03. Ref UM10204. Junio 2007. NXP. [Link] [40] Using the 87LPC76X microcontroller as an I2C bus master. Ref. AN464. Enero 2000. Philips Semiconductors.

[41] [Link] Wire Serial EEPROM Datasheet. Rev. 1116OSEEPR1/07. Enero 2007. Atmel.

[42] Sitio Web de los foros de Freescale. [Link]

[43] Gestin de memoria HS08 (II), Fichero Motorola S19. Ref. NLAZA-IT-009. Noviembre 2006. Nlaza Soluciones.

[44] Hexadecimal Object File Format Specification. Revision A, 1/6/88. Junio 1988. Intel. [45] HC(S)08 Compiler Manual. Noviembre 2005. Freescale.

[46] HC(S)08/RS08 and HC(S)12 Build Tools Utilities Manual. Abril 2006. Freescale.

229

[47] HC(S)08/RS08 Debugger Manual. Mayo 2006. Freescale.

[48] R. G. Carranza, Diseo y validacin de una aplicacin de configuracin remota de dispositivos sobre 802.15.4. Proyecto Fin de Carrera. Ingeniera Superior de Telecomunicacin. Enero 2009. Universidad Carlos III de Madrid.

[49] EIA Standard RS-232-C Interface Between Data Terminal Equipment and Data Communication Equipment Employing Serial Data Interchange. Agosto 1969. Electronics Industries Association.

[50] HCS08 Flash Integration for ZigBee and 802.15.4 Applications. Ref. AN2770, rev. 1.3, Marzo 2006. Freescale Semiconductor.

[51] S. Ledford, Non-Volatile Memory Technology Overview. Ref. AN1837. 2004. Freescale Semiconductor.

[52] A. Wheeler, Commercial Applications of Wireless Sensor Networks Using ZigBee. IEEE Communications Magazine. Abril 2007. Ember Corporation.

[53] G. L. Lpez, Diseo y desarrollo de una pasarela de interoperabilidad 802.15.4/802.3 para aplicaciones de sensores. Proyecto Fin de Carrera. Ingeniera Superior de Telecomunicacin. Enero 2009. Universidad Carlos III de Madrid.

[54] J. Furness. Tiene Futuro ZigBee?. Artculo de la Revista Espaola de Electrnica (REE). Ed. Marzo 2008, pp. 80-81. Farnell.

[55] C. Buratti, A. Conti, D. Dardari, R. Verdone, An Overview on Wireless Sensor Networks Technology and Evolution. Agosto 2009.

230