Mistakes happen, bugs are found, things work not always ideally. No problem, here's a collection of procedures to test this or that feature on a Gen7-ARM. Most of them apply to Gen7-AVR, too.

If there is a doubt that serial works, one can do a serial loopback test.

• Connect the power supply, the yellow LED should light up.
• Connect the USB outlet to your PC.
• Open a serial terminal, e.g. GtkTerm on Linux, PuTTY or HyperTerminal on Windows, CoolTerm on OS X. An application which allows to connect to a serial device.
• Let the serial terminal connect to the serial device at 115200 baud, one stop bit, no parity. How to do this depends on the application.

There should be no error message on connecting.

The following behaviour depends on wether the serial terminal application has local echo turned on or not. To find out, simply type a few characters into the terminal's window. If the characters are written to the terminal's screen, local echo is turned on. If typing characters on the keyboard results in just nothing, it's turned off. Both is fine.

The green marker shows the pins to connect for a serial loop.

Now connect RxD and TxD, the two leftmost pins on the LPC1114 socket in the lower row, like shown in the picture to the right. A short, bent wire is just fine for this. You can do this with the PSU still on.

With this bridge, typing characters in the serial terminal window should cause another character to be written. If each keystroke caused one character before, you should see now two. If a keystroke caused nothing before, you should see each character now.

How this works? Well, the character is sent out over USB, converted to serial, sent on the serial transmit line, fed right back into the serial receive line by this wire bridge and then goes all the way back via serial and USB into your terminal window. If this works, serial communications works.

When trying to connect to a Gen7 with a Debian/Ubuntu system, it says this:

stty: /dev/ttyACM0: Device or resource busy

/dev/ttyACM0 is a serial device and as such, Modem Manager assumes it to be a connected modem and tries to establish a network connection as soon as it appears, occupying the device.

First and most simple solution is to simply wait for a minute. Modem Manager gives up after a while, freeing the device.

Second solution is to uninstall Modem Manager:

sudo apt-get purge modemmanager

As no other package depends on Modem Manager, this works flawlessly. You loose the ability to make a network connection via a modem, of course.

Third solution is to instruct the system to try on all serial devices, but not the Gen7. This is a bit more complicated. Googling around I found several sets of instructions, only one of them look reasonable:

AT91 writes:

sudo vi /lib/udev/rules.d/10-atmel-usb-device-blacklist.rules

Then insert the following lines:

# Atmel CDC interfaces: Not handled by ModemManager
# SEGGER console interface
ATTRS{idVendor}=="1366", ENV{ID_MM_DEVICE_IGNORE}="1"
# SAM-BA CDC interface with SAM-BA monitor
ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="6124", ENV{ID_MM_DEVICE_IGNORE}="1"
# Atmel EDBG CDC interface
ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2111", ENV{ID_MM_DEVICE_IGNORE}="1"

Finally restart udev:

sudo service udev restart
udev stop/waiting
udev start/running, process 9299

RepRap DIY note: doing it this way will cause a conflict next time the udev package is upgraded. As udev allows to override distribution files it'd probably be better to copy that file to /etc/udev/rules.d, which causes the one in /lib/udev/rules.d to be ignored. Then edit the copy.