sergiotarxz/nuttx
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Add buildroot support for binutils-2.22 and gcc-4.6.3; all buildroot tools are not called abc-nuttx-elf instead of abc-elf

Browse Source 
git-svn-id: svn://svn.code.sf.net/p/nuttx/code/trunk@5213 42af7a65-404d-4744-a932-0658087f49c3
This commit is contained in:
patacongo 2012-10-05 23:01:51 +00:00
parent 8fbd2c4b22
commit 906b527dec
6 changed files with 362 additions and 361 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

34
Documentation/NuttX.html
View File

@ -1309,7 +1309,7 @@ svn checkout -r5206 http://svn.code.sf.net/p/nuttx/code/trunk nuttx-code
<b>TI TMS320C5471</b> (also called <b>C5471</b> or <b>TMS320DA180</b> or <b>DA180</b>).
NuttX operates on the ARM7 of this dual core processor.
This port uses the <a href="http://www.spectrumdigital.com/">Spectrum Digital</a>
evaluation board with a GNU arm-elf toolchain* under Linux or Cygwin.
evaluation board with a GNU arm-nuttx-elf toolchain* under Linux or Cygwin.
</p>
<ul>
<p>
@ -1352,7 +1352,7 @@ svn checkout -r5206 http://svn.code.sf.net/p/nuttx/code/trunk nuttx-code
<b>NXP LPC214x</b>.
Support is provided for the NXP LPC214x family of processors. In particular,
support is provided for the mcu123.com lpc214x evaluation board (LPC2148).
This port also used the GNU arm-elf toolchain* under Linux or Cygwin.
This port also used the GNU arm-nuttx-elf toolchain* under Linux or Cygwin.
</p>
<ul>
<p>
@ -1386,7 +1386,7 @@ svn checkout -r5206 http://svn.code.sf.net/p/nuttx/code/trunk nuttx-code
Support is provided for the NXP LPC2378 MCU. In particular,
support is provided for the Olimex-LPC2378 development board.
This port was contributed by Rommel Marcelo is was first released in NuttX-5.3.
This port also used the GNU arm-elf toolchain* under Linux or Cygwin.
This port also used the GNU arm-nuttx-elf toolchain* under Linux or Cygwin.
</p>
<ul>
<p>
@ -1413,7 +1413,7 @@ svn checkout -r5206 http://svn.code.sf.net/p/nuttx/code/trunk nuttx-code
<b>STMicro STR71x</b>.
Support is provided for the STMicro STR71x family of processors. In particular,
support is provided for the Olimex STR-P711 evaluation board.
This port also used the GNU arm-elf toolchain* under Linux or Cygwin.
This port also used the GNU arm-nuttx-elf toolchain* under Linux or Cygwin.
</p>
<ul>
<p>
@ -1450,7 +1450,7 @@ svn checkout -r5206 http://svn.code.sf.net/p/nuttx/code/trunk nuttx-code
<td>
<p>
<b>Freescale MC9328MX1</b> or <b>i.MX1</b>.
This port uses the Freescale MX1ADS development board with a GNU arm-elf toolchain*
This port uses the Freescale MX1ADS development board with a GNU arm-nuttx-elf toolchain*
under either Linux or Cygwin.
</p>
<ul>
@ -1476,7 +1476,7 @@ svn checkout -r5206 http://svn.code.sf.net/p/nuttx/code/trunk nuttx-code
NuttX operates on the ARM9 of this dual core processor.
This port uses the
<a href="http://wiki.neurostechnology.com/index.php/Developer_Welcome">Neuros OSD</a>
with a GNU arm-elf toolchain* under Linux or Cygwin.
with a GNU arm-nuttx-elf toolchain* under Linux or Cygwin.
The port was performed using the OSD v1.0, development board.
</p>
<ul>
@ -1498,7 +1498,7 @@ svn checkout -r5206 http://svn.code.sf.net/p/nuttx/code/trunk nuttx-code
<td>
<b>NXP <a href="http://ics.nxp.com/products/lpc3000/lpc313x.lpc314x.lpc315x/">LPC3131</a></b>.
The port for the NXP LPC3131 on the <a href="http://www.embeddedartists.com/products/kits/lpc3131_kit.php">Embedded Artists EA3131</a>
development board was first released in NuttX-5.1 with a GNU arm-elf or arm-eabi toolchain* under Linux or Cygwin
development board was first released in NuttX-5.1 with a GNU arm-nuttx-elf or arm-eabi toolchain* under Linux or Cygwin
(but was not functional until NuttX-5.2).
</p>
<ul>
@ -1571,7 +1571,7 @@ svn checkout -r5206 http://svn.code.sf.net/p/nuttx/code/trunk nuttx-code
<p>
<b>Luminary/TI Stellaris LM3S6918</b>.
This port uses the <a href=" http://www.micromint.com/">Micromint</a> Eagle-100 development
board with a GNU arm-elf toolchain* under either Linux or Cygwin.
board with a GNU arm-nuttx-elf toolchain* under either Linux or Cygwin.
</p>
<ul>
<p>
@ -1601,7 +1601,7 @@ svn checkout -r5206 http://svn.code.sf.net/p/nuttx/code/trunk nuttx-code
<td>
<p>
<b>Luminary/TI Stellaris LM3S6965</b>.
This port uses the Stellaris LM3S6965 Ethernet Evalution Kit with a GNU arm-elf toolchain*
This port uses the Stellaris LM3S6965 Ethernet Evalution Kit with a GNU arm-nuttx-elf toolchain*
under either Linux or Cygwin.
</p>
<ul>
@ -1635,7 +1635,7 @@ svn checkout -r5206 http://svn.code.sf.net/p/nuttx/code/trunk nuttx-code
<td>
<p>
<b>Luminary/TI Stellaris LM3S8962</b>.
This port uses the Stellaris EKC-LM3S8962 Ethernet+CAN Evalution Kit with a GNU arm-elf toolchain*
This port uses the Stellaris EKC-LM3S8962 Ethernet+CAN Evalution Kit with a GNU arm-nuttx-elf toolchain*
under either Linux or Cygwin.
Contributed by Larry Arnold.
</p>
@ -1733,7 +1733,7 @@ svn checkout -r5206 http://svn.code.sf.net/p/nuttx/code/trunk nuttx-code
</li>
</ol>
<p>
These ports uses a GNU arm-elf toolchain* under either Linux or Cygwin (with native Windows GNU
These ports uses a GNU arm-nuttx-elf toolchain* under either Linux or Cygwin (with native Windows GNU
tools or Cygwin-based GNU tools).
</p>
<ul>
@ -1842,7 +1842,7 @@ svn checkout -r5206 http://svn.code.sf.net/p/nuttx/code/trunk nuttx-code
<b>Atmel AT91SAM3U</b>.
This port uses the <a href="http://www.atmel.com/">Atmel</a> SAM3U-EK
development board that features the AT91SAM3U4E MCU.
This port uses a GNU arm-elf or arm-eabi toolchain* under either Linux or Cygwin (with native Windows GNU
This port uses a GNU arm-nuttx-elf or arm-eabi toolchain* under either Linux or Cygwin (with native Windows GNU
tools or Cygwin-based GNU tools).
</p>
<ul>
@ -1905,7 +1905,7 @@ svn checkout -r5206 http://svn.code.sf.net/p/nuttx/code/trunk nuttx-code
<p>
The Nucleus 2G board, the mbed board, and the LPCXpresso all feature the NXP LPC1768 MCU;
the Olimex LPC1766-STK board features an LPC1766.
All use a GNU arm-elf or arm-eabi toolchain* under either Linux or Cygwin (with native Windows GNU tools or Cygwin-based GNU tools).
All use a GNU arm-nuttx-elf or arm-eabi toolchain* under either Linux or Cygwin (with native Windows GNU tools or Cygwin-based GNU tools).
</p>
<ul>
<p>
@ -2386,7 +2386,7 @@ svn checkout -r5206 http://svn.code.sf.net/p/nuttx/code/trunk nuttx-code
</li>
</ul>
<p>
Both use a GNU arm-elf toolchain* under Linux or Cygwin.
Both use a GNU arm-nuttx-elf toolchain* under Linux or Cygwin.
The NuttX <a href="http://sourceforge.net/projects/nuttx/files/buildroot/">buildroot</a> provides a properly patched GCC 3.4.4 toolchain that is highly optimized for the m9s12x family.
</p>
<ul>
@ -2696,10 +2696,10 @@ svn checkout -r5206 http://svn.code.sf.net/p/nuttx/code/trunk nuttx-code
<b>STATUS:</b>
Initial source files released in nuttx-0.4.2.
At this point, the port has not been integrated; the target cannot be built
because the GNU <code>m16c-elf-ld</code> link fails with the following message:
because the GNU <code>m16c-nuttx-elf-ld</code> link fails with the following message:
</p>
<ul>
<code>m32c-elf-ld: BFD (GNU Binutils) 2.19 assertion fail /home/Owner/projects/nuttx/buildroot/toolchain_build_m32c/binutils-2.19/bfd/elf32-m32c.c:482</code>
<code>m32c-nuttx-elf-ld: BFD (GNU Binutils) 2.19 assertion fail /home/Owner/projects/nuttx/buildroot/toolchain_build_m32c/binutils-2.19/bfd/elf32-m32c.c:482</code>
</ul>
<p>Where the reference line is:</p>
<ul><pre>
@ -3583,7 +3583,7 @@ buildroot-1.10 2011-05-06 &lt;gnutt@nuttx.org&gt;
i486 ELF binaries. But that will not work under Cygwin! The Cygwin
toolchain (and probably MinGW), build DOS MZ format executables (i.e.,
.exe files). That is probably not usable for most NuttX targets.
Instead, you should use this i486-elf-gcc to generate true ELF binaries
Instead, you should use this i486-nuttx-elf-gcc to generate true ELF binaries
under Cygwin.
* Makefile - Alter copy arguments to avoid permissions problems when
copying NuttX header files.

1
Documentation/NuttXLinks.html
View File

@ -22,6 +22,7 @@
<li><a href="http://sourceforge.net/projects/nuttx/develop" target="_top">SourceForge</a></li>
<li><a href="http://freshmeat.net/projects/nuttx/" target="_top">FreshMeat</a></li>
<li><a href="http://tech.groups.yahoo.com/group/nuttx/" target="_top">Forum</a></li>
<li><a href="https://www.ohloh.net/p/nuttx" target="_top">Ohloh</a></li>
<li><a href="http://www.oschina.net/p/nuttx" target="_top">OSChina</a></li>
<li><a href="http://sourceforge.net/projects/nuttx/files/" target="_top">Downloads</a></li>
<li><a href="http://www.nx-engineering.com/nuttx-wiki/" target="_top">Wiki</a></li>

4
Documentation/NuttXNxFlat.html
View File

@ -443,7 +443,7 @@ cat ../syscall/syscall.csv ../lib/lib.csv | sort >tmp.csv
<tr>
<td><br></td>
<td><br></td>
<td><code>abc-elf-ld -r -d -warn-common -o $@ $^</code></td>
<td><code>abc-nuttx-elf-ld -r -d -warn-common -o $@ $^</code></td>
</tr>
<tr>
<th>Target 2</th>
@ -464,7 +464,7 @@ cat ../syscall/syscall.csv ../lib/lib.csv | sort >tmp.csv
<td><br></td>
<td><br></td>
<td>
<code>abc-elf-ld -r -d -warn-common -T binfmt/libnxflat/gnu-nxflat.ld -no-check-sections -o $@ hello.o hello-thunk.o</code>
<code>abc-nuttx-elf-ld -r -d -warn-common -T binfmt/libnxflat/gnu-nxflat.ld -no-check-sections -o $@ hello.o hello-thunk.o</code>
</td>
</tr>
<tr>

2
Documentation/NuttXRelated.html
View File

@ -41,7 +41,7 @@
<li><a href="http://osmocom.org/" target="top">Osmocom-BB</a></li>
<li><a href="https://pixhawk.ethz.ch/px4/" target="top">PX4 Autopilot</a></li>
<li><a href="http://rgmp.sourceforge.net/wiki/index.php/Main_Page" target="top">RGMP</a></li>
<li><a href="http://code.google.com/p/tmr/" target="top">Top Multi-Rotor (TMR)</a></li>
<li><a href="http://sourceforge.net/projects/tmr-fc/" target="top">Top Multi-Rotor (TMR)</a></li>
</tr>
<tr>
<td align="center" valign="top" width="22">

18
Documentation/NuttxPortingGuide.html
View File

@ -768,7 +768,7 @@
This is a port to the Spectrum Digital C5471 evaluation board. The
C5471 is a dual core processor from TI with an ARM7TDMI general purpose
processor and a c54 DSP. It is also known as TMS320DA180 or just DA180.
NuttX runs on the ARM core and is built with with a GNU arm-elf toolchain
NuttX runs on the ARM core and is built with with a GNU arm-nuttx-elf toolchain
under Linux or Cygwin. This port is complete and verified.
</li>
@ -780,14 +780,14 @@
<li><code>configs/ea3131</code>:
Embedded Artists EA3131 Development bard. This board is based on the
an NXP LPC3131 MCU. This OS is built with the arm-elf toolchain.
an NXP LPC3131 MCU. This OS is built with the arm-nuttx-elf toolchain.
STATUS: This port is complete and mature.
</li>
<li><code>configs/eagle100</code>:
Micromint Eagle-100 Development board. This board is based on the
an ARM Cortex-M3 MCU, the Luminary LM3S6918. This OS is built with the
arm-elf toolchain. STATUS: This port is complete and mature.
arm-nuttx-elf toolchain. STATUS: This port is complete and mature.
</li>
<li><code>configs/ez80f0910200kitg</code>
@ -805,7 +805,7 @@
<li><code>configs/lm3s6965-ek</code>:
Stellaris LM3S6965 Evaluation Kit. This board is based on the
an ARM Cortex-M3 MCU, the Luminary/TI LM3S6965. This OS is built with the
arm-elf toolchain. STATUS: This port is complete and mature.
arm-nuttx-elf toolchain. STATUS: This port is complete and mature.
</li>
<li><code>configs/lm3s8962-ek</code>:
@ -827,13 +827,13 @@
<li><code>configs/mbed</code>:
The configurations in this directory support the mbed board (http://mbed.org)
that features the NXP LPC1768 microcontroller. This OS is also built
with the arm-elf toolchain. STATUS: Contributed.
with the arm-nuttx-elf toolchain. STATUS: Contributed.
</li>
<li><code>configs/mcu123-lpc214x</code>:
This port is for the NXP LPC2148 as provided on the mcu123.com
lpc214x development board.
This OS is also built with the arm-elf toolchain* under Linux or Cygwin.
This OS is also built with the arm-nuttx-elf toolchain* under Linux or Cygwin.
The port supports serial, timer0, spi, and usb.
</li>
@ -858,7 +858,7 @@
</li>
<li><code>configs/ntosd-dm320</code>:
This port uses the Neuros OSD with a GNU arm-elf toolchain* under Linux or Cygwin.
This port uses the Neuros OSD with a GNU arm-nuttx-elf toolchain* under Linux or Cygwin.
See <a href="http://wiki.neurostechnology.com/index.php/Developer_Welcome">Neuros Wiki</a>
for further information.
NuttX operates on the ARM9EJS of this dual core processor.
@ -878,12 +878,12 @@
</li>
<li><code>configs/olimex-lpc2378</code>:
This port uses the Olimex-lpc2378 board and a GNU arm-elf toolchain under
This port uses the Olimex-lpc2378 board and a GNU arm-nuttx-elf toolchain under
Linux or Cygwin. STATUS: ostest and NSH configurations available.
</li>
<li><code>configs/olimex-strp711</code>:
This port uses the Olimex STR-P711 board arm-elf toolchain* under Linux or Cygwin.
This port uses the Olimex STR-P711 board arm-nuttx-elf toolchain* under Linux or Cygwin.
See the <a href="http://www.olimex.com/dev/str-p711.html">Olimex</a> web site
for further information.
STATUS: Configurations for the basic OS test and NSH are complete and verified.

664
Documentation/UsbTrace.html
View File

@ -1,332 +1,332 @@
<html>
<head>
<title>NuttX USB Trace Capability</title>
</head>
<body background="backgd.gif">
<hr><hr>
<table width ="100%">
<tr align="center" bgcolor="#e4e4e4">
<td>
<h1><big><font color="#3c34ec"><i>NuttX USB Device Trace</i></font></big></h1>
<p>Last Updated: March 20, 2011</p>
</td>
</tr>
</table>
<hr><hr>
<p><b>USB Device Tracing Controls</b>.
The NuttX USB device subsystem supports a fairly sophisticated tracing facility.
The basic trace cabability is controlled by these NuttX configuration settings:
</p>
<ul>
<li><code>CONFIG_USBDEV_TRACE</code>: Enables USB tracing</li>
<li><code>CONFIG_USBDEV_TRACE_NRECORDS</code>: Number of trace entries to remember</li>
</ul>
<p><b>Trace IDs</b>.
The trace facility works like this:
When enabled, USB events that occur in either the USB device driver or in the USB class driver are logged.
These events are described in <code>include/nuttx/usb/usbdev_trace.h</code>.
The logged events are identified by a set of event IDs:
</p>
<ul><table>
<tr>
<td><code>TRACE_INIT_ID</code></td>
<td>Initialization events</td>
</tr>
<tr>
<td><code>TRACE_EP_ID</code></td>
<td>Endpoint API calls</td>
</tr>
<tr>
<td><code>TRACE_DEV_ID</code></td>
<td>USB device API calls</td>
</tr>
<tr>
<td><code>TRACE_CLASS_ID</code></td>
<td>USB class driver API calls</td>
</tr>
<tr>
<td><code>TRACE_CLASSAPI_ID</code></td>
<td>Other class driver system API calls</td>
</tr>
<tr>
<td><code>TRACE_CLASSSTATE_ID</code></td>
<td>Track class driver state changes</td>
</tr>
<tr>
<td><code>TRACE_INTENTRY_ID</code></td>
<td>Interrupt handler entry</td>
</tr>
<tr>
<td><code>TRACE_INTDECODE_ID</code></td>
<td>Decoded interrupt event</td>
</tr>
<tr>
<td><code>TRACE_INTEXIT_ID</code></td>
<td>Interrupt handler exit</td>
</tr>
<tr>
<td><code>TRACE_OUTREQQUEUED_ID</code></td>
<td>Request queued for OUT endpoint</td>
</tr>
<tr>
<td><code>TRACE_INREQQUEUED_ID</code></td>
<td>Request queued for IN endpoint</td>
</tr>
<tr>
<td><code>TRACE_READ_ID</code></td>
<td>Read (OUT) action</td>
</tr>
<tr>
<td><code>TRACE_WRITE_ID</code></td>
<td>Write (IN) action</td>
</tr>
<tr>
<td><code>TRACE_COMPLETE_ID</code></td>
<td>Request completed</td>
</tr>
<tr>
<td><code>TRACE_DEVERROR_ID</code></td>
<td>USB controller driver error event</td>
</tr>
<tr>
<td><code>TRACE_CLSERROR_ID</code></td>
<td>USB class driver error event</td>
</tr>
</table></ul>
<p><b>Logged Events</b>.
Each logged event is 32-bits in size and includes
</p>
<ol>
<li>8-bits of the trace ID (values associated with the above)</li>
<li>8-bits of additional trace ID data, and</li>
<li>16-bits of additonal data.</li>
</ol>
<p><b>8-bit Trace Data</b>
The 8-bit trace data depends on the specific event ID. As examples,
</p>
<ul>
<li>
For the USB serial and mass storage class, the 8-bit event data is provided in <code>include/nuttx/usb/usbdev_trace.h</code>.
</li>
<li>
For the USB device driver, that 8-bit event data is provided within the USB device driver itself.
So, for example, the 8-bit event data for the LPC1768 USB device driver is found in <code>arch/arm/src/lpc17xx/lpc17_usbdev.c</code>.
</li>
</ul>
<p><b>16-bit Trace Data</b>.
The 16-bit trace data provided additional context data relevant to the specific logged event.
</p>
<p><b>Trace Control Interfaces</b>.
Logging of each of these kinds events can be enabled or disabled using the interfaces described in <code>include/nuttx/usb/usbdev_trace.h</code>.
</p>
<p><b>Enabling USB Device Tracing</b>.
USB device tracing will be configured if <code>CONFIG_USBDEV</code> and either of the following are set in the NuttX configuration file:
</p>
<ul>
<li><code>CONFIG_USBDEV_TRACE</code>, or</li>
<li><code>CONFIG_DEBUG and CONFIG_DEBUG_USB</code></li>
</ul>
<p><b>Log Data Sink</b>.
The logged data itself may go to either (1) an internal circular buffer, or (2) may be provided on the console.
If <code>CONFIG_USBDEV_TRACE</code> is defined, then the trace data will go to the circular buffer.
The size of the circular buffer is determined by <code>CONFIG_USBDEV_TRACE_NRECORDS</code>.
Otherwise, the trace data goes to console.
<p>
<p><b>Example</b>.
Here is an example of USB trace output using <code>apps/examples/usbserial</code> for an LPC1768 platform with the following NuttX configuration settings:
</p>
<ul>
<li><code>CONFIG_DEBUG</code>, <code>CONFIG_DEBUG_VERBOSE</code>, <code>CONFIG_USB</code>
<li><code>CONFIG_EXAMPLES_USBSERIAL_TRACEINIT</code>, <code>CONFIG_EXAMPLES_USBSERIAL_TRACECLASS</code>,
<code>CONFIG_EXAMPLES_USBSERIAL_TRACETRANSFERS</code>, <code>CONFIG_EXAMPLES_USBSERIAL_TRACECONTROLLER</code>,
<code>CONFIG_EXAMPLES_USBSERIAL_TRACEINTERRUPTS</code>
</ul>
<p>Console Output:</p>
<ul><table>
<tr>
<td align="center">&nbsp;</td>
<td align="left"><code>ABDE</code></td>
</tr>
<tr>
<td align="center">&nbsp;</td>
<td align="left"><code>usbserial_main: Registering USB serial driver</code></td>
</tr>
<tr>
<td align="center">&nbsp;</td>
<td align="left"><code>uart_register: Registering /dev/ttyUSB0</code></td>
</tr>
<tr>
<td align="center">&nbsp;</td>
<td align="left"><code>usbserial_main: Successfully registered the serial driver</code></td>
</tr>
<tr>
<td align="center">1</td>
<td align="left"><code>Class API call 1: 0000</code></td>
</tr>
<tr>
<td align="center">2</td>
<td align="left"><code>Class error: 19:0000</code></td>
</tr>
<tr>
<td align="center">&nbsp;</td>
<td align="left"><code>usbserial_main: ERROR: Failed to open /dev/ttyUSB0 for reading: 107</code></td>
</tr>
<tr>
<td align="center">&nbsp;</td>
<td align="left"><code>usbserial_main: Not connected. Wait and try again.</code></td>
</tr>
<tr>
<td align="center">3</td>
<td align="left"><code>Interrupt 1 entry: 0039</code></td>
</tr>
<tr>
<td align="center">4</td>
<td align="left"><code>Interrupt decode 7: 0019</code></td>
</tr>
<tr>
<td align="center">5</td>
<td align="left"><code>Interrupt decode 32: 0019</code></td>
</tr>
<tr>
<td align="center">6</td>
<td align="left"><code>Interrupt decode 6: 0019</code></td>
</tr>
<tr>
<td align="center">7</td>
<td align="left"><code>Class disconnect(): 0000</code></td>
</tr>
<tr>
<td align="center">8</td>
<td align="left"><code>Device pullup(): 0001</code></td>
</tr>
<tr>
<td align="center">9</td>
<td align="left"><code>Interrupt 1 exit: 0000</code></td>
</tr>
</table></ul>
<p>
The numbered items are USB USB trace output.
You can look in the file <code>drivers/usbdev/usbdev_trprintf.c</code> to see examctly how each output line is formatted.
Here is how each line should be interpreted:
</p>
<ul><table>
<tr>
<th align="center">&nbsp</th>
<td align="left">USB EVENT ID</td>
<td align="right">8-bit<br>EVENT<br>DATA</td>
<td align="left">MEANING</td>
<td align="left">16-bit<br>EVENT<br>DATA</td>
</tr>
<tr>
<td align="center">1</td>
<td align="left"><code>TRACE_CLASSAPI_ID</code><sup>1</sup></td>
<td align="right">1</td>
<td align="left"><code>USBSER_TRACECLASSAPI_SETUP</code><sup>1</sup></td>
<td align="left">0000</td>
</tr>
<tr>
<td align="center">2</td>
<td align="left"><code>TRACE_CLSERROR_ID</code><sup>1</sup></td>
<td align="right">19</td>
<td align="left"><code>USBSER_TRACEERR_SETUPNOTCONNECTED</code><sup>1</sup></td>
<td align="left">0000</td>
</tr>
<tr>
<td align="center">3</td>
<td align="left"><code>TRACE_INTENTRY_ID</code><sup>1</sup></td>
<td align="right">1</td>
<td align="left"><code>LPC17_TRACEINTID_USB</code><sup>2</sup></td>
<td align="left">0039</td>
</tr>
<tr>
<td align="center">4</td>
<td align="left"><code>TRACE_INTDECODE_ID</code><sup>2</sup></td>
<td align="right">7</td>
<td align="left"><code>LPC17_TRACEINTID_DEVSTAT</code><sup>2</sup></td>
<td align="left">0019</td>
</tr>
<tr>
<td align="center">5</td>
<td align="left"><code>TRACE_INTDECODE_ID</code><sup>2</sup></td>
<td align="right">32</td>
<td align="left"><code>LPC17_TRACEINTID_SUSPENDCHG</code><sup>2</sup></td>
<td align="left">0019</td>
</tr>
<tr>
<td align="center">6</td>
<td align="left"><code>TRACE_INTDECODE_ID</code><sup>2</sup></td>
<td align="right">6</td>
<td align="left"><code>LPC17_TRACEINTID_DEVRESET</code><sup>2</sup></td>
<td align="left">0019</td>
</tr>
<tr>
<td align="center">7</td>
<td align="left"><code>TRACE_CLASS_ID</code><sup>1</sup></td>
<td align="right">3</td>
<td align="left"><code>(See TRACE_CLASSDISCONNECT</code><sup>1</sup>)</td>
<td align="left">0000</td>
</tr>
<tr>
<td align="center">8</td>
<td align="left"><code>TRACE_DEV_ID</code><sup>1</sup></td>
<td align="right">6</td>
<td align="left"><code>(See TRACE_DEVPULLUP</code><sup>1</sup>)</td>
<td align="left">0001</td>
</tr>
<tr>
<td align="center">9</td>
<td align="left"><code>TRACE_INTEXIT_ID</code><sup>1</sup></td>
<td align="right">1</td>
<td align="left"><code>LPC17_TRACEINTID_USB</code><sup>2</sup></td>
<td align="left">0000</td>
</tr>
</table>
<p><small><b>NOTES</b>:<br>
<sup>1</sup>See <code>include/nuttx/usb/usbdev_trace.h</code><br>
<sup>2</sup><code>See arch/arm/src/lpc17xx/lpc17_usbdev.c</code>
</small></p>
</ul>
<p>
In the above example you can see that:
</p>
<ul>
<li><b>1</b>.
The serial class USB setup method was called for the USB serial class.
This is the corresponds to the following logic in <code>drivers/usbdev/pl2303.c</code>:
<ul><pre>
static int pl2303_setup(FAR struct uart_dev_s *dev)
{
...
usbtrace(PL2303_CLASSAPI_SETUP, 0);
...
</pre></ul>
</li>
<li><b>2</b>.
An error occurred while processing the setup command because no configuration has yet been selected by the host.
This corresponds to the following logic in <code>drivers/usbdev/pl2303.c</code>:
<ul><pre>
static int pl2303_setup(FAR struct uart_dev_s *dev)
{
...
/* Check if we have been configured */
if (priv->config == PL2303_CONFIGIDNONE)
{
usbtrace(TRACE_CLSERROR(USBSER_TRACEERR_SETUPNOTCONNECTED), 0);
return -ENOTCONN;
}
...
</pre></ul>
<li><b>3-6</b>.
Here is a USB interrupt that suspends and resets the device.
</li>
<li><b>7-8</b>.
During the interrupt processing the serial class is disconnected
</li>
<li><b>9</b>.
And the interrupt returns
</li>
</ul>
</body>
</html>
<html>
<head>
<title>NuttX USB Trace Capability</title>
</head>
<body background="backgd.gif">
<hr><hr>
<table width ="100%">
<tr align="center" bgcolor="#e4e4e4">
<td>
<h1><big><font color="#3c34ec"><i>NuttX USB Device Trace</i></font></big></h1>
<p>Last Updated: March 20, 2011</p>
</td>
</tr>
</table>
<hr><hr>
<p><b>USB Device Tracing Controls</b>.
The NuttX USB device subsystem supports a fairly sophisticated tracing facility.
The basic trace cabability is controlled by these NuttX configuration settings:
</p>
<ul>
<li><code>CONFIG_USBDEV_TRACE</code>: Enables USB tracing</li>
<li><code>CONFIG_USBDEV_TRACE_NRECORDS</code>: Number of trace entries to remember</li>
</ul>
<p><b>Trace IDs</b>.
The trace facility works like this:
When enabled, USB events that occur in either the USB device driver or in the USB class driver are logged.
These events are described in <code>include/nuttx/usb/usbdev_trace.h</code>.
The logged events are identified by a set of event IDs:
</p>
<ul><table>
<tr>
<td><code>TRACE_INIT_ID</code></td>
<td>Initialization events</td>
</tr>
<tr>
<td><code>TRACE_EP_ID</code></td>
<td>Endpoint API calls</td>
</tr>
<tr>
<td><code>TRACE_DEV_ID</code></td>
<td>USB device API calls</td>
</tr>
<tr>
<td><code>TRACE_CLASS_ID</code></td>
<td>USB class driver API calls</td>
</tr>
<tr>
<td><code>TRACE_CLASSAPI_ID</code></td>
<td>Other class driver system API calls</td>
</tr>
<tr>
<td><code>TRACE_CLASSSTATE_ID</code></td>
<td>Track class driver state changes</td>
</tr>
<tr>
<td><code>TRACE_INTENTRY_ID</code></td>
<td>Interrupt handler entry</td>
</tr>
<tr>
<td><code>TRACE_INTDECODE_ID</code></td>
<td>Decoded interrupt event</td>
</tr>
<tr>
<td><code>TRACE_INTEXIT_ID</code></td>
<td>Interrupt handler exit</td>
</tr>
<tr>
<td><code>TRACE_OUTREQQUEUED_ID</code></td>
<td>Request queued for OUT endpoint</td>
</tr>
<tr>
<td><code>TRACE_INREQQUEUED_ID</code></td>
<td>Request queued for IN endpoint</td>
</tr>
<tr>
<td><code>TRACE_READ_ID</code></td>
<td>Read (OUT) action</td>
</tr>
<tr>
<td><code>TRACE_WRITE_ID</code></td>
<td>Write (IN) action</td>
</tr>
<tr>
<td><code>TRACE_COMPLETE_ID</code></td>
<td>Request completed</td>
</tr>
<tr>
<td><code>TRACE_DEVERROR_ID</code></td>
<td>USB controller driver error event</td>
</tr>
<tr>
<td><code>TRACE_CLSERROR_ID</code></td>
<td>USB class driver error event</td>
</tr>
</table></ul>
<p><b>Logged Events</b>.
Each logged event is 32-bits in size and includes
</p>
<ol>
<li>8-bits of the trace ID (values associated with the above)</li>
<li>8-bits of additional trace ID data, and</li>
<li>16-bits of additonal data.</li>
</ol>
<p><b>8-bit Trace Data</b>
The 8-bit trace data depends on the specific event ID. As examples,
</p>
<ul>
<li>
For the USB serial and mass storage class, the 8-bit event data is provided in <code>include/nuttx/usb/usbdev_trace.h</code>.
</li>
<li>
For the USB device driver, that 8-bit event data is provided within the USB device driver itself.
So, for example, the 8-bit event data for the LPC1768 USB device driver is found in <code>arch/arm/src/lpc17xx/lpc17_usbdev.c</code>.
</li>
</ul>
<p><b>16-bit Trace Data</b>.
The 16-bit trace data provided additional context data relevant to the specific logged event.
</p>
<p><b>Trace Control Interfaces</b>.
Logging of each of these kinds events can be enabled or disabled using the interfaces described in <code>include/nuttx/usb/usbdev_trace.h</code>.
</p>
<p><b>Enabling USB Device Tracing</b>.
USB device tracing will be configured if <code>CONFIG_USBDEV</code> and either of the following are set in the NuttX configuration file:
</p>
<ul>
<li><code>CONFIG_USBDEV_TRACE</code>, or</li>
<li><code>CONFIG_DEBUG and CONFIG_DEBUG_USB</code></li>
</ul>
<p><b>Log Data Sink</b>.
The logged data itself may go to either (1) an internal circular buffer, or (2) may be provided on the console.
If <code>CONFIG_USBDEV_TRACE</code> is defined, then the trace data will go to the circular buffer.
The size of the circular buffer is determined by <code>CONFIG_USBDEV_TRACE_NRECORDS</code>.
Otherwise, the trace data goes to console.
<p>
<p><b>Example</b>.
Here is an example of USB trace output using <code>apps/examples/usbserial</code> for an LPC1768 platform with the following NuttX configuration settings:
</p>
<ul>
<li><code>CONFIG_DEBUG</code>, <code>CONFIG_DEBUG_VERBOSE</code>, <code>CONFIG_USB</code>
<li><code>CONFIG_EXAMPLES_USBSERIAL_TRACEINIT</code>, <code>CONFIG_EXAMPLES_USBSERIAL_TRACECLASS</code>,
<code>CONFIG_EXAMPLES_USBSERIAL_TRACETRANSFERS</code>, <code>CONFIG_EXAMPLES_USBSERIAL_TRACECONTROLLER</code>,
<code>CONFIG_EXAMPLES_USBSERIAL_TRACEINTERRUPTS</code>
</ul>
<p>Console Output:</p>
<ul><table>
<tr>
<td align="center">&nbsp;</td>
<td align="left"><code>ABDE</code></td>
</tr>
<tr>
<td align="center">&nbsp;</td>
<td align="left"><code>usbserial_main: Registering USB serial driver</code></td>
</tr>
<tr>
<td align="center">&nbsp;</td>
<td align="left"><code>uart_register: Registering /dev/ttyUSB0</code></td>
</tr>
<tr>
<td align="center">&nbsp;</td>
<td align="left"><code>usbserial_main: Successfully registered the serial driver</code></td>
</tr>
<tr>
<td align="center">1</td>
<td align="left"><code>Class API call 1: 0000</code></td>
</tr>
<tr>
<td align="center">2</td>
<td align="left"><code>Class error: 19:0000</code></td>
</tr>
<tr>
<td align="center">&nbsp;</td>
<td align="left"><code>usbserial_main: ERROR: Failed to open /dev/ttyUSB0 for reading: 107</code></td>
</tr>
<tr>
<td align="center">&nbsp;</td>
<td align="left"><code>usbserial_main: Not connected. Wait and try again.</code></td>
</tr>
<tr>
<td align="center">3</td>
<td align="left"><code>Interrupt 1 entry: 0039</code></td>
</tr>
<tr>
<td align="center">4</td>
<td align="left"><code>Interrupt decode 7: 0019</code></td>
</tr>
<tr>
<td align="center">5</td>
<td align="left"><code>Interrupt decode 32: 0019</code></td>
</tr>
<tr>
<td align="center">6</td>
<td align="left"><code>Interrupt decode 6: 0019</code></td>
</tr>
<tr>
<td align="center">7</td>
<td align="left"><code>Class disconnect(): 0000</code></td>
</tr>
<tr>
<td align="center">8</td>
<td align="left"><code>Device pullup(): 0001</code></td>
</tr>
<tr>
<td align="center">9</td>
<td align="left"><code>Interrupt 1 exit: 0000</code></td>
</tr>
</table></ul>
<p>
The numbered items are USB USB trace output.
You can look in the file <code>drivers/usbdev/usbdev_trprintf.c</code> to see examctly how each output line is formatted.
Here is how each line should be interpreted:
</p>
<ul><table>
<tr>
<th align="center">&nbsp</th>
<td align="left">USB EVENT ID</td>
<td align="right">8-bit<br>EVENT<br>DATA</td>
<td align="left">MEANING</td>
<td align="left">16-bit<br>EVENT<br>DATA</td>
</tr>
<tr>
<td align="center">1</td>
<td align="left"><code>TRACE_CLASSAPI_ID</code><sup>1</sup></td>
<td align="right">1</td>
<td align="left"><code>USBSER_TRACECLASSAPI_SETUP</code><sup>1</sup></td>
<td align="left">0000</td>
</tr>
<tr>
<td align="center">2</td>
<td align="left"><code>TRACE_CLSERROR_ID</code><sup>1</sup></td>
<td align="right">19</td>
<td align="left"><code>USBSER_TRACEERR_SETUPNOTCONNECTED</code><sup>1</sup></td>
<td align="left">0000</td>
</tr>
<tr>
<td align="center">3</td>
<td align="left"><code>TRACE_INTENTRY_ID</code><sup>1</sup></td>
<td align="right">1</td>
<td align="left"><code>LPC17_TRACEINTID_USB</code><sup>2</sup></td>
<td align="left">0039</td>
</tr>
<tr>
<td align="center">4</td>
<td align="left"><code>TRACE_INTDECODE_ID</code><sup>2</sup></td>
<td align="right">7</td>
<td align="left"><code>LPC17_TRACEINTID_DEVSTAT</code><sup>2</sup></td>
<td align="left">0019</td>
</tr>
<tr>
<td align="center">5</td>
<td align="left"><code>TRACE_INTDECODE_ID</code><sup>2</sup></td>
<td align="right">32</td>
<td align="left"><code>LPC17_TRACEINTID_SUSPENDCHG</code><sup>2</sup></td>
<td align="left">0019</td>
</tr>
<tr>
<td align="center">6</td>
<td align="left"><code>TRACE_INTDECODE_ID</code><sup>2</sup></td>
<td align="right">6</td>
<td align="left"><code>LPC17_TRACEINTID_DEVRESET</code><sup>2</sup></td>
<td align="left">0019</td>
</tr>
<tr>
<td align="center">7</td>
<td align="left"><code>TRACE_CLASS_ID</code><sup>1</sup></td>
<td align="right">3</td>
<td align="left"><code>(See TRACE_CLASSDISCONNECT</code><sup>1</sup>)</td>
<td align="left">0000</td>
</tr>
<tr>
<td align="center">8</td>
<td align="left"><code>TRACE_DEV_ID</code><sup>1</sup></td>
<td align="right">6</td>
<td align="left"><code>(See TRACE_DEVPULLUP</code><sup>1</sup>)</td>
<td align="left">0001</td>
</tr>
<tr>
<td align="center">9</td>
<td align="left"><code>TRACE_INTEXIT_ID</code><sup>1</sup></td>
<td align="right">1</td>
<td align="left"><code>LPC17_TRACEINTID_USB</code><sup>2</sup></td>
<td align="left">0000</td>
</tr>
</table>
<p><small><b>NOTES</b>:<br>
<sup>1</sup>See <code>include/nuttx/usb/usbdev_trace.h</code><br>
<sup>2</sup><code>See arch/arm/src/lpc17xx/lpc17_usbdev.c</code>
</small></p>
</ul>
<p>
In the above example you can see that:
</p>
<ul>
<li><b>1</b>.
The serial class USB setup method was called for the USB serial class.
This is the corresponds to the following logic in <code>drivers/usbdev/pl2303.c</code>:
<ul><pre>
static int pl2303_setup(FAR struct uart_dev_s *dev)
{
...
usbtrace(PL2303_CLASSAPI_SETUP, 0);
...
</pre></ul>
</li>
<li><b>2</b>.
An error occurred while processing the setup command because no configuration has yet been selected by the host.
This corresponds to the following logic in <code>drivers/usbdev/pl2303.c</code>:
<ul><pre>
static int pl2303_setup(FAR struct uart_dev_s *dev)
{
...
/* Check if we have been configured */
if (priv->config == PL2303_CONFIGIDNONE)
{
usbtrace(TRACE_CLSERROR(USBSER_TRACEERR_SETUPNOTCONNECTED), 0);
return -ENOTCONN;
}
...
</pre></ul>
<li><b>3-6</b>.
Here is a USB interrupt that suspends and resets the device.
</li>
<li><b>7-8</b>.
During the interrupt processing the serial class is disconnected
</li>
<li><b>9</b>.
And the interrupt returns
</li>
</ul>
</body>
</html>