Sistemas Embebidos para Tiempo Real

Documentación Final

Wolverine-Contiki

Comunicación RF basada en MicroControlador y Radio de ultra bajo consumo, utilizando Contiki OS

Integrantes: Bruno Bellini

Rodolfo Jalabert

Tutores: Javier Schandy

Leonardo Steinfeld

 

Resumen

El presente documento contiene la memoria del proyecto Wolverine-Contiki, el cual consistió en la implementación de un nodo para una red de sensores inalámbricos. Se portó el Sistema Operativo (SO) Contiki para el microcontrolador MSP430FR5969 y se implementó el driver de la radio CC110L. Ambos CI se caracterizan por su bajo consumo energético, y pertenecen a la familia Texas Instruments. El porte del SO se realizó a partir de la versión ya existente para el Launchpad MSP-EXP430G2, y el driver de la radio se implementó a partir del driver de la radio CC1101.

Tabla de contenidos

1. Introducción 1.1. Descripción del problema 1.2. Antecedentes

2. Objetivos 3. Alcance 4. Descripción del sistema

4.1. Descripción funcional 4.2 Diagrama de bloques

5. Requerimientos y restricciones del sistema 5.1 Procesamiento y memoria (estimación preliminar) 5.2 Tiempos de respuesta

6. Diseño 6.1 Plataforma de hardware 6.2 Arquitectura de software

7. Implementación 7.1. Port de la Plataforma 7.2. Porte de la Radio

8. Conclusiones A.1. Comparación radio CC1101 vs CC110L A.2. Búsqueda de una solución al error “Security Fuse has been Blown”

Launchpad Based BSL A.3. Planificación Referencias

 

1. Introducción 1.1. Descripción del problema

El problema a resolver fue desarrollar un nodo de una red de sensores inalámbricos de ultra bajo consumo, basado en un microcontrolador de última generación (Wolverine con memoria FRAM) y una radio subGHz. La aplicación de prueba a realizar consistía en medir temperatura (o aceleración) y enviarla a otro nodo utilizando comunicación por radiofrecuencia. El sistema utiliza Contiki OS[1] como sistema operativo. Para ello fue necesario portar dicho sistema operativo al microcontrolador y radio disponibles. 1.2. Antecedentes Si bien en un principio se comenzó trabajando en base al porte de Contiki OS para el mote Sky, posteriormente se optó por partir del porte para el Launchpad MSP-EXP430G2 que se encuentra en [2], ya que se asemejaba más al caso de estudio de este proyecto, y es el antecedente más significativo para el proyecto. Por otro lado, en [3] se pueden encontrar antecedentes de un proyecto realizado por José Basualdo, Nicolás Lamath y Santiago Martínez para la asignatura Redes de Sensores Inalámbricos del IIE, UdelaR, en el cual se portó Contiki parcialmente para el openMSP430 (microcontrolador emulado en FPGA), y se realizaron las rutinas de comunicación con una radio CC2520. Existen además antecedentes internacionales de proyectos similares, como el realizado por G. Oikonomou and I. Phillips, que se encuentra disponible en [4], donde comentan sus experiencias al portar el sistema operativo contiki a una plataforma de hardware popular, el CC2430 de Sensinode. Existe también un trabajo realizado para el port de la radio C1101 a Contiki y la emulación del chip para COOJA en [5], que fue lo que se tomó como base para desarrollar el driver de la radio CC110L. Por otro lado, en Contiki ya existe una implementación base para el MSP430, disponible en [6].

 

2. Objetivos El objetivo del proyecto consistió en implementar, mediante la utilización de las placas de desarrollo MSP-EXP430FR5969 LaunchPad[7] y CC110L AIR Module BoosterPack[8] (ambas de Texas Instruments), una interfaz de comunicación RF (868 Mhz ~ 928 Mhz) portando el SO Contiki[1] para el microcontrolador MSP430FR5969[9] y el driver de la radio CC110L[10]. Adicionalmente, se debía realizar una caracterización del consumo del sistema para sus distintos estados, y opcionalmente se implementaría una aplicación que enviase datos crudos o filtrados, obtenidos de un acelerómetro de bajo consumo ADXL362[11] de Analog Devices. 3. Alcance

• Portar los módulos necesarios del sistema operativo Contiki al microcontrolador MSP430FR5969 utilizando el entorno de desarrollo Code Composer Studio.

• Adaptar los drivers de comunicación por radio de Contiki para comunicarse con una radio

CC1101 y de ser necesario implementar funciones propias.

• Crear un sistema de dos partes: nodo-sensor (envía información) y sink (recibe información).

• Caracterizar el consumo del sistema nodo-sensor para sus distintos estados: TX, RX, Idle,

Sleep, en lo posible utilizando la característica EnergyTrace++[11] de la placa MSP-EXP430FR5969.

• No se elaborará un protocolo particular de aplicación, sino que se enviará la información

en formato ASCII seguida del carácter de retorno de carro utilizando los protocolos disponibles en la distribucion de Contiki (CoAP o simplemente UDP).

Opcionales

• Medir la distancia máxima de comunicación.

• Medir la tasa máxima de comunicación (kbps)

• Enviar datos crudos de las mediciones de un acelerómetro ADXL362.

• Filtrar dichos datos y enviar los resultados obtenidos. Cabe mencionar que, debido a la complejidad del proyecto y a los varios problemas que surgieron durante el transcurso del mismo, estos objetivos secundarios se descartaron a mediados del período del proyecto.

 

4. Descripción del sistema

4.1. Descripción funcional

El sistema a realizar debía constar de dos nodos, un receptor y un transmisor, que se comunicarían por radio a 900 MHz aproximadamente. El nodo transmisor contaría además con un sensor de temperatura (y opcionalmente un acelerómetro) y transmitiría inalámbricamente los datos obtenidos al receptor.

4.2 Diagrama de bloques

En forma esquemática, el sistema a implementar podría sintetizarse de la siguiente manera:

Hardware:

Figura 1. Sistema hardware implementado

Software:

Figura 2. Software utilizado para el desarrollo

 

Software:

Figura 3. Software implementado en la plataforma utilizada

5. Requerimientos y restricciones del sistema

5.1 Procesamiento y memoria (estimación preliminar) Como se describe en la siguiente sección, el MSP430FR5969 cuenta con 2KB de SRAM y 64 KB de FRAM. Una configuración típica de Contiki OS utiliza 2 KB de RAM y 40 KB de ROM[12], por lo que la limitación más grande se tiene por el lado de la memoria SRAM. Sin embargo, se consideró que dado que la aplicación puede prescindir de varios módulos de Contiki, la memoria del microcontrolador requerida sería menor. En cuanto al procesamiento, dado que la comunicación con el módulo de radio se realiza a través del protocolo SPI, y que la otra tarea a realizar es utilizar un ADC para obtener la temperatura, se consideró que la velocidad de procesamiento no va a ser una limitante (16 MHz máximo) y se podrá trabajar al menos a la mitad de la frecuencia máxima de operación. En el caso del TelosB o Tmote Sky, el microcontrolador utilizado también es un MSP430, con una frecuencia de reloj de 4 u 8 MHz, por lo cual resultó razonable pensar que la capacidad de procesamiento del procesador a utilizar en este proyecto sería suficiente.

5.2 Tiempos de respuesta Se consideró que no existen grandes restricciones en los tiempos de respuesta para este proyecto, dado que la aplicación consiste en enviar datos de temperatura (unos pocos bytes) cada un segundo o algún período similar (pero de órdenes de magnitud no muy alejados al segundo).

 

6. Diseño 6.1 Plataforma de hardware

Para el desarrollo del proyecto se utilizó una placa de desarrollo MSP-EXP430FR5969 en conjunto con un CC110L AIR Module BoosterPack. La placa de desarrollo MSP-EXP430FR5969 es una placa de evaluación que viene con un microcontrolador MSP430FR5969, el cual posee memoria FRAM (Ferroelectric RAM) de ultra bajo consumo. La placa provee el hardware necesario para realizar emulación “on-board”, programación, debug y medidas de energía. Algunas características destacables de esta placa son:

❖ MSP430 ultra-low-power FRAM technology based MSP430FR5969 16-bit MCU ❖ 20-pin LaunchPad standard that leverages the BoosterPack ecosystem ❖ 0.1-F super capacitor for standalone power ❖ Onboard eZ-FET emulation with EnergyTrace++™ Technology ❖ Two buttons and two LEDs for user interaction ❖ Backchannel UART through USB to PC [20]

Figura 4. Placa de desarrollo MSP-EXP430FR5969.

El microcontrolador MSP430FR5969 posee una arquitectura RISC de 16 bits y puede funcionar hasta una frecuencia de 16 MHz. Cuenta con 64 KB de memoria FRAM (memoria que combina la velocidad, flexibilidad y performance de una memoria SRAM, con la estabilidad y confiabilidad de una memoria flash, pero consumiendo mucha menos energía), y 2 KB de memoria SRAM. Por otro lado, el módulo de radio utilizado, el CC110L AIR Module BoosterPack, es un transceptor inalámbrico de bajo consumo que consta de 2 borneras compatibles con las plataformas Launchpad. Posee el módulo de radio Anaren Integrated Radio (AIR) A110LR09A que opera en las bandas Europeas 868-870 MHz y Estadounidenses 902-928 MHz ISM, y se comunica con el microcontrolador MSP430 a través de un puerto SPI.

 

Figura 5. Módulo de radio CC110L.

6.2 Arquitectura de software

Se portó el sistema operativo para tiempo real (RTOS) Contiki para el microcontrolador utilizado, por lo que la arquitectura quedó determinada por el SO. Contiki utiliza una interesante arquitectura intermedia entre el Round-Robin con interrupciones y el Multithreading, llamada Protothreads. A continuación se muestra y explica brevemente el árbol de directorios de Contiki:

Figura 6. Directorios de Contiki

❖ Core: Contiene definiciones del core de Contiki como son los timers (etimer, ctimer, rtimer, stimer), procesos, file system, etc.

❖ Cpu: Contiene las definiciones de los microcontroladores y microprocesadores soportados por el sistema operativo.

❖ Examples: Ejemplos de distintos tipos (prender leds, comunicación, manejo de memoria, etc) ya armados para distintas plataformas.

❖ Platform: Definiciones de las distintas plataformas hardware soportadas.

Se adaptaron los módulos necesarios del SO Contiki para hacerlos compatibles con el microprocesador y el módulo de radio.

 

7. Implementación Lo primero que se intentó realizar fue portar Contiki OS. Se descargó contiki_2.7[16] y se importó

un proyecto (Makefile Project with Existing Code) en Code Composer Studio (CCS) V6, trabajando

en Windows 7. Se eligió el ejemplo para launchpad blink.c (examples/launchpad/blink), que hace

parpadear ambos leds de la plataforma, pero tras varios intentos fue imposible poder compilar el

ejemplo de Contiki correctamente. El problema surge de que el make que utiliza el CCS en

Windows no interpreta correctamente los makefiles de Contiki.

Al trabajar con una distribución Linux hay varios problema ya resueltos, ya que Contiki está

pensado para ser compilado en este sistema operativo, por lo que se decidió instalar el CCS sobre

una máquina virtual (VMWare) con Ubuntu 12.04. Sin embargo, esto trajo consigo la problemática

de enfrentarse a un sistema operativo desconocido, con lo cual cada instalación, búsqueda de

archivos o cualquier otra tarea que se quiso realizar consumió un tiempo mucho mayor que el que

se emplearía en Windows para realizar la misma tarea.

Para la instalación del CCS, se siguieron los pasos descritos en la Wiki de Texas Instruments [14],

habiendo previamente descargando el instalador de CCS para Linux.

Una vez instalado el CCS, se probó compilar y cargar el ejemplo blink de manera exitosa.

Cabe destacar que CCS en Ubuntu no posee los drivers necesarios para poder debuggear el

launchpad MSP-EXP430G2, por lo que una vez compilado el ejemplo (generándose un archivo

blink.launchpad) se utilizó el debugger gratuito para los MCU MSP430, mspdebug[17]. Utilizando

una Terminal, y posicionándose sobre la carpeta ../examples/launchpad/blink, se deben escribir

los siguientes comandos:

>>prog blink.launchpad

>>run

Una vez compilado el primer ejemplo, se pasó a portar el mismo ejemplo, pero para la plataforma

hardware de este proyecto. Por demoras en tiempo de compilación y problemas de memoria de la

máquina virtual, se pasó a trabajar en una computadora con Ubuntu 14.04 LTS nativo.

Es posible identificar todas las líneas en los archivos que fueron modificados (.c, .h o Makefiles), ya

que contienen un comentario del estilo //WOLVERINED o #WOLVERINED. Por esta razón y debido

a que las funciones que han sido modificadas son básicamente inicializaciones de registros, etc.,

consideramos que no tiene sentido realizar una documentación en formato Doxygen del código,

ya que el mismo contiene los comentarios originales de los desarrolladores del SO, y no hay

nuevas funciones implementadas por nosotros que puedan llevar comentarios Doxygen

relevantes.

 

7.1. Port de la Plataforma

Dada la complejidad de adaptar el porte de Sky hacia nuestra plataforma, y dado que existe un

port de Contiki para el launchpad MSP-EXP430G2[2] (la cual es más similar a nuestra plataforma),

se decidió partir de este port y adaptarlo a nuestra plataforma Wolverine. Este port compila

correctamente sin necesidad de modificaciones en CCS para Linux.

A continuación se realiza un listado de los pasos seguidos para adaptar a nuestra plataforma un

ejemplo que hace parpadear los leds:

1. Se parte del programa ejemplo localizado en examples/launchpad/blink/blink.c (aplicación)

el cual hace un include de contiki.h, que incluye a contiki-conf.h, e incluye a

platform-conf.h, el cual define la configuración de la plataforma. En platform-conf.h, se

realizan los siguientes cambios:

a. Línea 93: #define USE_SERIAL 0 (se deshabilita la comunicación serial

transitoriamente)

b. Se comenta la línea 125 e incluye la configuración de los puertos donde se

encuentran los LEDs de la placa de desarrollo:

Figura 7. Modificaciones del archivo platform-conf.h.

 

2. Se crea un nuevo proyecto de CCS para el micro MSP430FR5969, de manera de obtener el

archivo MSP430FR5969.ccxml dentro de targetConfigs, que luego será utilizado para

debugear (Contiki no lo trae por defecto).

Figura 8. Target Configs.

3. En CCS se importa un proyecto a partir de makefiles ("Existing code as Makefile Project") y

se selecciona el directorio donde se encuentra el port de Contiki para el Launchpad. Al

hacer ésto, queda el siguiente árbol de directorios dentro del proyecto:

Figura 9. Estructura de directorios de Contiki OS.

 

4. Luego se agregan las siguientes propiedades al proyecto importado:

a. en C/C++ Build, Builder settings

i. “Build Command: make TARGET=launchpad”

ii. “Build directory: {carpeta del programa ejemplo}

b. en C/C++ General, Paths and Symbols

i. en Includes, GNU C se incluyen las siguientes carpetas:

1. usr/msp430/include

2. contiki-launchpad/cpu/msp430

3. contiki-launchpad/cpu/msp430/dev

4. contiki-launchpad/cpu/msp430/fr5xxx

5. contiki-launchpad/platform/launchpad

6. contiki-launchpad/platform/launchpad/dev

ii. en Symbols, GNU C se incluyen los siguientes símbolos:

1. __GNUC__ (Value = 1)

2. __MSP430__ (Value = 1)

3. __MSP430FR5969__ (Value = 1)

4. __MSPGCC__ (Value = 1)

(Nota: estos símbolos son sólo para poder navegar las variables en CSS, pero no influyen en el

proceso de compilado ya que dichas banderas son incluídas en los makefiles)

Los includes dentro del navegador de proyecto deberían verse de la siguiente manera:

Figura 10. Includes necesarios al proyecto.

5. En platform/launchpad/Makefile.launchpad se modifica:

a. Línea 8: MCU=msp430fr5969 (se cambia para el microcontrolador en uso)

b. Línea 58: #include $(CONTIKI)/cpu/msp430/g2xxx/Makefile.msp430

c. Línea 61: include $(CONTIKI)/cpu/msp430/Makefile.msp430 (se incluye el Makefile

general)

 

Figura 11. Modificación del archivo Makefile.launchpad.

6. cpu/msp430 → Se crea una carpeta fr5xxx a partir de la g2xxx; se modifican todos los

archivos necesarios dentro de esta carpeta para configurar relojes, timers, etc.

7. cpu/msp430/Makefile.msp430:

a. Línea 34. Se agrega:

ifndef CONTIKI_CPU_FAM_DIR

ifneq (,$(findstring msp430fr5,$(MCU)))

CONTIKI_CPU_FAM_DIR = fr5xxx

endif

endif

Para manejar la familia FR5

8. Run → Debug Configurations → Se elige “Target Configuration” = MSP430FR5969.ccxml y

“Program” = blink.launchpad, para poder debuggear.

Hasta este punto, los módulos de UART, SPI, ADC, etc. que no se utilizan para parpadear los leds

fueron comentados dentro del archivo ../platform/launchpad/Makefile.launchpad. Solamente se

mantuvieron los módulos de leds y botones. También se comentaron los módulos en

DEV_SOURCES y RADIO_SOURCES.

 

Figura 12. Modificaciones en Makefile.launchpad

Por último se modificó el proceso en blink.c para que en vez de parpadear ambos leds con los

timers, uno parpadeara y el otro esperará por un evento de botón (presión de botón) para

cambiar el estado del led.

Figura 13. Proceso blink_process

 

Debemos mencionar en este punto, que hubo problemas al intentar compilar este sencillo

ejemplo, por incompatibilidades entre el archivo estándar de registros y definiciones de bits

msp430fr5969.h que trae el CCS y el código fuente de Contiki, el cual utiliza la versión del

compilador GNU, en particular con lo referente a los vectores de interrupciones y las rutinas de

atención de las mismas. Este problema se solucionó en Linux nativo añadiendo el directorio

usr/msp430/include dentro de los includes del proyecto, aunque esto no funcionó en VMWare.

Una vez realizadas las modificaciones descritas se compiló y se programó nuestra plataforma

correctamente. También se pudo probar la función EnergyTrace++ y observar numérica y

gráficamente el consumo de la plataforma.

Luego de tener el ejemplo correctamente compilado y cargado se procedió a portar, de la misma

forma que el procedimiento descrito anteriormente, el módulo SPI (necesario para la

comunicación con la radio) y la radio, como se explica a continuación.

7.2. Porte de la Radio

El proceso de adaptación de los drivers de la radio fue similar al que se realizó anteriormente para

los módulos del Launchpad. Para ello, se bajó del repositorio [15] los drivers para la radio CC1101

que es muy similar a la CC110L. Dentro de los archivos correspondientes se modificaron todos

aquellos registros que difieren una de otra (ver Anexo A1), teniendo el cuidado de mantener una

configuración compatible. Se procedió de manera similar con las funciones de inicialización de la

radio.

Figura 14. Modificación de la arquitectura de la radio.

 

De la carpeta descargada, se copiaron los siguientes archivos de dev/cc1101:

❖ cc1101.c

❖ cc1101.h

❖ cc1101-arch.h

❖ cc1101-const.h

❖ cc1101-config.h

❖ cc1101-msp-arch.c

Dichos archivos se copiaron en platform/launchpad/dev

Se copiaron los archivos de core/dev:

❖ radio.h

En la carpeta core/dev de nuestro proyecto, reemplazando los ya existentes.

Se copiaron los archivos de core/net a la carpeta core/net de nuestro proyecto (no existían):

❖ linkaddr.c

❖ linkaddr.h

Luego de portados los módulos de SPI y lo referente a la radio, se quiso portar el módulo UART (ya que los distintos módulos de la radio utilizan varios “printf” para realizar el debugging. Al momento de compilar y cargar un ejemplo para realizar la prueba de la radio, ../examples/launchpad/periodic-broadcast/periodic-bc.c, se comenzó a recibir el siguiente error cada vez que se quería cargar nuevamente el programa: “Security Fuse has been Flown”. Dicho error dejó inutilizables las plataformas e implicó varios días de trabajo en la búsqueda de una solución a este inconveniente (ver Anexo por más detalles). Si bien no sabemos con certeza qué fue lo que causó el problema, especulamos que puede deberse a que se hayan realizado erróneamente escrituras (de valores distintos a 0x00 o 0xFF) en los registros 0xFF80 o 0xFF82 (coinciden con el comienzo del rango de los vectores de interrupciones) que se utilizan para impedir la comunicación con el uC a través de la interfaz JTAG. Dado que el error fue imposible de solucionar, para seguir con el proyecto se optó por seguir trabajando con el Launchpad MSP-EXP430G2 y la radio CC110L. Luego de rearmar el proyecto para esta plataforma se logró portar la radio, con el debug por UART incluído, pero lamentablemente no dieron los tiempos para corregir algunos inconvenientes que impiden la comunicación entre ambos nodos.

 

Figura 15. Errores recibidos por la UART al momento de transmitir datos.

8. Conclusiones

En primer lugar, debemos observar que lamentablemente no se alcanzó por completo el objetivo

principal del proyecto. Se considera que dada la complejidad del mismo, se dificultó enormemente

la estimación de tiempos de trabajo, y si bien en un principio parecía posible que las cosas se

desarrollaran de otro modo, nos encontramos con una gran variedad de complejos problemas,

que estuvieron fuera del alcance del curso, ya que no tuvieron relación con lo visto en clases o

laboratorios, sino con problemas técnicos de las herramientas de compilación, utilización de un

nuevo sistema operativo, problemas imprevistos con las placas de desarrollo, etc.

Debido a la complejidad (y nuestra inexperiencia en desarrollos de RTOS), se considera que para

llevar a cabo al proyecto hasta su objetivo final en tan corto plazo, se debió contar con más ayuda

por parte de los tutores (el proyecto, que debió ser de 40 horas por persona, en la realidad llevó

más de 80), aunque por otro lado, tal vez el aprendizaje adquirido de esta manera sea mayor (si

bien el resultado “visible” pueda ser menor a lo esperado).

Por el lado positivo, se puede decir que se logró portar Contiki para la plataforma

MSP-EXP430FR5969, y por la experiencia se sugiere utilizar y conocer Linux previamente. Son

necesarios además conocimientos de Makefiles, ya que es una parte influyente en el proceso de

portar Contiki, y por esto mismo, no parecería recomendable utilizar CCS ya que Contiki no fue

creado (ni está pensado para ser utilizado) en esta plataforma de desarrollo.

En relación a la utilización de RTOS podemos destacar que no se pudieron observar los beneficios

de utilizar Contiki OS: si no existe un port para la plataforma, podría ser más rápido desarrollar el

mismo proyecto sin utilizar RTOS, si es que el objetivo del proyecto en cuestión se centra en

desarrollar un nodo funcional y no solamente en portar el SO.

 

Anexo:

A.1. Comparación radio CC1101 vs CC110L

La radio utilizada en este proyecto fue la CC110L, la cual es una radio basada en la CC1101 con características de RF idénticas.[8] Las diferencias y similitudes entre ambas radios se listan a continuación:

CC1101 CC110L

Registros “Strobe” 13 11

SWOR (addr 0x38) no lo tiene

SWORRST (addr 0x3C) no lo tiene

Registros de configuración 47 39

WOREVT1 (addr 0x1E) no lo tiene

WOREVT0 (addr 0x1F) no lo tiene

WORCTRL (addr 0x20) reservado

RCCTRL1 (addr 0x27) no lo tiene

RCCTRL0 (addr 0x28) no lo tiene

FSTEST (addr 0x29) reservado

PTEST(addr 0x2A) reservado

AGCTEST (addr 0x2B) reservado

Registros de “Status” 12 9

LQI (addr 0x33) CRC_REG (addr 0x33)

WORTIME1 (addr 0x36) reservado

WORTIME0 (addr 0x37) reservado

VCO_VC_DAC (addr 0x39) reservado

RCCTRL1_STATUS (addr 0x3C) reservado

RCCTRL0_STATUS (addr 0x3D) reservado

 

A.2. Búsqueda de una solución al error “Security Fuse has been Blown” Como se mencionó en la sección 7.2, el error de Security Fuse has been Blown causa el impedimento para comunicar la plataforma con el CCS. Estos registros o “fusibles” de seguridad se encuentran en la misma región de memoria que los vectores de interrupción del microcontrolador y deben contener el valor 0xFFFF para que no cause el error.

Figura A.2.1. Tabla con la organización de memoria extraída de la hoja de datos del microcontrolador.

Luego de investigar en una gran cantidad de foros y documentos sobre la familia de microcontroladores MSP430 se llegó a la conclusión que la única forma de solucionar este problema es a través del Boot Strap Loader (BSL). El BSL es una herramienta para programar microcontroladores MSP430 a través de un puerto serie (típicamente UART o SPI). Con el BSL es posible leer y escribir la memoria del uC.[18] Lamentablemente, esta herramienta no se encontraba disponible en el Instituto de Ingeniería Eléctrica, y dado el poco tiempo pendiente para la finalización del proyecto (2 semanas), se tornó inviable la adquisición de uno.

 

Figura A.2.2. Boot Strap Loader (Modelo Rocket).

Launchpad Based BSL  Texas Instruments provee un documento en el cuál se expone cómo realizar un BSL a través de un Launchpad[19] y esto fue lo que se intentó realizar. Ya que se contaba con el MSP-EXP430G2 Launchpad, se decidió utilizar éste como bypass de la UART entre el PC y el MSP-EXP430FR5969 Launchpad y generador de la secuencia de entrada a BSL, tal cual lo indica la imagen a continuación.  

 

Figura A.2.3. Configuración hardware para implementar el BSL con Launchpad y secuencia a generar necesaria para entrar en modo BSL.

Se utiliza la señal TEST para generar la secuencia de entrada, en vez de la TCK, porque como se indica en el documento [19], si los pines de JTAG se comparten con otras funcionalidades debe

 

realizarse con TEST. Por lo tanto, se implementó el sistema descrito, generando la secuencia de entrada.

Figura A.2.4. Sistema implementado y secuencia de entrada generada

Como puede observarse en la figura A.2.4, la secuencia de entrada a BSL se estaba generando correctamente, pero desafortunadamente el uC no entró en modo BSL, por lo que no se pudo enviar un programa nuevo mediante el BSL_Scripter en el PC.

A.3. Planificación A continuación se realiza una comparación entre lo planificado al comienzo del proyecto y lo realmente realizado.

Referencias: X - Programado, X - Realizado

 

Tarea \ Fecha 20/4 27/4 04/5 11/5 18/5 25/5 01/6 08/6 15/6 22/6

Descripción inicial del proyecto X

X

Descripción final del proyecto

X

X

Estudio de plataforma

MSP-EXP430FR5969

X

X

X

X

Estudio de plataforma CC110L

AIR Module (Radio)

X

X

X

X

Estudio y adaptación de Contiki

para MSP430FR5969

X

X

X

X

X

X X X

Presentación del proyecto

X

X

Control del módulo de radio

para TX y RX X X X X X

Hito

X

X

Armar un módulo de TX (envía

valor de temperatura o de

acelerómetro)

X X

Armar un módulo de RX X X

Pruebas finales X

Documentación

X

X

X

X

X

X

X

X

X

X

X

X

X

X X X

Defensa X X

(Opcional) Incorporar el

acelerómetro. Estudio del

bitrate y distancia máx. de

comunicación

X X

 

Como puede observarse, tanto la adaptación de Contiki para la plataforma como la adaptación de los drivers de la radio, tomaron más tiempo de lo planificado. Si se suman estos retrasos a el resto de los problemas enfrentados se llega al por qué no se llegó a resolver el problema completo y quedaron descartados los objetivos opcionales.

Referencias [1] - http://www.contiki-os.org/index.html [2] - https://github.com/msloth/contiki-launchpad [3] - https://drive.google.com/file/d/0B9Pqg3gA0es9bEx4cGJ4VVhYZ0UxRGxTZlBkYU1oM2JQWF9R/view [4] - http://dx.doi.org/10.1109/dcoss.2011.5982222 [5] - https://github.com/contiki-os/contiki/pull/1002 [6] - https://github.com/contiki-os/contiki/tree/master/cpu/msp430 [7] - MSP-EXP430FR5969 LaunchPad™ Development Kit - http://www.ti.com/lit/ug/slau535a/slau535a.pdf [8] - http://www.ti.com/tool/430Boost-CC110L [9] - MSP430FR59xx Mixed-Signal Microcontrollers - http://www.ti.com/lit/ds/symlink/msp430fr5969.pdf [10] - CC110L Value Line Transceiver - http://www.ti.com/lit/ds/symlink/cc110l.pdf [11] - http://www.analog.com/media/en/technical-documentation/data-sheets/ADXL362.pdf [12] - http://www.ti.com/tool/energytrace [13] - http://contiki.sourceforge.net/docs/2.6/ [14] - http://processors.wiki.ti.com/index.php/Linux_Host_Support_CCSv6#Ubuntu_12.04_64bit

[15] - https://github.com/adamdunkels/contiki-fork/tree/pr/cc-subghz

[16]- http://sourceforge.net/projects/contiki/files/Contiki/

[17]- http://dlbeer.co.nz/mspdebug/

[18]- http://www.ti.com/tool/MSPBSL

[19]- LaunchPad-Based MSP430 UART BSL Interface - http://www.ti.com/lit/an/slaa535a/slaa535a.pdf

 

[20]- http://www.ti.com/tool/MSP-EXP430FR5969

[21]- Migrating from the MSP430F2xx and MSP430G2xx Families to the

MSP430FR58xx/FR59xx/68xx/69xx Family - http://www.ti.com/lit/an/slaa559c/slaa559c.pdf