de los binarios en EEPROM
La plataforma virtual “Leon2ViP” emula el comportamiento de los mecanismosSDP
4.5. Integraci´on de “Leon2ViP”con GCOV para el an´alisis de cobertura del c´odigo fuente 65
sario realizar una secuencia de escritura de datos en direcciones concretas que habiliten
la capacidad de escritura en la memoria. Por otro lado, el n´umero de veces que se puede
proceder a la la reescritura de datos en memorias EEPROM reales est´a limitado. Aunque
esta cantidad es m´as que suficiente para el tiempo de operaci´on de la ICU, es una bue-
na pr´actica realizar el desarrollo y las pruebas en el entorno virtual y la comprobaci´on
definitiva, con una versi´on madura del procedimiento, sobre el hardware real.
Para cada uno de los escenarios descritos en la tabla4.1en los que no se puede realizar
el boot de la ICU, el BOOTSW pasa a un estado denominadoSafe Mode donde espera
telecomandos de servicio de tipo 6 (Memory Management). Este tipo de telecomandos
permite operaciones dePATCH,DUMP yCHECK de la memoria. Mediante la interfaz
virtual de SpaceWire descrita en la secci´on3.5es posible emular la comunicaci´on con el
ordenador central de la nave y someter al BOOTSW a diversos escenarios de prueba. De
acuerdo con la especificaci´on del formato de telecomandos tipo 6 (Gesti´on de memoria),
el tama˜no m´aximo del campo de datos de una operaci´onPATCH es de 226 bytes. Esto
significa que son necesarios alrededor de 145 (0x8000 / 226) mensajes para enviar la imagen nueva completa de una EEPROM. Para las pruebas se ha partido de un escenario
inicial con los dos bancos EEPROM en blanco. Este caso se corresponder´ıa con la situaci´on
Baseline y Updatable NOK de la tabla 4.1. En una primera fase se ha procedido al
env´ıo de la versi´onUpdatable y se ha comprobado el correcto grabado del binario, con el
consiguiente arranque normal de la aplicaci´on y la recepci´on del mensaje de telemetr´ıa asociado. En una segunda fase se ha procedido al env´ıo de telecomandos para el grabado
de la versi´on Baseline. Finalmente el sistema ha arrancado con el env´ıo del mensaje de
telemetr´ıa TM(51) correspondiente a un informe nominal sin errores.
4.5.
Integraci´on de “Leon2ViP”con GCOV para el an´ali-
sis de cobertura del c´odigo fuente
Las pruebas de cobertura del software de arranque de la ICU se han dividido en dos niveles: cobertura de c´odigo m´aquina y de c´odigo en lenguaje C. Para realizar la cobertura del binario se emplea la funcionalidad de cobertura de c´odigo objeto de “Leon2ViP” tal
como se muestra la secci´on 4.2. Sin embargo en este informe, aparte de los s´ımbolos
globales como los nombres de las rutinas, no hay informaci´on que relacione el binario con el c´odigo fuente escrito en un lenguaje de alto nivel. Puesto que las herramientas de compilaci´on usadas son GNU, se ha procedido a la integraci´on de la herramienta
de an´alisis de cobertura GCOV en el entorno de “Leon2ViP”. La figura 4.4 muestra el
escenario general de uso que consta b´asicamente de tres fases:
Fase de compilaci´on: En esta fase se generan los binarios. Mediante el uso deswitchs
de compilaci´on espec´ıficos el compilador a˜nade la instrumentaci´on de c´odigo ade-
cuada. Esta instrumentaci´on se encarga de ir incrementando una serie de contadores que se corresponden con los bloques de c´odigo C de la aplicaci´on. As´ı, los contado- res reflejan la cantidad de veces que se ha ejecutado cada uno de dichos bloques. El c´odigo necesario para la instrumentaci´on se encuentra en una librer´ıa del compila- dor denominada LIBGCOV. Adem´as, por cada fichero fuente se genera un fichero
Figura 4.4: An´alisis de cobertura con GCOV
GCNO que contiene la informaci´on necesaria para poder recuperar a partir de los bloques de c´odigo binario, las l´ıneas de c´odigo fuente asociadas.
Fase de recolecci´on: En esta fase se ejecuta el programa con la instrumentaci´on
a˜nadida y se procede al almacenamiento de la informaci´on de cobertura en estruc-
turas de datos internas. Finalizada la ejecuci´on del programa, la informaci´on de cobertura se almacena en ficheros GCNA. Se genera un fichero GCNA para cada m´odulo fuente.
Fase de an´alisis: A partir de la informaci´on est´atica, ficheros fuente y GCNO, y de la informaci´on obtenida en tiempo de ejecuci´on se generan los informes de cobertura. Este entorno est´a pensado para la prueba y verificaci´on de software en un entorno que disponga de soporte para un sistema de ficheros. Este hecho dificulta su uso para el an´alisis en sistemas embebidos sencillos ya que no es posible obtener de forma sencilla la informaci´on de los ficheros GCNA. Concretamente en la ICU no hay sistema de ficheros. Sin embargo, puesto que el c´odigo fuente de la librer´ıa LIBGCOV est´a disponible, es posible modificarlo para adaparlo a un escenario espec´ıfico. Pr´acticamente todo el c´odigo de LIBGCOV es C puro y solo necesita servicios del sistema operativo subyacente, al final de la ejecuci´on del programa, cuando desea guardar los datos obtenidos durante la
ejecuci´on del programa. Esto se realiza en la funci´on gcov exit, la cual en la distribuci´on
est´andar escribe los datos en el sistema de ficheros. Modificando esta funci´on es posible redirigir la escritura de los datos a otro lugar o perif´erico.
4.5. Integraci´on de “Leon2ViP”con GCOV para el an´alisis de cobertura del c´odigo fuente 67
Figura 4.5: Adaptaci´on de LIBGCOV a “Leon2ViP”
La figura4.5muestra el escenario implementado para dar soporte GCOV en la plata-
forma virtual “Leon2ViP”.
Se ha modificado gcov exit para que realice el volcado de los datos en un bloque de
memoria en lugar de escribirlos en el disco y se ha generado una nueva LIBGCOV
para el compiladorsparc-elf-gcc.
Haciendo uso del fichero de configuraci´on del mapa de memoria de “Leon2ViP”
se define un nuevo bloque de memoria EEPROM (EEPROM GCOV), fuera del
espacio de direccionamiento normal del BOOTSW. En este espacio de memoria se escribe la informaci´on de cobertura del programa ejecutado.
“Leon2ViP” vuelca el contenido de esta memoria a un fichero externo al finalizar la ejecuci´on. De este volcado se extraen los ficheros GCNA que junto con los GCNO obtenidos en la fase de compilaci´on y los ficheros fuente permiten la elaboraci´on de informe de cobertura en el formato que se estime oportuno.
En la figura 4.6 se muestra un ejemplo de informe de cobertura de c´odigo fuente
Figura 4.6: Ejemplo de informe de cobertura generado con el soporte GCOV