Sam_I_Am -- Connecting the Device

Andrew Sterian
Padnos College of Engineering and Computing
Grand Valley State University


Top-Level | Connecting the Device | Program Operation | Commands
 
Installing SAM-BA | USB Serial Driver | USB Communications Device Class Driver

Introduction

Sam_I_Am expects to communicate with SAM-BA over a USB interface, not a serial port (even though SAM-BA can do both). This means that:

The first two points above are either true or not -- there's not much you can do if they're not. The Atmel AT91SAM7S64-EK development kit satisfies both of these points. This board was used for developing Sam_I_Am thus is known to work.

The sections below address the last two points.

Installing SAM-BA

The SAM-BA monitor code is always present on the AT91SAM7S microcontrollers in a hidden read-only memory. For SAM-BA to run, it must be copied into the microcontroller's FLASH memory. The procedure for doing this is as follows:
  1. With the microcontroller board power off, connect the TST pin on the microcontroller to VDDIO (e.g., 3.3V if VDDIO is 3.3V). On the AT91SAM7S64-EK development kit, this is accomplished by installing the TST jumper (JP5).
  2. Ensure that pins PA0, PA1, and PA2 are high (they have internal pullups so if they are left disconnected then they will read as high).
  3. Apply power to the microcontroller. Wait 10 seconds. Remove power.
  4. Remove the TST pin connection to VDDIO.

The effect of this process is that the first two pages of FLASH memory will be overwritten with the SAM-BA program. When power is applied to the microcontroller again, SAM-BA will automatically execute.

USB Serial Driver

The easiest way to have Linux recognize the microcontroller's USB peripheral is to use the usbserial kernel module. You simply have to type (as root):
   modprobe usbserial vendor=0x03EB product=0x6124

If the above worked without any error messages, you can plug in your device.

You can then talk to SAM-BA using a standard terminal emulator (such as minicom) using the /dev/ttyUSB0 device, or whatever device name has been created on your system with a major device number of 188. This device name may be /dev/ttyUSB1, etc. if you are already using the serial driver for other devices. If you are using devfs, you should see your device as /dev/usb/tts/0, or /dev/usb/tts/1, etc.

If you cannot find either of the above filenames, you can find the right device by searching for the special device file name that corresponds to the major device number of 188:

   find /dev -inum `ls -liR /dev | fgrep "188," | head -1 | sed -e "s/^ *//" | cut -d" " -f1`

If the above command does not display any files, then the distribution you are using did not create a file association to the usbserial driver. You can easily create one on your own. As root, type:

   mknod -m 0666 /dev/ttyUSB0 c 188 0

This will create the character-special file /dev/ttyUSB0 (with read-write permissions for everyone) and associate it with a major device number of 188 and minor number of 0.

The modprobe command will fail if you do not have the usbserial kernel module compiled, in which case you will have to learn about compiling a kernel and installing it. This process is well-described by the Kernel Rebuild Guide.

You may have to be root to access the special file (/dev/ttyUSB0). If you want to be able to access the special device as a normal user, you will have to use the chmod command to give regular users permission to read and write from it:

   chmod a+rw /dev/ttyUSB0

The process may also fail you have another kernel module that interferes with usbserial. The acm module in 2.4 kernels and the cdc-acm module in 2.6 kernels may be the source of this interference as they implement the USB Communications Device Class (see the next section). Try removing those modules (using modprobe -r acm or modprobe -r cdc-acm) first.

As a last resort, try running the depmod command (as root) to make sure your module dependencies are up-to-date.

USB Communications Device Class Driver

The SAM-BA documentation indicates that it configures the AT91SAM7S microcontroller as a USB Communications Device Class device. Thus, the Linux acm (for 2.4 kernels) or cdc-acm (for 2.6 kernels) should be usable.

No instructions for the 2.4 kernel acm driver are available yet.

For the 2.6 kernel cdc-acm driver, the driver source code must be patched and the kernel module recompiled in order to recognize the microcontroller. The first step is to modify the cdc-acm.c file in the kernel source tree (e.g., /usr/src/linux-2.6.14.3/drivers/usb/class/cdc-acm.c) to add the following three lines marked with '+' signs:

      { USB_DEVICE(0x0482, 0x0203), /* KYOCERA AH-K3001V */
      .driver_info = NO_UNION_NORMAL, /* has no union descriptor */
      },
    + { USB_DEVICE(0x03EB, 0x6124), /* Atmel AT91SAM7S microcontrollers (SAM-BA) */
    + .driver_info = NO_UNION_NORMAL,
    + },
      /* control interfaces with various AT-command sets */
      { USB_INTERFACE_INFO(USB_CLASS_COMM, USB_CDC_SUBCLASS_ACM,
Next, recompile the kernel and ensure that the cdc-acm driver is compiled as a module. The new kernel has to be installed and booted. The new kernel module can then be installed with (as root):
  modprobe cdc-acm
When you plug in the microcontroller device, you should be able to communicate with it using a filename of /dev/usb/acm/0, or /dev/ttyACM0, or other names depending on your distribution. You can try to find the right name on your system using the same type of command used to find the usbserial devices from the previous section:
   find /dev -inum `ls -liR /dev | fgrep "166," | head -1 | sed -e "s/^ *//" | cut -d" " -f1`

The major device number for the cdc-acm module is 166. If this special file has not been created, you can create it yourself (as root):

     mkdir -p /dev/usb/acm
     chmod -R a+rx /dev/usb
     mknod /dev/usb/acm/0 c 166 0
     mknod /dev/usb/acm/1 c 166 1
     mknod /dev/usb/acm/2 c 166 2
     chmod -R a+rwx /dev/usb/acm

The above allows anyone on the system access to these devices. You may want to modify your chmod commands for alternative access arrangements if you are running a multi-user system.


© 2006, Copyright by Andrew Sterian; All Rights Reserved. mailto: steriana@claymore.engineer.gvsu.edu