Details of USB communications for NXT

[tcwan]

Hi,

I'm trying to understand the architecture of the existing USB protocol in the NXT firmware (more specifically the enhanced version) for use by my GDB ARM debugger project to communicate with the GDB server.

What USB protocol device class does the NXT firmware implement? Similarly for the Fantom driver (PC side).

The brief intro to USB protocol device classes from SEGGER http://www.segger.com/cms/admin/uploads ... _V227g.pdf list several classes, notably Bulk, CDC, and HID which seem most likely to be candidate protocols.

[gloomyandy]

I'm pretty sure that you get two bulk endpoints (one input, one output), and a single interrupt endpoint. If you are on Linux then lsusb -v will give you all of the details. The Fantom driver only provides access to the bulk endpoints (I think). One problem you may well hit is that the Fantom driver does not seem to like more than one thread using it at a time. So you can't have a reader thread blocking on input and still be able to write to the device...

Andy

[linusa]

Some of my research from 2008 is still available here: http://www.mindstorms.rwth-aachen.de/trac/wiki/USBStuff
Please note that it's probably not state of the art, and might not be complete...

Anyway, it all condensated into the RWTH toolbox for MATLAB, which provides functions to talk to the NXT via USB connections on both Windows and Linux systems (by using Fantom and libusb, respectively).

If you're not afraid of MATLAB syntax, you can check out the documented functions here:
http://www.mindstorms.rwth-aachen.de/tr ... penNXTEx.m
http://www.mindstorms.rwth-aachen.de/tr ... ndPacket.m
http://www.mindstorms.rwth-aachen.de/tr ... ctPacket.m

Somehow I couldn't get libusb to work on Windows systems in MATLAB, but the supplied C++-example did work.

If you decide to to take a look at the MATLAB source-code, I'd recommend an editor with syntax highlighting, such as Notepad++, and a full toolbox download...

Other projects, who deal with the same problem and who are worth looking at (in no particular order):
NXT_Python
NXT-Python
aNXT
NXT++
libnxt
MindSqualls (.net)
iCommand (Java)
LEGO::NXT (Perl)

and maybe even more. See Wikipedia on NXT for a long list.

[schodet]

If you want to make a GDB stub, you should be able to talk to the target code even when target is stopped on a breakpoint. This means that you will have to implement your own code which could run even when the firmware is stopped, right?

[schodet]

I was curious and I run the gloomyandy command. Interesting parts:

Code: Select all

  bDeviceClass            0 (Defined at Interface level)
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol

        bEndpointAddress     0x01  EP 1 OUT
          Transfer Type            Bulk

        bEndpointAddress     0x82  EP 2 IN
          Transfer Type            Bulk

EP0 is reserved for control, so there is only EP3 left, according to ATMEL datasheet. You may hook in the USB interrupt to take your frames .

Whole output:

Code: Select all

Bus 002 Device 004: ID 0694:0002 Lego Group Mindstorms NXT
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0         8
  idVendor           0x0694 Lego Group
  idProduct          0x0002 Mindstorms NXT
  bcdDevice            0.00
  iManufacturer           0
  iProduct                0
  iSerial                 1 001653089133
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           32
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0xc0
      Self Powered
    MaxPower                0mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
Device Status:     0x0001
  Self Powered

[schodet]

That's me again!

After looking at Rasmus code in nxtgcc (nxtdebug.c), he uses only low level functions from d_usb.c and uses the USB bulk end point as a simple serial port. The only Fantom specific part is that the Fantom driver sends a version request at connection and Rasmus code handles this specific request.

On the computer side, he uses the raw read and write from the fantom driver. I suppose that using libusb would be actually simpler.

This seems to mean that debugging is completely taking over the USB port.

[tcwan]

Hi all,
Thanks so much for all the comments! I'll have to study the various packages to understand what others have done.

If you want to make a GDB stub, you should be able to talk to the target code even when target is stopped on a breakpoint. This means that you will have to implement your own code which could run even when the firmware is stopped, right?

The ARM Debugger I'm developing is not using JTAG, so technically the CPU is not stopped. This means that the GDB stub will have to be incorporated into the firmware and run as part of the firmware. As to whether it can coexist with other NXT-PC communications on Endpoints 1 & 2, I have to study that further, I've just started on trying to understand the USB communications protocol myself.

[tcwan]

As to whether it can coexist with other NXT-PC communications on Endpoints 1 & 2, I have to study that further, I've just started on trying to understand the USB communications protocol myself.

After reading about USB protocols, it appears that the only way to implement an out-of-channel link is to setup Endpoint 3 as a Control Endpoint (Control Endpoints are bidirectional, whereas Bulk Endpoints are unidirectional). The disadvantage is that it'll require a lot of support code since EP3 is not currently used by the NXT firmware or NxOS. In addition, I don't see how to select/specify EP3 in the Fantom drivers, they are very high level and don't seem to provide access to specific end-points. I wonder if it is possible for applications running on the PC to open one USB interface for different endpoints (e.g., Debugger using EP3, NXTTool running concurrently using EP1&2).

The quicker way is probably to override Endpoints 1 & 2 for communications for a start, to get the debugger working, and then work to implement a proper interface over EP3.