PDF de programación - Interfaz de depuración para microcontrolador

INTERFAZ DE DEPURACI ÓN PARA MICROCONTROLADOR

Tropea, S. E.

Electrónica e Informática

Instituto Nacional de Tecnología Industrial

Buenos Aires, Argentina

email: [email protected]

ABSTRACT

En este trabajo presentamos el desarrollo de una inter-
faz de depuración desarrollada para ser usada con un
microcontrolador compatible con el PIC 16C84.

La misma permite controlar la ejecución del micro-
controlador permitiendo detenerla y/o reanudarla. Pa-
ra detener la ejecución se proveen mecanismos directos
así como puntos de parada en el código (breakpoints)
o por acceso y/o modificación de datos (watchpoints).
Esta interfaz permite acceder a registros internos del
controlador e inspeccionar el stack.

Este core se complementa con el desarrollo de un
programa que permite la utilización de interfaces de
usuario de alto nivel ya existentes. Esto se logró utili-
zando el protocolo GDB/MI del GNU debugger.

1. INTRODUCCI ÓN

El desarrollo de sistemas electrónicos basados en sis-
temas embebidos presenta un desafío a la hora de elimi-
nar errores de implementación. Esto se debe a que los
microcontroladores utilizados para estas tareas suelen
ser pequeños y no es posible que ejecuten las complejas
tareas involucradas en la depuración de errores. La ta-
rea se dificulta aún más cuando dichos dispositivos no
poseen una interfaz de usuario amistosa, sin salida de
video donde conectar un monitor ni entradas de teclado
o similares para ingresar datos.

Para solucionar estos problemas se suele incluir fun-
cionalidad en el microcontrolador que permite realizar
las tareas de depuración en forma remota utilizando
una computadora personal, donde se encuentran dispo-
nibles los recursos antes mencionados.

En este trabajo presentamos el desarrollo de una
interfaz de depuración especialmente creada para ser
usada en conjunto con un microcontrolador compati-
ble con el PIC 16C84 de Microchip [1] implementado
en la misma FPGA. Dicho microcontrolador [2] [3] fue

desarrollado por nuestro equipo de trabajo. Cabe des-
tacar que el microcontrolador original no dispone de es-
tas funcionalidades y que sólo microcontroladores más
avanzados de su familia poseen limitadas capacidades
de este tipo.

El objetivo de este trabajo fue el de obtener un me-
canismo que permitiera eliminar errores de implemen-
tación en proyectos basados en dicho microcontrolador.

2. METODOLOGÍA

Las herramientas de desarrollo utilizadas fueron las
recomendadas por el proyecto FPGALibre [4] [5]. Para
este desarrollo se utilizaron estaciones de trabajo que
corren Debian [6] GNU [7] /Linux.

Se procedió a agregar dos puertos especiales al mi-
crocontrolador, uno de entrada y otro de salida. Debi-
do a que dichos puertos poseerían numerosas señales, a
que las mismas serían usadas opcionalmente en el caso
de que se conectara este accesorio y a que las mismas
podrían cambiar en el futuro, se utilizaron los llama-
dos records de VHDL que permiten agrupar señales, tal
como una estructura en C permite agrupar variables.

Se agregó funcionalidad al microcontrolador para
poder detener su ejecución, inspeccionar sus registros
y monitorear la actividad del bus de datos. Esta fun-
cionalidad se exportó a través de los puertos antes men-
cionados.

Se diseñó un periférico compatible con WISHBONE
[8] que implementara la funcionalidad necesaria para
controlar las señales antes mencionadas. Se seleccionó el
estándar de interconexión WISHBONE con el objeti-
vo de que el periférico pudiera ser accedido utilizando
distintos mecanismos de comunicación entre la compu-
tadora y la FPGA. Para el diseño inicial se seleccionó un
puente [9] que permite interconectar el puerto paralelo
de una PC con un bus WISHBONE. De esta mane-
ra el nuevo periférico pudo ser controlado utilizando el
puerto paralelo de una PC.

Para interpretar los comandos provenientes de la

PC y detener o reanudar la ejecución de la CPU se
utilizó una máquina de estados. La misma permite de-
tener la ejecución sólo en los ciclos de reloj adecuados,
decodificación y lectura de operandos, y manejar la eje-
cución paso a paso.

Para permitir que el número de breakpointsy watch-
pointsfuera configurable sin alterar la cantidad de regis-
tros de entrada/salida del periférico, se implementó un
registro selector de breakpointsy otro de watchpoints.
Esto permite al periférico implementar 1 a 255 elemen-
tos manteniendo la estructura de registros.

3. SOFTWARE COMPLEMENTARIO

Se creó un programa escrito en C++ que permite
controlar este periférico utilizando el puerto paralelo
de una PC. Debido al hecho de que crear la interfaz de
usuario para la depuración de un programa es una ta-
rea muy compleja se optó por aprovechar una interfaz
de usuario ya existente. De esta manera sólo fue nece-
sario concentrarnos en la parte técnica del problema.
Para comunicar nuestro programa con una interfaz de
usuario ya existente se optó por implementar el proto-
colo denominado GDB/MI (GNU DeBugger Machine
Interface). Este protocolo es parte del depurador del
proyecto GNU, el GNU debugger, y permite controlarlo
desde una interfaz de usuario amigable. De esta manera
fue posible utilizar una interfaz de usuario que original-
mente fue diseñada para controlar al GNU debugger.

Para dicha interfaz de usuario se seleccionó el pro-
grama SETEdit [10]. El mismo es el entorno de trabajo
recomendado por el proyecto FPGALibre. SETEdit im-
plementa el protocolo GDB/MI para la depuración de
programas en C/C++ y assembler por lo que no fue-
ron necesarios cambios importantes para lograr que el
mismo se adaptara a la depuración de programas es-
critos en lenguaje de ensamblador corriendo en dicho
microcontrolador.

4. HARDWARE COMPLEMENTARIO

El microcontrolador en cuestión no implementa la
funcionalidad de reprogramación incluida en el origi-
nal. Esto no es un problema importante debido a que
las FPGAs son reconfigurables y por lo tanto basta con
volver a sintetizar el diseño para modificar el progra-
ma ejecutado por el microcontrolador. Es común que
los depuradores remotos puedan modificar el progra-
ma ejecutado por el sistema embebido por lo que pa-
ra complementar este desarrollo se diseñó un periférico
WISHBONE capaz de acceder a la memoria de pro-
grama del microcontrolador. Esto permitió reconfigu-
rar dicha memoria sin necesidad de reconfigurar toda

Fig. 1. Diagrama de conexiones de los bloques de har-
dware involucrados.

Fig. 2. Flujo de datos dentro de la computadora.

la FPGA.

La Fig. 1 ilustra la interconexión entre los distin-
tos componentes de hardware antes mencionados, los
bloques ilustrados con relleno sólido corresponden a los
desarrollos descriptos en este trabajo. En la Fig. 2 se
muestra el flujo de datos dentro de la computadora, los
datos ingresan a través del puerto paralelo utilizando
el protocolo EPP, son tomados por el sistema opera-
tivo (Linux) utilizando operaciones básicas de entra-
da/salida y enviados al espacio de usuario utilizando
el dispositivo ppdev, estos datos son procesados por el
programa depurador (icepic) y enviados a la interfaz de
usuario (SETEdit) utilizando el protocolo GDB/MI.

5. RESULTADOS

Nuestro desarrollo permite:

Detener/Reanudar la ejecución del microcontro-
lador en cualquier momento.

Ejecutar su programa paso a paso.

Detener la ejecución cuando se alcanzó una posi-
ción de memoria determinada, punto de parada o
breakpoint. La cantidad de breakpoints es confi-
gurable entre 1 y 256.

Reinicializar el microcontrolador.

Acceder a registros especiales tales como el acu-
mulador, el puntero de la pila y el contador de
programa.

Acceder a todos los registros de la memoria de
datos, incluyendo registros especiales tales como
el estado del microcontrolador.

Modificar cualquier registro, inclusive modificar
el contador de programa forzando un salto.

Inspeccionar la pila de llamadas (calling stack).

Detener la ejecución cuando se accede a una posi-
ción de memoria de datos, watchpoint. Los acce-
sos pueden seleccionarse para detenerse por lectu-
ra, escritura o ambos. El número de watchpoints
es configurable entre 1 y 256.

Alterar la memoria de programa.

Detectar desbordes en la pila y detener la ejecu-
ción cuando esto sucede.

El periférico insumió 16 direcciones de entrada sali-

da:

2 para selección de comando y lectura de resulta-
dos y/o estado.

4 para los breakpoints: 1 de selección, 2 de direc-
ción y otro de estado.

3 para acceder a los registros de memoria de da-
tos: dirección, banco y valor.

4 para inspeccionar y/o modificar el stacky el sta-
ckpointer.

3 para los watchpoints: 1 de selección, 1 de habi-
litación y modo y otro de dirección.

Fig. 3. Sesión de depuración.

CGW: leer el registro acumulador (W).

La Fig. 3 muestra una sesión de depuración utilizan-
do SETEdit. En la misma se observa el código fuente
del programa, el código desensamblado y una ventana
utilizada para monitorear el valor de una variable.

Este desarrollo fue verificado en hardware utilizando
FPGAs Spartan 3 de Xilinx. Para la síntesis se utilizó el
programa XST 8.2.02i (I.33).

El área ocupada depende de la cantidad de break-
points y watchpoints configurados, para el caso de tres
breakpoints y tres watchpoints se observó un uso de 186
slices. Esto incluye el periférico utilizado para modifi-
car la memoria de programa del microcontrolador, de
aproximadamente 32 slices, y el puente que conecta el
puerto paralelo de la PC con el bus WISHBONE, de
aproximadamente 31 slices. Esto corresponde al 9,7 %
de una Spartan 3 200 o bien sólo un 1,3 % de una Spar-
tan 3 1500.

Se requirió implementar 8 comandos para el control

6. CONCLUSIONES

del periférico:

STOP: detener la ejecución.

RUN: reanudar la ejecución.

STEP: ejecutar sólo un paso de programa.

RESET: reiniciar el microcontrolador.

FRESET: reiniciar todo el sistema.

GPCL: leer la parta baja del contador de progra-
ma.

GPCH: leer la parta alta