Commtech's Fastcom Product Support Blog

fscc_2010_02_02.zip

asyncpci_2010_02_02.zip

asyncpci335_2010_02_02

fscc_2009_12_23

This is the second recent firmware update to the FCore.

• FSCC Family = FCore version 9.09
• SuperFSCC Family = FCore version 4.11

This fixes another small bug in XSync mode.  If you turned on zero or one insertion in XSync mode, it was not only doing the insertion to the data or payload (intended) but it was also bit insertion the opening and closing flags (bug).  This prevented (for example) correctly being able to receive and transmit HDLC frames while in XSync mode as it would bit-stuff the opening HDLC flag.  In this example the HDLC flag 0×7E (0111 1110) would end up getting bit stuffed and would end up like this:  0111 1101 0.

This bug would have affected anyone who had a sync or term character that had 5 or more contiguous one bits (like: 0xFF or 0×3E).

Note: as of the date of this post, this is considered the current, shipping firmware unless otherwise noted.

There have been a couple of firmware updated since I last posted.  Here the first one.

• FSCC family = FCore version 9.08
• SuperFSCC family = FCore version 4.10

This is a fix to a bug discovered by our good friend Al.  Thanks Al.

The problem is with XSync mode when you have what I’m calling a “double” termination character.  That is any termination character that is a double byte (i.e. 0xAA, 0×22, 0xFF, etc).  If the last byte of your data’s upper nibble matches the byte of your “double” termination character, then you will lose it.

Example:

Data = 0×12345678

Termination = 0×77

The data is put on the line LSB first and so the 7 in the last byte of data will be accidentally taken to be the first byte of the termination character.

It is still possible to induce this problem if you try to enable zero/one insertion while you are using a double termination byte.  We would have to redesign major portions of the receive state machine to make it work with zero/one insertion as well.

We have only had one person report this problem, so chances are that most of you aren’t affected by this bug, but we fixed it anyway.

It has come to my attention that some (maybe not all) Linux kernels of the vintage 2.6.27 (specifically Ubuntu 8.10) and later will cause the SuperFastcom driver to seg fault upon being loaded with an insmod.  Apparently someone decided that the DSCC4 kernel module is associated with the PEB20534 serial controller’s PCI device ID and therefore would be the correct driver to load when that PCI device ID is detected.  This would be incorrect.

To get around this problem, you will need to add the DSCC4 and hdlc modules to modprobe’s blacklist so that they do not automatically get loaded.  Edit the file /etc/modprobe.d/blacklist and add these two lines to it somewhere:

blacklist dscc4

blacklist hdlc

Reboot your PC and verify that these two modules are no longer with an lsmod.  You will now be able to correctly insmod the SuperFastcom’s superfc.ko kernel module and use the card as intended.

If anyone knows how to get them to NOT load these modules by default, let me know and I’ll see what I can do.

09/23/2009 – Linux

• Fix request_irq() to stop using deprecated SA_INTERRUPT and SA_SHIRQ flags.
• I can also confirm that this driver installs and runs in OpenSuse 11.0.

esccpcmcia_2009_09_23

07/20/2009 - Windows

• Added IOCTL call to Async module to allow reading of auto hardware RTS & CTS flow control
• Making settings tab able to read the hardware flow control
• Created example application to show how to use the set/get hardware flow control

fscc_2009_07_20.zip

To start we need to grab a few packages.

su -c 'yum groupinstall "Development Tools" ncurses-devel #'

Now make sure you are not logged in as root and run these commands to setup a directory tree to build the kernel.

cd
mkdir -p rpmbuild/{BUILD,RPMS,SOURCES,SPECS,SRPMS}
echo '%_topdir %(echo $HOME)/rpmbuild' > .rpmmacros

Now we need to get the kernel source code to patch. To do this we use a command like this and edit it to use the specific kernel we wou like to use. You can browse here http://ftp.redhat.com/pub/redhat/linux/enterprise/5Client/en/os/SRPMS/ for more options. This line might take awhile since it is downloading an ~50mb file first.

rpm -i kernel-2.6.18-8.el5.src.rpm

Next up lets unpack the source code and get it ready to go.

cd ~/rpmbuild/SPECS
rpmbuild -bp --target=`uname -m` kernel-2.6.spec

Now we configure the kernel to do everything we need.

cd ~/rpmbuild/BUILD/kernel-2.6.18/linux-2.6.18.<arch>
cp /boot/config-2.6.18-8.el5 .config
make oldconfig

Edit the .config file we just copied to the current directory and modify the line CONFIG_SERIAL_8250_RUNTIME_UARTS to something higher than 4.

CONFIG_SERIAL_8250_RUNTIME_UARTS=8

Add this line as the first line in the .config file.

# i386

Now replace an existing config file with the one we just modified. Then move all of the config files over to the SOURCES directory.

cp .config configs/kernel-2.6.18-i686.config
cp configs/* ~/rpmbuild/SOURCES

We need to copy our patch file into the ~/rpmbuild/SOURCES/ directory so it gets applied during the build.

cp commtech.patch ~/rpmbuild/SOURCES/commtech.patch

Change directories.
cd ~/rpmbuild/SPECS/

Open up the kernel-2.6.spec file and modify this line so it looks like this. This way we can tell the which kernel is which when we are done.
%define release 8%{?dist}.commtech

Then at line 913 add this line.
Patch40000: commtech.patch

Then at line 1985 add this line.
%patch40000 -p1

Build time. This step takes forever so I wouldn’t wait and watch. NOTE: Real early in the build process there is a problem with our patch that makes us manually specify the file that needs patched. So when it asks which file you need to say this line with your username and arch.
/home/<username>rpmbuild/BUILD/kernel-2.6.18/linux-2.6.18.<arch>/drivers/serial

rpmbuild --with baseonly -bb --target=`uname -m` kernel-2.6.spec

Finally the build is done and all you have left to do it install the
kernel and reboot. Just double click on the RPM file of your choosing
in the ~/rpmbuild/RPMS/ directory and follow the install prompt.

06/24/2009 -  LInux

• Added more patch files for kernel 2.6 compiles
• Updated the loop.c example program

12/05/2008 – Linux

• Added RTSCTS IOCTL call

asyncpci335_2009_06_24

06/24/2009 - Windows

• Added updated firmware for FSCC/232
• Modified basic_settings GUI so that the CRC is changable in HDLC mode

06/24/2009 - Linux

• Added new device IDs
• Bug fixes for new kernel revs
• New patch files for async mode

05/06/2009 - Windows

• Added IOCTL call to Async module to allow setting of auto hardware RTS & CTS flow control

03/16/2009 - Windows

• Modified installation files to recognize new SuperFSCC/4 firmware revision 14.0D

fscc_2009_06_24

Here is a guide for patching the Linux kernel in Fedora 8 so that the Commtech boards will be detected.

To start we need to make sure we have all the tools we need for obtaining and building the kernel.


su -c 'yum install yum-utils rpm-build m4 make gcc redhat-rpm-config rpmdevtools ncurses-devel'


Now that we have all the tools we need, we run another command that sets up some directories for usage.


rpmdev-setuptree


Now everything should be setup the way we want it. So we download the kernel source code.


yumdownloader --source kernel
su -c 'yum-builddep kernel-<version>.src.rpm'
rpm -Uvh kernel-<version>.src.rpm
cd ~/rpmbuild/SPECS
rpmbuild -bp --target=`uname -m` kernel.spec


The kernel source code we are going to use is now located in


~/rpmbuild/BUILD/kernel-<version>/


We are about ready to build, but before we do we need to put together a config file. In the configs folder is some you should probably use. Pick one and cp it to .config


cp configs/kernel-2.<version>-<arch>.config .config


Before we start to build the kernel we need to tweak the .config file so that it allows for enough UART ports. So modify .config and change the CONFIG_SERIAL_8250_RUNTIME_UARTS line to something higher like 8.


gedit .config


Then copy it over to help out the build process.


cp .config ~/rpmbuild/SOURCES/config-<arch>


Lets apply the patch then we will be ready to build.


patch -p0 < ../fastcom_async_pci_serial_patch_2.6.24.hardy


Now finally we get to actually build the kernel. It takes forever so go do something else for awhile.


cd ~/rpmbuild/SPECS/
rpmbuild --with baseonly -bb --target=`uname -m` kernel.spec


Finally the build is done and all you have left to do it install the kernel and reboot. Just double click on the RPM file of your choosing in the ~/rpmbuild/RPMS/ directory and follow the install prompt.

cp .config ~/rpmbuild/SOURCES/config-$arc

Today new FCore firmware is being released into the wild.

• FSCC = FCore version 9.07
• SuperFSCC = FCore version 4.0F

The changes to the FCore in these new versions are as follows:

1. Modified DPLL code to be more reliable and responsive to locking on to incoming data streams
2. Change behavior of X-Sync mode to allow for reception of back to back frames.  Previously if you had a data stream like this: <sync><data1><sync><data2><sync><data3>, you would actually only receive <data1> and <data3>.  Essentially when the receiver was told to start hunting for the next sync sequence, it was looking at data that came in after the hunt command was issued, not on data that was already received.
3. Pretty minor change, but there existed a condition that if you had X-Sync or Transparent mode enabled and you set the number of termination bytes (NTB) = 0, it would actually still append whatever was inside the TSR register.  Now when you set NTB = 0 it also sets the disable termination bit (DTERM) = 1, this ensures that there will be no termination appended.
4. Added Frame Sync Mode 5.  Previously if you shifted the FST signal, you would be moving both the beginning and the end of the FST signal.  Frame Sync Mode 5 is similar to Mode 1 except there are independent controls for both leading and trailing edge of the FST signal.  When enabled, CCR2[7:4] control the leading edge of the FST signal and CCR2[11:8] control the trailing edge.  CCR2[11:8] have no effect in any other Frame Sync Mode.

If you believe that you are affected by one of these and would like to receive updated firmware, you will have to return your board(s) to Commtech for reprogramming.  I have a widget that will allow for reprogramming of the boards in the field, but it is not yet ready.

This is almost more of a note self, but I thought it was worth putting out here just in case anyone else wonders about this.

If you attempt to read an invalid FCore register, i.e. 0×5C or 0×60, it will return the version status register (VSTR).  Who knew right?

Also, if you attempt to read a register that is not on a DWORD boundary (i.e. 0×19) you will effectively get gibberish in return, so don’t try to do that.

03/11/2009 – Windows
- Added an additional option for IsoSync mode to the IOCTL call. Also added an example, setIsosync.c.

03/04/2009 – Windows
- Add FST/DTR pin control to the setfeatues and getfeatures examples.

02/27/2009 – Windows
- Increased max number of ports from 10 to 20.

fscc_2009_03_11

Windows - Fix to time tag function to prevent overflow of a buffer if you add the time tag to a large frame.  This was causing a BSOD for one of the customers who use the Time Tag feature of the driver.  Thanks to Tim for the fix.

ESCC-PCI

ESCC-PCMCIA

ESCC-PCI-335

2/12/2009 - Windows

 - Fix problem where I frelled the property page in the previous release.

 - Added support for more of our FSCC family of boards as well as 4-port card

12/17/2008 - Linux

 - Added code to fix deprecated PCI defines for a clean compile.

12/02/2008 - Windows

 - Fixes to make the clock code in the Async driver be the same as the clock code in the Sync driver.

fscc_2009_02_12

Many users of the FSCC experience the situation where either one of the example programs and utilities returns with an error “Device or Resource busy.”

The likely cause (if we are talking about an FSCC card specifically) is that you performed an operation on the transmitter or receiver and there is not a valid transmit or receive clock present.  One example of an instance in which this can happen is if you configure the card to operate in a mode with an external receive clock (i.e. clock mode 1) and there is not a valid clock present on the RxClkIn pins and then you try to issue a command to the receiver (i.e. a HUNT or RESET command). 

Basically what happens is that the command is sent to the card and it never completes.  This can be verified by reading the status of the command executing bit.  If it is a 1, then there is a command waiting to be executed (when a clock shows up).  This can be remedied by momentarily switching to a mode that uses internal clocking (i.e. 7).  It can be prevented by never issuing a receive command if there is a chance that you don’t have a receive clock.

NOTE: all of the above can also pertain to the transmitter as well, if you issue a transmit command and you don’t have a transmit clock, the same situation will occur.

While LabView/LabWindows are not fully supported environments at this time, circumstances have led us to run the evaluation package of LabWnidows/CVI and the results of that eval follow.

While none of what follows includes any of the “nifty” features of LabWindows, it does demonstrate that it is possible to touch/use our hardware in that environment. Perhaps not in the manner that LabWindows users are accustomed, but not having much familiarity with that environment my main goal was to determine if it was possible to use our products “at all”.

The following method should work with any of our products as long as the base underlying system is Windows (and not one of the real-time variants of LabWindows). It is quite possible and straightforward to use any of our example code directly in CVI, all that is necessary is to add a ‘#include “windows.h”‘ to the top of the C file that contains the Win32API function calls. Since most of the driver interface to our cards relies on the basic Win32 Functions:

CreateFile()
DeviceIoControl()
ReadFile()
WriteFile()
CloseHandle()

Using these functions in LabWIndows/CVI is fairly straightforward.

If for whatever reason it is not possible to include the windows header file, (or include the windows dll’s that back those functions) in your project.  You can use the fscctoolbox dll to interface to the driver without using the win32 functions directly.  They are of course used by the toolbox dll, but using the toolbox you can just include the toolbox and not have to include all of the windows functionality that is exported by windows.h.

To do this you simply add the fscctoolbox.lib to your project, and then call the functions in the toolbox to open/configure/read/write to the card.