Commtech's Fastcom Product Support Blog

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 0x7E (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 0x3E).

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.