| Line 12... |
Line 12... |
%\usepackage{subfigure}
|
%\usepackage{subfigure}
|
\usepackage{float}
|
\usepackage{float}
|
\usepackage{fancyhdr}
|
\usepackage{fancyhdr}
|
\usepackage{caption}
|
\usepackage{caption}
|
\usepackage{subcaption}
|
\usepackage{subcaption}
|
|
\usepackage{amssymb}
|
\title{Plataforma de hardware recofigurable \\ \small{JTAG -- Configuración OOCD-Links, (\textsl{Hardware \& Software})}}
|
\title{Plataforma de hardware recofigurable \\ \small{JTAG -- Configuración OOCD-Links, (\textsl{Hardware \& Software})}}
|
\author{Luis A. Guanuco}
|
\author{Luis A. Guanuco}
|
\date{\today}
|
\date{\today}
|
\pagestyle{fancy}
|
\pagestyle{fancy}
|
\addtolength{\textheight}{2cm}
|
\addtolength{\textheight}{2cm}
|
| Line 24... |
Line 25... |
|
|
\begin{document}
|
\begin{document}
|
|
|
\maketitle{}
|
\maketitle{}
|
|
|
\chead{\includegraphics[width=0.1\textwidth]{images/logov2_ES}}
|
%\chead{\includegraphics[width=0.1\textwidth]{images/logov2_ES}}
|
%\begin{figure}[h]
|
\begin{figure}[h]
|
% \centering
|
\centering
|
% \includegraphics[width=0.3\textwidth]{images/logov2_ES}
|
\includegraphics[width=0.3\textwidth]{images/logov2_ES}
|
%\end{figure}
|
\end{figure}
|
|
|
\section{Introducción}
|
\section{Introducción}
|
\label{sec:intro}
|
\label{sec:intro}
|
|
|
Una gran parte del proyecto \emph{\ac{PHR}} se basa en la implementación de códigos de programación en diferentes lenguajes. En esta etapa
|
El presente reporte desarrolla la continuación del armado, testeo de las distintas placas que conformarán la \emph{\ac{PHR}}. Además, gran parte del informe se basa en el \textsl{software} que permitirá la comunicación entre la PC y el programador \ac{jtag}.
|
El presente reporte desarrolla la continuación del armado, testeo de las distintas placas que conformarán la \emph{\ac{PHR}}.Gran parte del informe se basa en el \textsl{software} que permitirá la comunicación entre la PC y el programador \ac{JTAG}.
|
|
|
|
\section{Programador \ac{JTAG}}
|
\section{Programador JTAG}
|
\label{sec:prog-jtag}
|
\label{sec:prog-jtag}
|
Gran parte de los \textsl{scripts} utilizados se obtuvieron del manual de usuario de \ac{OpenOCD} que se encuentra publicado en la web. Se recuerda que anteriormente al uso de \ac{OpenOCD}, se intentó utilizar el \textsl{software} Ur\ac{JTAG}, pero debido a la limitaciones que presentaba la versión estable, se optó por cambiarlo. Además existía mayor documentación de \ac{OpenOCD} que de UrJTAG.
|
Los \textsl{scripts} utilizados se obtuvieron del manual de usuario del \textsl{software} \ac{openocd} que se encuentra publicado en la web\footnote{http://openocd.sourceforge.net/doc/html/index.html}.
|
|
Anteriormente al uso de \ac{openocd} se intentó utilizar el \textsl{software} UrJTAG\footnote{http://urjtag.org/} pero debido a la limitaciones que presentaba la versión estable se lo descartó.
|
|
|
\subsection{\textsl{Software} \ac{OpenOCD}}
|
\subsection{\textsl{Software} \ac{openocd}}
|
\label{sec:soft-openocd}
|
\label{sec:soft-openocd}
|
En el proceso de lograr obtener el \textsl{software} funcional, se realizó un gran trabajo que se podría diferenciar en tres etapas:
|
La instalación y puesta en funcionamiento del \textsl{software} \ac{openocd} se realiza en tres etapas:
|
\begin{itemize}
|
\begin{itemize}
|
\item Instalación del \textsl{software} \ac{OpenOCD}
|
\item Instalación del \textsl{software} \ac{openocd}
|
\item \textsl{Interface}
|
\item \textsl{Interface}
|
\item \textsl{Target}
|
|
\end{itemize}
|
\end{itemize}
|
|
|
\subsubsection{Instalación del \textsl{software} \ac{OpenOCD}}
|
\subsubsection{Instalación del \textsl{software} \ac{openocd}}
|
Para la instalación se recurrió a la documentación del \textsl{software}. En dicho documento se hace referencia a los requerimientos para cada \ac{SO}. Como ya se mencionó en anteriormente reportes, se utilizará herramientas libres, por lo que se realizará la instalación en un \ac{SO} GNU/Linux Debian ``Squeeze'' 6.0.
|
Se recomienda descargar la última versión estable de \ac{openocd} y compilarlo manualmente con los correspondientes argumentos necesarios para el \textsl{driver} a utilizar. En nuestro caso utilizaremos el \textsl{driver} libftdi\footnote{http://www.intra2net.com/en/developer/libftdi/}. Además en la documentación oficial de \ac{openocd} se hace referencia a los requerimientos para cada \ac{SO}. Como ya se mencionó en anteriormente reportes, se utilizará herramientas libres, por lo que se realizará la instalación en un \ac{SO} GNU/Linux Debian ``Squeeze'' 6.0. Como así también los drivers para el \textsl{hardware} están licenciados como \ac{GPL}.
|
|
Un documento de referencia muy útil es la Nota Técnica \emph{Entorno de desarrollo de \textsl{firmware} sobre arquitecturas ARM Cortex-M3, basado en herramientas libres}\cite{2012-SSE-FIUBA-NT01-00}.
|
|
|
\subsubsection{\textsl{Interface}}
|
\subsubsection{\textsl{Interface}}
|
El \textsl{Interface} hace referencia al \textsl{hardware} que realiza el enlace entre el dispositivo que queremos programar y la PC. En éste caso el \textsl{interface} será nuestra placa OOCD-Links. \ac{OpenOCD} dispone de \textsl{scripts} para varios \textsl{interface} entre los cuales se encuentra nuestra placa programadora. La información que proporciona éste código hace a que tipo de driver se utilizará como así también identificación del dispositivo central. A continuación se puede ver la estructura del archivo \texttt{oocdlink.cfg}.
|
\textsl{Interface} hace referencia al \textsl{hardware} que realiza el enlace entre el puerto \ac{jtag} del dispositivo al que se quiere acceder y la PC. En éste caso el \textsl{interface} será nuestra placa OOCD-Links. \ac{openocd} dispone de \textsl{scripts} para varios \textsl{interface} entre los cuales se encuentra nuestra placa programadora. La información que proporciona éste código hace a que tipo de driver se utilizará como así también identificación del dispositivo central. A continuación se puede ver la estructura del archivo \texttt{oocdlink.cfg}.
|
|
|
\begin{verbatim}
|
\begin{verbatim}
|
#
|
#
|
# Joern Kaipf's OOCDLink
|
# Joern Kaipf's OOCDLink
|
#
|
#
|
# http://www.joernonline.de/contrexx2/cms/index.php?page=126
|
# http://www.joernonline.de/contrexx2/cms/index.php?page=126
|
| Line 68... |
Line 70... |
ft2232_layout oocdlink
|
ft2232_layout oocdlink
|
ft2232_vid_pid 0x0403 0xbaf8
|
ft2232_vid_pid 0x0403 0xbaf8
|
jtag_khz 5
|
jtag_khz 5
|
\end{verbatim}
|
\end{verbatim}
|
|
|
\subsubsection{\textsl{Target}}
|
Para obtener el VIP (vendor ID) y el PID (product ID) se lo puede obtener una vez conectada el \textsl{interface} a la PC y listando los dispositivos conectados al puerto USB, por ejemplo,
|
\textsl{Target} define las especificaciones del \textsl{hardware} al cual queremos acceder con el \textsl{interface} OOCD-Links. Al igual que con los \textsl{interfaces}, \ac{OpenOCD} dispone de \textsl{scripts} con varias \textsl{targets} conocidas. En nuestro caso vamos a utilizar éstos archivos como ejemplo para configurar y adaptar a nuestra placa de prueba. Por último se probará agregar varios dispositivos al archivo que se generé y poder programarlos a la vez con la placa OOCD-Links.
|
|
|
\begin{verbatim}
|
|
luis@luis-laptop:openocd$ lsusb
|
|
Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
|
|
Bus 006 Device 002: ID 0403:6010 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
|
|
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
|
|
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
|
|
Bus 001 Device 002: ID 0bda:0158 Realtek Semiconductor Corp. USB 2.0 multicard reader
|
|
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
|
|
\end{verbatim}
|
|
|
|
En la salida del \texttt{lsusb} se puede ver que tenemos el dispositivo \emph{0403:6001 Future Technology Device International}. Luego utilizamos éste dato para modificar o crear nuestro archivo \texttt{openocd.cfg} que será argumento de \ac{openocd}.
|
|
|
\subsection{Documentación de comandos y \textsl{scripts}}
|
\subsection{Documentación de comandos y \textsl{scripts}}
|
Luego de la configuración del \textsl{software} \ac{OpenOCD}, se procede a generar código de programa que nos permita realizar las tareas que necesitamos para nuestros proyecto \emph{\ac{PHR}}.
|
Una vez que se logra comunicar el \textsl{interface} \ac{jtag} con el \textsl{software} \ac{openocd}, se crean los archivos necesarios para acceder a los dispositivos que se encuentren conectados en el protocolo \ac{jtag}.
|
En principio se agregarán comandos útiles que servirán en general para cualquier dispositivo. Entre ellos se puede destacar,
|
Para correr \ac{openocd} correctamente se necesita pasarle algunos simples argumentos,
|
|
\begin{verbatim}
|
|
luis@luis-laptop:trunk$ openocd -h
|
|
Open On-Chip Debugger 0.6.1 (2012-12-08-02:21)
|
|
Licensed under GNU GPL v2
|
|
For bug reports, read
|
|
http://openocd.sourceforge.net/doc/doxygen/bugs.html
|
|
Open On-Chip Debugger
|
|
Licensed under GNU GPL v2
|
|
--help | -h display this help
|
|
--version | -v display OpenOCD version
|
|
--file | -f use configuration file <name>
|
|
--search | -s dir to search for config files and scripts
|
|
--debug | -d set debug level <0-3>
|
|
--log_output | -l redirect log output to file <name>
|
|
--command | -c run <command>
|
|
\end{verbatim}
|
|
|
|
Los más importantes de éstos son \texttt{--file}, que permite definir que archivo de configuración \ac{openocd} utilizará. Dentro de éste archivo se podría agregar cualquiera de los otros comandos.
|
|
Es recomendable que la estructura de archivos sea la siguiente,
|
\begin{itemize}
|
\begin{itemize}
|
\item Identificar información de un dispositivo sin datos del proveedor, para agregarlo a una cadena \ac{JTAG} como \ac{TAP}.
|
\item Directorio raíz de trabajo (por ej.: \texttt{openocd\_dir})
|
\item Configurar dispositivo en modo \textsl{halt}.
|
\begin{itemize}
|
|
\item [$\rightarrow$] \texttt{core.cfg}, contiene los comandos básicos para que \ac{openocd} reconozca el \textsl{interface}
|
|
\item [$\rightarrow$] \texttt{openocd.cfg}, contiene los comandos que configura el acceso al protocolo \ac{jtag}
|
|
\item [$\rightarrow$] \texttt{device.cfg}, contiene los comandos propios de los dispositivos a conectar en la cadena \ac{jtag}, por ejemplo ID, cantidad de bits de los registros, etc.
|
|
\item [$\rightarrow$] \texttt{files/...}, también se debe conciderar tener un subdirectorio en el cual almacenar archivos que se transerirán a los dispositivos mediante \ac{jtag}, por ejemplo: archivos .svf, archivos .elf, etc.
|
|
\end{itemize}
|
\end{itemize}
|
\end{itemize}
|
|
|
\subsubsection{Agregar \ac{TAP}}
|
A continuación se describen comandos útiles que se pueden aplicar en forma general a cualquier dispositivo a conectar.
|
Para acceder a un dispositivo mediante el protocolo \ac{JTAG}, se debe proporcionar información del \textsl{hardware} al \textsl{interface}. Muchas veces ésta información no se encuentra fácil de acceder en la hoja de datos de dichos dispositivos por lo que \ac{OpenOCD} dispone de un modo \textsl{Autoprobing}, para más información sobre éste modo se puede obtener del Manual de Usuario de \ac{OpenOCD} en la sección 10.7 Autoprobing.
|
|
En definitiva, para capturar la información del dispositivo conectado se debe generar una archivo \texttt{openocd.cfg} base como el que se muestra a continuación,
|
\subsubsection{Agregar un \ac{TAP}}
|
|
Para acceder a un dispositivo mediante el protocolo \ac{jtag}, se debe proporcionar especificaciones del mismo. Muchas veces ésta información no se encuentra fácil de acceder en la hoja de datos de los dispositivos conectados al \textsl{interface}. Para situaciones como la descrita, \ac{openocd} dispone de un modo llamado \textsl{Autoprobing}\cite{openocd-manual-autoprobing}.
|
|
|
|
En definitiva, para capturar la información del dispositivo conectado se debe generar una archivo base \texttt{openocd.cfg} como el que se muestra a continuación,
|
\begin{verbatim}
|
\begin{verbatim}
|
# OpenOCD configuration script
|
# OpenOCD configuration script
|
# 2013-03-25 lguanuco
|
# 2013-03-25 lguanuco
|
# Hardware:
|
# Hardware:
|
# - OOCD-Link-s
|
# - OOCD-Link-s
|
| Line 100... |
Line 140... |
# 3. Other configs
|
# 3. Other configs
|
|
|
reset_config trst_and_srst
|
reset_config trst_and_srst
|
jtag_rclk 8
|
jtag_rclk 8
|
\end{verbatim}
|
\end{verbatim}
|
Luego de correr \ac{OpenOCD}, se debe acceder al archivo de salida con el nombre que se asignó en el archivo \texttt{openocd.cfg}, \texttt{out.log}. Este archivo registra todos los mensajes de salida que genera \ac{OpenOCD}, a continuación se muestra parte de éste archivo donde se puede observar información útil para generar el \ac{TAP} de dicho dispositivo.
|
Luego de correr \ac{openocd}, se debe acceder al archivo de salida con el nombre que se asignó en el archivo \texttt{openocd.cfg}, \texttt{out.log}. Este archivo registra todos los mensajes de salida que genera \ac{openocd}, a continuación se muestra parte de éste archivo donde se puede observar información útil para generar el \ac{TAP} de dicho dispositivo.
|
\begin{verbatim}
|
\begin{verbatim}
|
...
|
...
|
Debug: 129 273 core.c:323 jtag_call_event_callbacks(): jtag event: TAP reset
|
Debug: 129 273 core.c:323 jtag_call_event_callbacks(): jtag event: TAP reset
|
Warn : 130 359 core.c:1145 jtag_examine_chain(): AUTO auto0.tap - use "jtag newtap auto0 tap -expected-id 0x4f1f0f0f ..."
|
Warn : 130 359 core.c:1145 jtag_examine_chain(): AUTO auto0.tap - use "jtag newtap auto0 tap -expected-id 0x4f1f0f0f ..."
|
Debug: 131 359 core.c:1323 jtag_tap_init(): Created Tap: auto0.tap @ abs position 0, irlen 0, capture: 0x1 mask: 0x3
|
Debug: 131 359 core.c:1323 jtag_tap_init(): Created Tap: auto0.tap @ abs position 0, irlen 0, capture: 0x1 mask: 0x3
|
| Line 121... |
Line 161... |
\item \emph{irlen}
|
\item \emph{irlen}
|
\item \emph{capture}
|
\item \emph{capture}
|
\item \emph{mask}
|
\item \emph{mask}
|
\end{itemize}
|
\end{itemize}
|
|
|
\subsubsection{Modo \textsl{Halt}}
|
Por lo tanto, con estos datos se puede generar nuestro propio \textsl{script} en el cual agregar manualmente el \ac{TAP}, por ejemplo \texttt{lpc2124.cfg}
|
El modo \textsl{halt}, permite congelar al dispositivo tanto para agregar \textsl{breakpoints} como también programar el dispositivo. Un problema común es que dicho modo no puede ser aplicado, para solucionar ésto es necesario realizar un \textsl{reset}, con el comando \texttt{reset halt}. Luego de esto se puede pasar al modo \textsl{halt} sin problemas.
|
\begin{verbatim}
|
|
jtag newtap arm_lpc2124 tap -irlen 4 -ircapture 0x01 -irmask 0x3 -expected-id 0x4f1f0f0f
|
|
\end{verbatim}
|
|
|
|
\subsubsection{Multiples \ac{TAP}}
|
|
Muchas plataformas o kits de desarrollo tienen multiples TAPs. Por ejemplo, en nuestro caso tenemos conectados dos dispositivos a la cadena \ac{jtag} que son la \ac{FPGA} y la memoria \ac{PROM} de programación del mismo. Si la conexión es tal que,
|
|
|
|
\begin{itemize}
|
|
\item OpenOCD TDI(output) $\rightarrow$ XC3S50A pin TDI(BS input).
|
|
\item XC3S50A pin TDO(BS input) $\rightarrow$ XCF01S pin TDI.
|
|
\item XCF01S pin TDO(BS output) $\rightarrow$ OpenOCD TDO(input).
|
|
\end{itemize}
|
|
|
|
Los comandos para agregar éstos TAPs deberán respetar él orden con el que fueron conectados físicamente,
|
|
|
|
\begin{verbatim}
|
|
...
|
|
jtag newtap xcf01s tap -irlen ...
|
|
jtag newtap xc3s50a tap -irlen ...
|
|
...
|
|
\end{verbatim}
|
|
|
|
Es decir, se agrega los TAPs recorriendo la cadena JTAG desde el pin TDO al pin TDI desde el interface, aquí sería desde la placa OOCDLink.
|
|
|
\subsubsection{Programación \ac{CPLD}}
|
\subsubsection{Programación \ac{CPLD}}
|
Para los \ac{CPLD}, primero se debe tener el archivo \ac{SVF}, que es generado por la herramienta con la que se diseña y sintetiza el código VHDL o Verilog. En éste caso se utiliza el \textsl{software} ISE Xilinx. Una vez que se tiene el archivo \ac{SVF}, desde \ac{OpenOCD}, se corre el siguiente comando;
|
Para los \ac{CPLD}, primero se debe tener el archivo \ac{SVF}, que es generado por la herramienta con la que se diseña y sintetiza el código VHDL o Verilog. En éste caso se utiliza el \textsl{software} ISE Xilinx. Una vez que se tiene el archivo \ac{SVF}, desde \ac{openocd}, se corre el siguiente comando;
|
\begin{verbatim}
|
\begin{verbatim}
|
svf {file.svf} quiet
|
svf -tap tap_name file.svf quiet
|
\end{verbatim}
|
\end{verbatim}
|
Lo que generaría una salida como la que sigue,
|
Lo que generaría una salida como la que sigue,
|
\begin{verbatim}
|
\begin{verbatim}
|
svf processing file: "file.svf"
|
svf processing file: "file.svf"
|
500 kHz
|
500 kHz
|
|
...
|
|
...
|
Time used: 0m7s478ms
|
Time used: 0m7s478ms
|
svf file programmed successfully for 8468 commands
|
svf file programmed successfully for 8468 commands
|
\end{verbatim}
|
\end{verbatim}
|
|
|
En el caso de que se tenga problemas en la transferencia del archivo, se podría probar bajando la frecuencia de la comunicación \ac{JTAG}. Recordar que esto quizá se deba cambiar también desde el entorno ISE Xilinx.
|
En el caso de que se tenga problemas en la transferencia del archivo, se podría probar bajando la frecuencia de la comunicación \ac{jtag}.
|
|
|
|
Algo interesante se puede observar en el archivo \texttt{file.svf}, pues en una de sus lineas tiene el IDCODE del dispositivo al que se va a transferir, que debería coincidir con el que se le pasa cuando se agrega el \ac{TAP} al código de \ac{openocd}. O quizá diferenciarse con el valor hexadecimal más significativo, que indica la versión del dispositivo.
|
|
|
Algo interesante se puede observar en el archivo \texttt{fiel.svf}, pues en una de sus lineas tiene el IDCODE del dispositivo al que se va a transferir, que debería coincidir con el que se le pasa cuando se agrega el \ac{TAP} al código de \ac{OpenOCD}.
|
|
\begin{verbatim}
|
\begin{verbatim}
|
...
|
...
|
//Loading device with 'idcode' instruction.
|
//Loading device with 'idcode' instruction.
|
SIR 8 TDI (fe) SMASK (ff) ;
|
SIR 8 TDI (fe) SMASK (ff) ;
|
SDR 32 TDI (00000000) SMASK (ffffffff) TDO (f9604093) MASK (0fffffff) ;
|
SDR 32 TDI (00000000) SMASK (ffffffff) TDO (f9604093) MASK (0fffffff) ;
|
| Line 153... |
Line 217... |
//Boundary Scan Chain Contents
|
//Boundary Scan Chain Contents
|
//Position 1: xc9572xl
|
//Position 1: xc9572xl
|
...
|
...
|
\end{verbatim}
|
\end{verbatim}
|
|
|
En la conexión de los puertos \ac{JTAG}, hemos encontrado un problema y es el nivel de tensión que maneja éstos pines con respecto a los de la placa OOCD-Links.
|
La placa OOCD-Links cuenta con un dispositivo central, FT2232D. Éste dispositivo posee dos alimentaciones, por una parte la alimentación de núcleo del circuito integrado y por otro lado la alimentación de los interfaces de salida. La primera alimentación es tomada desde el puerto USB al que se encuentra conectado, mientas que la alimentación de sus puertos de conexión lo toma del conector \ac{jtag}, del \emph{Pin 1}. De tal manera que la tensión de los puertos de conexión \ac{jtag} del \textsl{interface} siempre tiene la misma tensión que maneja las señales \ac{jtag} de la placa conectada. Es decir, si se hace una conexión entre la placa OOCD-Links y una placa con un CPLD XC9572XL, ambas tendrán la misma tensión en sus puertos \ac{jtag}, en éste caso 3.3V.
|
La placa OOCD-Links cuenta con un dispositivo central, FT2232D. Éste dispositivo posee dos alimentaciones, por una parte la alimentación de núcleo del circuito integrado y por otro lado la alimentación de los \textsl{interfaces} de salida. La primera alimentación es tomada desde el puerto USB al que se encuentra conectado, mientas que la alimentación de sus puertos de conexión lo toma del conector \emph{P1}. Éste último debería tener el mismo nivel de tensión que la placa con la que se conecte. Es decir, si se hace una conexión entre la placa OOCD-Links y una placa con un CPLD XC9572XL, se debería asegurar que ambas tengan la misma tensión en sus puertos \ac{JTAG}, en éste caso 3.3V.
|
|
Una solución transitoria a éste problema sería proporcionar la alimentación de los \textsl{interfaces} de la placa OCD-Links desde el puerto de alimentación de la placa CPLD. La placa OT-CPLD posee los puertos de alimentación, regulado a 3.3V, como salida en sus pines de conexión \emph{P1} y \emph{P2}. El principal inconveniente que se podría encontrar es el consumo de corriente. Pues el regulador de la placa OT-CPLD se tendría que proporcionar energía a la placa OOCD-Links, pero como es en el proceso de programación y como proceso de testeo, no debería haber inconvenientes.
|
|
|
|
Otra posible solución sería implementar los puertos de \ac{JTAG} como lo tiene la placa ARM de ĺa Cátedra Técnicas Digitales II. Al parecer presenta solo unos resistores pullup a la salida de los pines que van al conector \ac{JTAG}.
|
Un inconveniente podría ser el consumo de corriente, pues el regulador de la placa OT-CPLD se tendría que proporcionar energía a la placa OOCD-Links, pero como es en el proceso de programación y como proceso de testeo, no debería haber inconvenientes. Igualmente se debe tener en cuenta.
|
|
|
Se investiga la posibilidad de que el problema de la placa OT-CPLD sea la falta de resistores pull-up en los puertos \ac{JTAG}; TDI, TDO, TMS, TCK.
|
|
|
|
Se encontró en la nota de aplicación de Xilinx [\emph{ug445.pdf}] que para los pines TDI y TMS de los CPLD XC9572XL, se dispone de resistores \textsl{pull-ups} internos. Por lo que no es necesario colocar resistores externos en el diseño del PCB.
|
Se encontró en la nota de aplicación de Xilinx [\emph{ug445.pdf}] que para los pines TDI y TMS de los CPLD XC9572XL, se dispone de resistores \textsl{pull-ups} internos. Por lo que no es necesario colocar resistores externos en el diseño del PCB.
|
|
|
|
\subsection{\textsl{Debugging}}
|
|
Para el \textsl{debugging} se utiliza varias herramientas y todas ellas corren sobre terminales \textsl{bash} de nuestro \ac{SO}. Entre éstos \textsl{software}, tenemos
|
|
\begin{itemize}
|
|
\item \emph{terminator}, múltiples terminales en una sola ventana (escritorio GNOME).
|
|
\item \emph{tailf}, sigue la escritura de un archivo( por ej.: archivos de .log).
|
|
\item \emph{ccze}, un robusto visor de archivos log con la posibilidad de colorear las líneas.
|
|
\item \emph{grep}, imprime las líneas similares a un patrón.
|
|
\end{itemize}
|
|
|
|
Todos éstos comandos son utilizados a la vez. La forma de trabajo es correr \emph{terminator} y luego dividir la pantalla en varios terminales al vez, eso será útil para ingresar comandos al puerto telnet 4444 donde se puede acceder al \textsl{interface} \ac{jtag}. Los otros \textsl{software} se utilizar a modo de \textsl{debugger}, pues nos permiten resaltar mensajes que genera \ac{openocd}. Por ejemplo, una forma estándar de ver la salida es,
|
|
|
|
\begin{verbatim}
|
|
luis@luis-laptop:~$ tailf codigo/jtag/openocd/find_tap/out.log | ccze -A -o scroll
|
|
\end{verbatim}
|
|
|
|
También se podría utilizar \emph{grep} para filtrar o diferenciar las líenas en función si son \emph{\textsl{Error, Warning, Debug \& User}}.
|
|
|
\section{Documentación}
|
\section{Documentación}
|
La documentación resulta fundamental en ésta etapa del desarrollo. Si bien se quiere lograr el correcto funcionamiento de las placas, la documentación sirve para realizar correciones a las versiones futuras de cada placa. Otro objetivo es documentar el funcionamiento de cada dispositivo que sirvan al reporte final como así también a los usuarios de la \emph{Plataforma de Hardware Reconfigurable}.
|
La documentación resulta fundamental en ésta etapa del desarrollo. Si bien se quiere lograr el correcto funcionamiento de las placas, la documentación sirve para realizar correciones a las versiones futuras de cada placa. Otro objetivo es documentar el funcionamiento de cada dispositivo que sirvan al reporte final como así también a los usuarios de la \emph{Plataforma de Hardware Reconfigurable}.
|
|
|
|
\begin{thebibliography}{}
|
|
\bibitem{2012-SSE-FIUBA-NT01-00} Sebastián García, ``Entorno de desarrollo de firmware sobre arquitectura ARM Cortex-M3, basado en herramientas libres'', 31 de Julio del 2013, Versión 0
|
|
\bibitem{openocd-manual-autoprobing} \ac{openocd}, ``\ac{openocd} User's Guide'', 25 de Noviembre del 2012, 10.7~Autoprobing, 58~p., Versión 0.7.0-dev
|
|
\end{thebibliography}
|
|
|
\newpage{}
|
\newpage{}
|
|
|
\appendix{}
|
\appendix{}
|
|
|
\section{Acrónimos}
|
\section{Acrónimos}
|
\begin{acronym}
|
\begin{acronym}
|
\acro{PHR}[PHR]{Plataforma de Hardware Reconfigurable}
|
\acro{PHR}[PHR]{Plataforma de Hardware Reconfigurable}
|
\acro{OpenOCD}[OpenOCD]{Open On-Chip Debugger}
|
\acro{openocd}[OpenOCD]{\textsl{Open On-Chip Debugger}}
|
\acro{JTAG}[JTAG]{Joint Test Action Group}
|
\acro{jtag}[JTAG]{\textsl{Joint Test Action Group}}
|
\acro{TAP}[TAP]{Test Access Port}
|
\acro{TAP}[TAP]{\textsl{Test Access Port}}
|
\acro{SVF}[SVF]{Serial Vector Format}
|
\acro{SVF}[SVF]{\textsl{Serial Vector Format}}
|
\acro{CPLD}[CPLD]{Complex Programmable Logical Device}
|
\acro{CPLD}[CPLD]{\textsl{Complex Programmable Logical Device}}
|
|
\acro{FPGA}[FPGA]{\textsl{Field Programmable Gate Array}}
|
|
\acro{PROM}[PROM]{\textsl{Programmable Read-Only Memory}}
|
\acro{SO}[SO]{sistema operativo}
|
\acro{SO}[SO]{sistema operativo}
|
|
\acro{GPL}[GPL]{\textsl{General Public License}}
|
\acro{UTN-FRC}{Universidad Tecnológica Nacional -- Facultad Regional Córdoba}
|
\acro{UTN-FRC}{Universidad Tecnológica Nacional -- Facultad Regional Córdoba}
|
\end{acronym}
|
\end{acronym}
|
|
|
\section{Repositorio de proyecto}
|
\section{Repositorio de proyecto}
|
|
|
